a programming language "kindof" designed for OS De

[Candy]

• is Python or Common Lisp, on the machine code level, really more effective in returning multiple values, than a C/C++ compiler doing return value optimization?
• will your selfmade-compiler for your selfmade-language actually beat the average GCC for efficiency of generated code, correctness, and ease of availability (not only the binaries, but documentation, tutorials, help from others)?
• will the improvements brought about by your language actually offset the learning time required to understand your language and toolchain?

I know, some of this could be countered with the truism, "if we all thought like that nothing new would ever be made".

I'd call it my signature or life motto.

But I believe in something that, in a company, would be called a "business case": Is the goal really worth the effort, or are you bound to end up with yet another toy language, supported by an unfinished toolchain rotting on a homepage that sees about three hits a month?

Which is on one side why I'm not developing my own toolchain for any company - it'd not be worth it and the eventual gain would be nullified by the time I would be tied up in it. I've recently had the oppurtunity to create an application that quite narrowly fit my OS design in a much reduced form, then to expand on it. It took me 3 weeks to make, it has about 9000 lines right now and it is so ridiculously easy to extend that I'm very motivated to create my own OS. Programming in it will require you to learn a new way of thinking and working, as well as being forced into one separation in your programs - yet, from what I've seen in that one program, I can easily tell that I consider it worth it.

If people here started to consider business aspects before starting a project, 99.9% of all these projects would be dead before conception. If, before inventing something, you considered the most likely outcome and based actually trying it on that, you might as well go into management. They're taking decisions on past experiences, not on believing in an idea.

[Solar]

1.A Common Lisp compiler can always know, just by looking at the form receiving the return values, whether or not those values are captured. Hence, a good Common Lisp compiler always performs what you call return value optimization: it always detects where those values are going and passes them directly there rather than actually writing out assembler code for a "multiple-value-list" form.

Means, it's merely on par with a good C/C++ compiler, not better.

2.Probably not, which is one of the reasons I would write my compiler to compile down to C or Pascal rather than ASM.

Means that your C compiler might spit errors and you'd have to figure out which part of your XYZ source corresponds to that error.

The other thing is, this has been originally about efficiency in returning multiple values from a function. You suggest a language that supports that syntactically, and a compiler compiling its source to C... which would leave you with either returning the values via stack or heap, or trusting the return value optimization of the C compiler all over again.

3.Have you actually tried Lisp?

I have looked into it, and wasn't too impressed with the expressiveness of its syntax. I work more efficiently in the C/C++/Java/C# family of syntaxes.

If you only want to use languages supported by the business community, go right on ahead using C. I'll run Object Pascal, and we'll see how things work out.

Don't get me wrong. There can be compelling reasons for using a language that is not in the mainstream. But those have to be really good reasons, and I doubt that "return value optimization" is one of them.

If creating this language and its toolchain is what you want to do for a hobby, go right ahead.

[Crazed123]

Means, it's merely on par with a good C/C++ compiler, not better.

Slightly better, I'd say. C/C++ compilers have to try and determine what the programmer means in order to use such optimizations, whereas in Lisp the programmer's intent is clearly laid out in the source.

Means that your C compiler might spit errors and you'd have to figure out which part of your XYZ source corresponds to that error.

The other thing is, this has been originally about efficiency in returning multiple values from a function. You suggest a language that supports that syntactically, and a compiler compiling its source to C... which would leave you with either returning the values via stack or heap, or trusting the return value optimization of the C compiler all over again.

I'd only write a Lispy -> C/Pascal compiler because I know nothing about writing an optimizing compiler. If I had to write Lispy -> ASM, I could only write a brute force, translate-Lisp-to-assembler-without-analyzing compiler, so instead I would try to let the C/Pascal compiler do the analysis.

Yes, I hopefully will take compiler courses in university.

Don't get me wrong. There can be compelling reasons for using a language that is not in the mainstream. But those have to be really good reasons, and I doubt that "return value optimization" is one of them.

If creating this language and its toolchain is what you want to do for a hobby, go right ahead.

Hobby? Not right now, I have about 3 hobby projects to work on together (Glider kernel, EDI, and a shell for Glider). However, it's definitely going in my Million-Dollar-Ideas-to-Write-a-PhD-Dissertation-About File.

[Cheery]

