John van Vlaanderen john-at-thinman@nyc.rr.com writes:
Hi Eric,
I think it's really incredible that you are developing this, and once it's done I am sure we will all wonder how we lived w/ out it.
But, as embarrassed as I am to ask, what is it for ??
I suspect others who have not followed this to closely probably have the same question.
romcc is a C compiler that does not use a stack. Instead it keeps all variables in registers.
Currently LinuxBIOS has a lot of assembly code simply because memory initialization is difficult in the general case. This code cannot be written with a standard compiler because there is no memory to put a stack in. Nor on x86 are there cache blocks that can be locked into place. As code generated with romcc does not use a stack it can be used during memory initialization.
It is true romcc is not *done*, it is quite usable at this point.
In the freebios2 I have been gradually making the primary API ones that can be used before memory is initialized.
The biggest difference is that if you want to return multiple values instead of passing in the address of a variable the a multi valued structure must be returned.
The biggest current known bug is that if you have a small type like short when it is stored in a register nothing ensures it does not take on a larger value than will fit in a short.
unsigned short i; i = 65535; i = i + 1; /* i == 65536 oops */
The biggest shortcoming comes from it's nature and
I have used it enough at this point I don't want to live without it again.
Eric
Haha, I thought so,
Eric wrote:
I have used it enough at this point I don't want to live without it again.
I did spend the better part of last night reading the thread, though that got to the why but not how.
Uses registers, not stacks -- like the Perl6 Parrot VM, I am going to have to tell them :)
============ Eric's text ============
Currently LinuxBIOS has a lot of assembly code simply because memory initialization is difficult in the general case. This code cannot be written with a standard compiler because there is no memory to put a stack in. Nor on x86 are there cache blocks that can be locked into place. As code generated with romcc does not use a stack it can be used during memory initialization.
It is true romcc is not *done*, it is quite usable at this point.
In the freebios2 I have been gradually making the primary API ones that can be used before memory is initialized.
The biggest difference is that if you want to return multiple values instead of passing in the address of a variable the a multi valued structure must be returned.
The biggest current known bug is that if you have a small type like short when it is stored in a register nothing ensures it does not take on a larger value than will fit in a short.
unsigned short i; i = 65535; i = i + 1; /* i == 65536 oops */
The biggest shortcoming comes from it's nature and
I have used it enough at this point I don't want to live without it again.
Eric
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
John van Vlaanderen john-at-thinman@nyc.rr.com writes:
Haha, I thought so,
Eric wrote:
I have used it enough at this point I don't want to live without it again.
I did spend the better part of last night reading the thread, though that got to the why but not how.
Uses registers, not stacks -- like the Perl6 Parrot VM, I am going to have to tell them :)
Actually quite a bit different.
Parrot will just not use stack oriented byte codes. But a call/return stack will still be required. romcc does not use a call/return stack, but romcc still implement subroutines.
Eric
-
ebiederman＠lnxi.com -
John van Vlaanderen