I read that with the new calling conventions, there are a variable number of registers. So, if I understand correctly, if a function call takes 2 parameters, then there are only 2, and if there are 30 parameters, there will be a frame holding 30 registers. Is this about right?
How does this stand WRT the 32 registers in Parrot. Is this still the case, or will this change as well?
thanks,
klaas-jan
>
> hi,
>
> I read that with the new calling conventions, there are a variable
> number of registers. So, if I understand correctly, if a function call
> takes 2 parameters, then there are only 2, and if there are 30
> parameters, there will be a frame holding 30 registers. Is this about
> right?
Yes. The argument passing opcodes take a variable amount of registers
> How does this stand WRT the 32 registers in Parrot. Is this still the
> case, or will this change as well?
This will change. Register frame size and thus the amount of registers
will be adapted to the actual usage of a subroutine.
> thanks,
> klaas-jan
leo
ah I thought so. just making sure. Then another question WRT this; will
there be a register allocator? In other words, an attempt to minimize
the number of needed registers? (in my simple code generator
implementations, any time I need a new register, I just increment a
counter, and use that, so in that case there is No register allocation
scheme)
regards,
klaas-jan
> ah I thought so. just making sure. Then another question WRT this;
> will there be a register allocator? In other words, an attempt to
> minimize the number of needed registers? (in my simple code generator
> implementations, any time I need a new register, I just increment a
> counter, and use that, so in that case there is No register
> allocation scheme)
Sure, the register allocator will remain. The "increment the counter"
strategy is fine. The only difference will be that all lexicals and
persistent variables, which are used around a function call, will be
assigned to distinct Parrot registers. This strategy will solve the
still lurking continuation bug that was discussed excessively here.
Temps, not used around a function call, will have their registers
reused as now.
> regards,
> klaas-jan
leo
maybe I misunderstand, but does the above mean that lexicals are stored
in registers, instead of storing them in scratchpads? (with lexicals
being local variables in a function, with the addition of being also
accessible from nested functions)
klaas-jan
> maybe I misunderstand, but does the above mean that lexicals are stored
> in registers, instead of storing them in scratchpads? (with lexicals
> being local variables in a function, with the addition of being also
> accessible from nested functions)
The storage of lexicals will be in Parrot registers, yes. The plan is to
assign all static (compile-time known) lexicals to distinct Parrot
registers. Dynamic lexicals (tcl upvars or such) will still be handled
with a hash, and name lookup remains the same.
Basically: the current runtime-only lexical handling will be extended to
provide a static scheme too.
Chip is currently preparing a PDD covering all the details.
> klaas-jan
leo