develooper Front page | perl.perl6.internals | Postings from May 2001

Re: Stacks & registers

Thread Previous | Thread Next
From:
Nick Ing-Simmons
Date:
May 27, 2001 05:09
Subject:
Re: Stacks & registers
Message ID:
20010527120950.652.5@dromedary.ni-s.u-net.com
Uri Guttman <uri@sysarch.com> writes:
>  NI> No - you keep the window base "handy" and don't keep re-fetching it,
>  NI> same way you keep "program counter" and "stack pointer" "handy".
>
>  NI> Getting      
>  NI>    window[N] 
>  NI> is same cost as 
>  NI>    next = *PC++; 
>
>  NI> My point is that to avoid keeping too-many things "handy" window
>  NI> base and stack pointer should be the same (real machine) register.
>
>if we can control that. 

Maybe not directly, but most compilers will keep common base registers
in machine registers if you code things right.

>but i see issues too. i mentioned the idea of
>having $_ and other special vars and stuff would have their own PMC's in
>this register set. 

Why does it have to be _this_ register set - globals can go in another
register set - SPARC's register scheme has global registers too.

That said my guess is that $_ is usually save/restored across sub/block
boundaries.

>dan like the idea. that doesn't map well to a window
>as those vars may not change when you call subs. i just don't see
>register windows as useful at the VM level.

Call it what you will - I am arguing for an addressable stack
not for windows as such.


>
>  >> i am just saying register windows don't seem to be any win for us
>  >> and cost an extra indirection for each data access. my view is let
>  >> the compiler keep track of the register usage and just do
>  >> individual push/pops as needed when registers run out.
>
>  NI> That makes sense if (and only if) virtual machine registers are real 
>  NI> machine registers. If virtual machine registers are in memory then 
>  NI> accessing them "on the stack" is just as efficient (perhaps more so)
>  NI> than at some other "special" location. And it avoids need for 
>  NI> memory-to-memory moves to push/pop them when we do "spill".
>
>no, the idea is the VM compiler keeps track of IL register use for the
>purpose of code generating N-tuple op codes and their register
>arguments. this is a pure IL design thing and has nothing to do with
>machine registers. at this level, register windows don't win IMO.

That quote is a little misleading. My point is that UNLESS machine
(real) machine registers are involved then all IL "Registers" are 
in memory. Given that they are in memory they should be grouped with
and addressed-via-same-base-as other "memory" that a sub is accessing.
(The sub will be accessing the stack (or its PAD if you like), and the 
op-stream for sure, and possibly a few hot globals.)

The IL is going to be CISC-ish - so treat it like an x86 where 
you operate on things where-they-are (e.g. "on the stack") 

   add 4,BP[4]

rather than RISC where you 

   ld BP[4],X
   add 4,X
   ST X,BP[4]
   
If "registers" are really memory the extra "moves" of a RISC scheme
are expensive.

What we _really_ don't want is the worst of both worlds:

   push BP[4];
   push 4
   add
   pop  BP[4] 

>
>i am thinking about writing a short psuedo code post about the N-tuple
>op codes and the register set design. the ideas are percolating in my
>brane.
>
>uri
-- 
Nick Ing-Simmons
who is looking for a new job see http://www.ni-s.u-net.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