Dan Sugalski <[EMAIL PROTECTED]> wrote: > Leo, we've talked about this before. The sensible and straightforward > thing to do in a case like this is to tag in the sub pmc which > register frames are used by the sub.
And what, if the sub calls another sub? The current pushtopp() is already an illegal optimization. We are not preserving P0, P1, P2 (for methods). So to preserve these, they are copied up to the upper frame half, where they occupy valuable register numbers, that else could get allocated. The same is true for all function arguments. That's all hidden by the PIR code. Look at the generated PASM code. $ cat o.pir .sub foo method,prototyped .param pmc a .param pmc b .param pmc c bar() ... # reuse a,b,c $ parrot -o- o.pir foo: set P21, P5 set P20, P6 set P19, P7 set P18, P2 set P16, P1 ... 5 registers are already used. P0 isn't preserved. That's it. You want to have improvment on the register allocator. ABove is one reason, why it gets into spilling easily. This is P registers only. We have I0..I4. Should be preserved. S0 for methods. We don't do it currently. A illegal speed hack. And as said (you are always snipping import things ;), whenever a subroutine or method will use some native S or N registers, we end up saving 640 bytes. In *each* function call. And restore 640 bytes on each return. My proposal did show a way, how to copy ~640 bytes *once* per subroutine creation. You didn't even comment that. > I'm not sure what you're thinking of with coroutines. I'm thinking of using 2 continuations for jumping back and forth. leo