If people here started to consider business aspects before starting a project, 99.9% of all these projects would be dead before conception. If, before inventing something, you considered the most likely outcome and based actually trying it on that, you might as well go into management. They're taking decisions on past experiences, not on believing in an idea.

I must remember this paragraph. Very well said!

[Ryu]

In the languages that do "truly support" multiple return values, how do you intend to implement this feature on a assembly level? I mean, odds are you'll have to resort to one of these techniques mentioned above, in which case you are just putting a prettier syntax on top of C/C++'s approach. As mentioned above #1 is OK for this, but not general purpose, so it's only usable in some cases, would it be your solution anyway? If so, what would you want if the data is bigger than the registers can provide storage for?

Now first of all, are we designing a language that eases programming or a language that can easily translate into machine code? I don't see it revelant to overweigh easily maintained at assembly level then easily human readable. Its about making a language to lift weights off our shoulders, which syntax logics plays a big time role to comfort our overly tired minds and fingers. And if you think about it C/C++ is just a prettier sytnax over assembly.

For the compilation stage of the language supporting multiple return values, keeping this thought, does a calling convention such a cdecl would specifically mark EAX register to be the return register? Or is it only specified by platform?

The problem is determining it meets the platform calling convention or the return is compatible with already specified specifications of the calling convention (that is if the calling convention itself specifies its registers that does not change in any platform). From the compiler point of view, this means options are limited by calling convention rules as well platform specifications, which there is no solution until these specifications are known to the compiler, and therefore by concept proxy, your question can't really be answered at assembly level.

However thinking about the design of the language and its compilation stage, one method would be multiple returns statements are internally treated no differn't then passing arguments, only they are always references and applying a rule they get passed in after actual arguments. Internally, the compiler can then just apply that to any calling convention simply passing more arugments.. yes using more stack space but a generic approach.

[proxy]

Now first of all, are we designing a language that eases programming or a language that can easily translate into machine code? I don't see it [sic] revelant to [sic] overweigh easily maintained at assembly level then easily human readable. Its about making a language to lift weights off our shoulders, which syntax logics plays a big time role to comfort our overly tired minds and fingers. And if you think about it C/C++ is just a prettier [sic] sytnax over assembly.

I'm going to have to disagree with some of this. Yes we are course developing a language so that it is easier to read and write, that's the point of having languages higher than ASM. But at the same time, this discussion started because of the desire for multiple return values which as previously mentioned can be done in c/c++ through the use of structs, pointers, hidden params, or even return value optimization.

This was responded to with "well that's just giving the illusion of multiple return values, not actually doing it."

This is where the ASM part of the discussion starts, because if the language can do it with various techniques (perhaps not in a way as pretty as python can, but it CAN do it) then was is gained by modifying the language except syntactic sugar? So, back to my original question...

If the c/c++ way is just the appearance of multiple return values, how _in practice_ not in syntax would this be done in other languages. The answer is of course the same way for reasons that you have just listed. "... if you think about it C/C++ is just a prettier [sic] sytnax over assembly."

Also the hidden param thing is something that c/c++ DOES do as a common optimization. Furthermore you dont want to do everything by reference since it would actually add overhead to things such as integer params.

proxy

[B.E]

First,

The reason why we use C/C++ for systems development(or OS Deving), is because it works at a level just above assembly. Because of this, developers can build systems that are processor independent. Which no other compiled(not semi compiled like java) language has not been able to do.

Second,

All of the things you are going to put in this language are already possible in C/C++ in some form.

2. Will support a thing I like to call "variable to function aliasing" which is where you can make a special variable like do something like this:

Code: Select all

ALIAS unsigned int blah=0:&Func1,&Func2; //Func1 is for when someone reads it, Func2 is when someone sets it

unsigned int Func1(){
    return 1;
}

void Func2(unsigned int blah){
    //you can set something here
}

void _main(void){
    unsigned char tmp;
    blah=23 //this will call Func2(23)
    tmp=blah; //this will call Func1 and will set tmp to 1
}

In C/C++ you can use get and set methods.

4. also will have complete control over optimizations, and if you enable none then it doesn't do those annoying things like store variables in registers.

this can already be done by using #pragmas

5. control over how it compiles for different bits(16,unreal,32)

this can be done by putting all of you 16-bit cod in another file, for example //note this will not work because of changing from 32 to 16 bit:

Code: Select all

