Graham Barr <[EMAIL PROTECTED]> writes:
>On Wed, May 23, 2001 at 10:30:32AM -0700, Hong Zhang wrote:
>> I think "stack based =~ register based". If we don't have Java-like "jsr" 
>
>That comment reminds me of how the register file is implemented in
>a sun sparc. They have a large register file, but only some are accessable
>at any given time, say 16. 

32 IIRC but principle is correct.

>When you do a sub call you place your
>arguments in the high registers, say 4, and shift the window pointer
>by 12 (in this case).  What was r12-r15 now becomes r0-r3. On return
>the result is placed into r0-r3 which are then available to the
>caller as r12-r15.
>
>This allows very efficient argument passing without having to save
>registers to a stack and restor them later.

That cost can be over-played - most compilers need "scratch" registers
which with have values which don't need to be saved, if your RISC
is set up to use arg registers as scratch then most of the save/restores
can be eliminated, and others can be hidden in delay slots or super-scalar
executed in parallel with other operations.

The problems with SPARC scheme are:

1. When you call deep enough to fall off the end of the large register
   file an expensive "system call" is needed to save some registers
   at the other end to memory and "wrap", and then again when you
   come "back" to the now-in-memory registers.

2. The large file has a large decode which is in "logical" critical
   path - so all kinds of bypass tricks have to be played to get 
   speed back.

Neither is too bad for a virtual machine though.

"We" need to decide where a perl6 sub's local variables are going to live
(in the recursive case) - if we need a "stack" anyway it may make sense
for VM to have ways of indexing the local "frame" rather than having 
"global" registers (set per thread by the way?)

What I do agree with is that 
   push a
   push b
   add
   pop  r 

is lousy way to code r = a + b - too much pointless copying. 
We want 
   add #a,#b,#r
were #a is a small number indexing into "somewhere" where a is stored.


>
>Graham.
-- 
Nick Ing-Simmons
who is looking for a new job see http://www.ni-s.u-net.com/

Reply via email to