develooper Front page | perl.perl6.internals | Postings from June 2003

Romcc (Parrot and LinuxBIOS)

Thread Previous | Thread Next
From:
John van V.
Date:
June 13, 2003 18:03
Subject:
Romcc (Parrot and LinuxBIOS)
Message ID:
20030613232017.77537.qmail@web10503.mail.yahoo.com
 
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 <ebiederman@lnxi.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
 again.
 

 

=====
CXN, Inc. Contact: john@thinman.com
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

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About