//file1.c
int Test(){}

Code: Select all

//file2.c
int main()
{
  Test()
  return 0;
}

to compile it:
gcc -c -b i8086 file1.c
gcc -c -b i386 file2.c
gcc -o Test file2.o file1.o

Note: I haven?t tried this

7. and it of course supports things like far functions in both real, unreal and for segmented protected mode(no code design right now).

can be done by

Code: Select all

void Test() __attribute__((far))
void Test2() __attribute__((near))

8. and possibly section support like this:

this can be done using a linker script. or using:

Code: Select all

void Test() __attribute__((section("SECTION-NAME")))

9. also a special nifty thing for asm stuff(supporting intel syntax!)

arr, I once thought AT&T syntax was confusing. but now that I understand why, I love it.

there is a compiler switch for this I think.

10. where ever you do a prototype for an external function is where it is put in the binary file,(just the function, not the whole library/object)

there is a way to do this just I can't remember how.

11. supports stronger macro support not sure on how to code this yet so cant really show what I mean(I mean by like for loops which is useful for ISR's)

this can be done by inlining the function. you can force it to inline

Code: Select all

void inline test() __attribute__((always_inline)){
}

In summery: The tools are there you just got to find out how to get them to work for you.

[bluecode]

5. control over how it compiles for different bits(16,unreal,32)

this can be done by putting all of you 16-bit cod in another file, for example //note this will not work because of changing from 32 to 16 bit:

Code: Select all

//file1.c
int Test(){}

Code: Select all

//file2.c
int main()
{
  Test()
  return 0;
}

to compile it:
gcc -c -b i8086 file1.c
gcc -c -b i386 file2.c
gcc -o Test file2.o file1.o

Note: I haven?t tried this

gcc/g++ does not support 16bit code afaik.

Code: Select all

void Test() __attribute__((far))
void Test2() __attribute__((near))

ehm, huh? Which segment is gcc/g++ then using?

[Crazed123]

Before this degenerates into "C/C++ is always good enough for OSdeving!" vs. "We need a new language for OSdeving.", I'd like to remind everyone of three things.

1.Any Turing-complete language will theoretically work if it can be compiled to machine code.
2.C has the advantage of being just above assembler, and therefore not requiring extra runtime code (which would require an OS beneath it) to support its language features.
3.C has the disadvantage of being just above assembler, and therefore not supporting features which would truly be helpful.

To continue... The thing which differentiates the multiple return value semantics of Common Lisp from those of C/C++ is that in CL, all secondary (all of them after the first) return values are discarded automatically if not captured. In C, I would have to use memory space to store unwanted values.

May I request a feature for our hypothetical language? Could it support Perl-style hash-maps natively? I really dislike having to write my own hash-table support.

[me=Crazed123]adds hash tables to /me's Dissertation Language.[/me]

[Solar]

In C, I would have to use memory space to store unwanted values.

Wrong. It depends on the compiler.

[Pype.Clicker]

In C, I would have to use memory space to store unwanted values.

There are two very distinct behaviours of GCC depending on whether the function is "exported" to the world or not. When a function is declared 'static' and when you don't put its address in some pointer, GCC is free to do virtually whatever it wants with your function, even inlining it or not compiling it at all (if it appears that you don't need it to be called).

On the other side, as soon as the function is somehow "visible" from other .o files (translation units in C compiling terminology), it has to conform to the C calling conventions, which for instance state that the "return structure" is allocated by the caller on stack before parameters, and that parameters are given params are pushed in reverse order ... bla bla bla.

Now, let's say we have DreamLang in which your function can return any number of parameters. Do you consider that the function you compiled with DreamLang is compiled once and linked many time (i.e. does it have to work the same regardless of how many of the returned values are used/discarded).

IIrc, "returning multiple values" in Lisp-derivated language is returning a list, right ? you have to "cons" it first, allocating cells to link atomic values together etc. Then if the list gets out of the scope and only its CAR is taken, the whole list will actually be garbage-collected, right ?

That doesn't sound much more enviable to C's "allocate structure for all items on stack" to me ...

Or does the common lisp compiler (that exists, right ?) behave in a smarter way?

May I request a feature for our hypothetical language? Could it support Perl-style hash-maps natively? I really dislike having to write my own hash-table support.

