Front page | perl.perl6.internals |
Postings from June 2003
Romcc (Parrot and LinuxBIOS)
From: John van V.
June 13, 2003 18:03
Romcc (Parrot and LinuxBIOS)
Message ID: firstname.lastname@example.org
I am on the LinuxBIOS list and my gut sense told me that a compiler that they
are developing called romcc might be a fit for Parrot.
Since Parrot uses CPU style assembler as its native language, it might make
sense to match it with a compiler that can take advantage of this.
Along comes romcc. The biggest problem w/ working in the BIOS is that you have
to initialize RAM. That cannot be done in C because there is no RAM to do it
in. Assembler is the only solution but thats an economic impossibility
sometimes because of the scaricity of linux folks versed it it.
So, sensibly, Eric Biederman <email@example.com> writes a small compiler that
uses registers instead of RAM hungry stacks.
Bingo !! But I feel like an idiot since I have yet to write a line of C code
but in only about 5 emails, Eric tells me "Yeah, thats doable"
Me> Romcc uses registers, not stacks -- like the Perl6 Parrot VM
Eric> Actually quite a bit different.
Eric> Parrot will just not use stack oriented byte codes. But a call/return
Eric> stack will still be required. romcc does not use a call/return stack,
Eric> but romcc still implement subroutines.
Me> Is there any point in implementing the Perl6 VM in a version of romcc
Me> enhanced with a call/return stack as the only compromise toward the
Me> traditional VM ??
Eric> I simply do not understand the question.
Me> To be frank, this is my situation; I am in an "open" school where my
Me> mentor has told me that I am way over my computer credits
Eric> I hope this is at the high school level or else your computer credits
Eric> have not sunk in well at all.
Me> I meant to use romcc in a context separate from LinuxBIOS.
Me> It would be a custom compiler for Parrot itself, running with RAM, where
Me> CPU register style of Parrot would match the register reliance of Parrot
Me> -- with the one added call/return stack that you mentioned.
Eric> O.k. that makes more sense. I have strong reservations about adding a
Eric> call/return stack. But a port to the parrot VM without that should
Eric> be doable.
Eric's romcc basics
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
CXN, Inc. Contact: firstname.lastname@example.org
President, The Linux Society
linux society distro -> http://www.thinman.com/eLSD/readme
ThinMan is a registered trademark of CXN, Inc
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).