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
