OSDev.org

Solar wrote:

• 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".

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?

Crazed123 wrote: 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.

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

3.Have you actually tried Lisp?

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.

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

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.

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.

Candy wrote: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.

proxy wrote: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 [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.

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
}

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.

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

//file1.c
int Test(){}

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

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

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

8. and possibly section support like this:

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

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

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)

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)

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

B.E wrote:

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

Code: Select all

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

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

Crazed123 wrote: 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.

   %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? */

Pype.Clicker wrote: 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?

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 ?)