For sure, in-language hashes are a real help for dev'ing ... Much like in-language support for lists/arrays. Yet you have no control on how searchs are performed, how arrays are allocated/extended/...

Code: Select all

   %mapping =  (cdrom => "/dev/hdc", mouse=>"/dev/psaux");
    /* somehow, we could pre-compile that into a static table */

    $mapping{keyboard}="/dev/usb/hid0";
    /* aaie. now we have to extend the table or what? */

In other words, you need a support library for those extensions. And probably your implementation of that library won't fit someone else's kernel (we all know OS devers never fully feel comfortable with third-party software, do they ?)

[Crazed123]

IIrc, "returning multiple values" in Lisp-derivated language is returning a list, right ? you have to "cons" it first, allocating cells to link atomic values together etc. Then if the list gets out of the scope and only its CAR is taken, the whole list will actually be garbage-collected, right ?

That doesn't sound much more enviable to C's "allocate structure for all items on stack" to me ...

That's because Common Lisp does not behave that way. In CL, returning a list means returning that list as a *single, primary return value*, rather than returning its elements as multiple values. Read below.

Or does the common lisp compiler (that exists, right ?) behave in a smarter way?

To my knowledge, it does. AFAIK, if the caller only captures the primary value of a function than only that value will get returned. This generates a bit more code than simply returning all values together and then taking the first, but uses less memory and runs faster.

For sure, in-language hashes are a real help for dev'ing ... Much like in-language support for lists/arrays. Yet you have no control on how searchs are performed, how arrays are allocated/extended/...

Code: Select all

   %mapping =  (cdrom => "/dev/hdc", mouse=>"/dev/psaux");
    /* somehow, we could pre-compile that into a static table */

    $mapping{keyboard}="/dev/usb/hid0";
    /* aaie. now we have to extend the table or what? */

In other words, you need a support library for those extensions. And probably your implementation of that library won't fit someone else's kernel (we all know OS devers never fully feel comfortable with third-party software, do they ?)

OK, so the runtime library of DreamLang is open-source, well-organized into separate functions, and anyone who pleases can rewrite some of those functions rather than use the standard versions. Feh, nearly all open-source RTLs work that way now.

[earlz]

wow!!! lots o' comments; being away from pc for 2weeks has really let me think about design...

I particularly like the multiple return value idea and my best idea for how to keep C calling convention(if I'm thinking right...)

Code: Select all

(char,char) foo(x,y){ //probably change the )'s to ]'s in the char,char
  //do nothing....
  return (0,0)
}

/*the way the stack looks inside the function...
(in dwords)
0:RETURN_ADDRESS -esp is right above this
1:y
2:x
3:char 2(right)
4:char 1(left)

*/

also I would like to be enough gcc compatabile to where it will compile standard Clib headers with the exclusion of some added reserved words

I had some more ideas but kindof forgot them
heres the big list of doom
1. support something like special types like

Code: Select all

_1BIT true_bool; //an actual bool using only 1bit of memory
_5BIT var1; //actually only allocates 5bits

// .....
true_bool=1;
true_bool++; //will make it 0
true_bool=493; //will not modify anything but that bool
//and well you get it....
//very nifty for things like gdt where only 1 bit is needed for some stuff and more will mess it up...

which will work by using a temp var/register and modifying only those bits
of course this causes my "where it is is where its located" idea but my best idea is for it to keep a secondary data area or something for vars that are not 8,16, or 32 bit....

well edit later getting tired....

[proxy]

Code: Select all

_1BIT true_bool; //an actual bool using only 1bit of memory
_5BIT var1; //actually only allocates 5bits

// .....
true_bool=1;
true_bool++; //will make it 0
true_bool=493; //will not modify anything but that bool
//and well you get it....
//very nifty for things like gdt where only 1 bit is needed for some stuff and more will mess it up...

this is achievable in C/C++ with bitfields:

Code: Select all

struct S {
    unsigned char item1 : 4;
    unsigned char item2 : 1;
    unsigned char item3 : 3;
}; /* this structure is exactly one byte big! */

to be completely honest, I really feel like you should learn the languages you intend to replace better, and then when you _really_ know c/c++ well, decide if they still need a successor to get what you need.

proxy

[earlz]

hmmm I didn't know that, yea probably should learn everything in the language first lol I still don't know what enumerators are!

[me=Jordan3]changes his un-nifty gdt code[/me]