Front page | perl.perl6.internals |
Postings from May 2001
Uri Guttman <uri@sysarch.com> writes: > DS> The one handy thing about push and pop is you don't need to go > DS> tracking the stack manually--that's taken care of by the push and > DS> pop opcodes. They can certainly be replaced with manipulations of > DS> a temp register and indirect register stores or loads, but that's > DS> more expensive--you do the same thing only with more dispatch > DS> overhead. > > DS> And I'm considering the stack as a place to put registers > DS> temporarily when the compiler runs out and needs a spot to > DS> squirrel something away, rather than as a mechanism to pass > DS> parameters to subs or opcodes. This is a stack in the traditional > DS> scratch-space sense. > >i agree with that. the stack here is mostly a call stack which >save/restores registers as we run out. with a large number like 64, we >won't run out until we do some deep calls. then the older registers (do >we have an LRU mechnism here?) get pushed by the sub call prologue which >then uses those registers for its my vars. I don't like push/pop - they imply a lot of stack limit checking word-by-word when it is less overhead for compiler to analyse the needs of whole basic-block check-for/make-space-on the stack _once_ then just address it. > >is the sub call/return stack also the data (scratch) stack? i think >separate ones makes sense here. the data stack is just PMC pointers, the >code call stack has register info, context, etc. One stack is more natural for translation to C (which has just one). One problem with FORTH was allocating two growable segments for its two stacks - one always ended up 2nd class. -- Nick Ing-Simmons who is looking for a new job see http://www.ni-s.u-net.com/Thread Previous | Thread Next