Hello all, 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 PROTECTED]> 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 again. ===== CXN, Inc. Contact: [EMAIL PROTECTED] President, The Linux Society http://groups.yahoo.com/group/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). http://calendar.yahoo.com
