Re: Stacks & registers

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

Thread Previous | Thread Next

From:

Uri Guttman

Date:

May 26, 2001 21:02

Subject:

Re: Stacks & registers

Message ID:

200105270401.AAA04784@home.sysarch.com.

>>>>> "NI" == Nick Ing-Simmons <nick@ing-simmons.net> writes:

  NI> Well:
  NI>  (a) I thought the plan was to design threads in from the begining this time.
  NI>  (b) I maintain that cost is about the same as global variables anyway.

i agree with (a) but is that always compiled in/enabled even in a single
thread perl? is the code always thread enabled with the default being
just one thread running?

  >> and the window base is not accounted for. you would need 2
  >> indirections, the first to get the window base and the second to get the
  >> register in that window. 

  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. 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. 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.

  >> 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.

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

-- 
Uri Guttman  ---------  uri@sysarch.com  ----------  http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11
Class and Registration info:     http://www.sysarch.com/perl/OOP_class.html

Thread Previous | Thread Next