Re: Stacks & registers
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> 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 - [EMAIL PROTECTED] -- 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
Re: Stacks & registers
Uri Guttman <[EMAIL PROTECTED]> writes: > NI> i.e. > NI> R4 = frame[N] > NI> is same cost as > NI> R4 = per_thread[N] > NI> and about the same as > NI> extern REGISTER GlobalRegs4 > NI> R4 = GlobalRegs4; > >well, if there is no multithreading then you don't need the per_thread >lookup. Well: (a) I thought the plan was to design threads in from the begining this time. (b) I maintain that cost is about the same as global variables anyway. The case for (b) is as follows: on RISC hardware R4 = SomeGlobal; becomes two instructions: loadhigh SomeGlobal.high,rp ld rp(SomeGlobal.low),R4 The C compiler will try and factor out the loadhigh instruction, leaving you with an indexed load. In most cases ld rp(RegBase.low+4),R4 is just a valid and takes same number of cycles, and there is normally a form like ld rp(rn),R4 Which allows "index" by variable amount. On CISC machines, then either there is an invisible RISC (e.g. Pentium) which behaves as above or you get something akin to PDP-11 where indirection reads a literal address via the "program counter". move [pc+n],r4 In such cases move [regbase+n],r4 is going to be just as fast - the issue is the need for a (real machine) register to hold 'regbase'. >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. No - you keep the window base "handy" and don't keep re-fetching it, same way you keep "program counter" and "stack pointer" "handy". Getting window[N] is same cost as next = *PC++; My point is that to avoid keeping too-many things "handy" window base and stack pointer should be the same (real machine) register. >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. That makes sense if (and only if) virtual machine registers are real machine registers. If virtual machine registers are in memory then accessing them "on the stack" is just as efficient (perhaps more so) than at some other "special" location. And it avoids need for memory-to-memory moves to push/pop them when we do "spill". -- Nick Ing-Simmons who is looking for a new job see http://www.ni-s.u-net.com/
