On Fri, 19 Oct 2001, Gregor N. Purdy wrote: > Dan -- > FWIW, I'd rather not dedicate registers to special uses at the Parrot > level. Jako reserves [INPS]0 for temporaries, but that is at its > discretion, not dictated by Parrot (and I like it that way :). I was > wishing for separate data and address stacks when I was writing the > Jako calling convention stuff, but I can live with the rotate solution. > If the choices come down to reserved registers or separate stacks, > though, I'm squarely in the separate stacks camp.
Not that it matters at this stage, but if we rely on compilers for temporaries, then what happens when we integrate different compiled binaries? MIPS (and I believe alpha) was good at reserved registers. Aside from "macro'd ops" most reserved registers only reserved at subroutine call time. Eventually all the compilers are going to have to deal with register renaming (we're going to run out of registers for a lot of code, and I don't think pushing and poping the register stack is going to be very helpful). I'd be curious to read up on register renaming compiler strategies (anybody have any online references?). Guess the basic algorithm is to assume an infinite number of registers, then perform data dependency checks and reduce the tree. In my up and comming post, I suggest a "peek R, i|ic" op-code which allows you to store fundamental datatypes in subroutine local stack memory (like hardware CPUs). If all variables are mapped within the stack frame, then register renaming should merely consist of pushing unused valued to their associated frame-offset and reusing that register and extracting it's replacement value from another address. -Michael
