Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Variable registers

0 views
Skip to first unread message

vand...@home.nl

unread,
Oct 1, 2005, 2:46:48 AM10/1/05
to perl6-i...@perl.org
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?

How does this stand WRT the 32 registers in Parrot. Is this still the case, or will this change as well?

thanks,
klaas-jan

Leopold Toetsch

unread,
Oct 1, 2005, 5:59:46 AM10/1/05
to vand...@home.nl, perl6-i...@perl.org

On Oct 1, 2005, at 8:46, <vand...@home.nl> wrote:

>
> 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

Klaas-Jan Stol

unread,
Oct 1, 2005, 12:11:22 PM10/1/05
to Leopold Toetsch, perl6-i...@perl.org
Leopold Toetsch wrote:

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

Leopold Toetsch

unread,
Oct 1, 2005, 12:55:53 PM10/1/05
to Klaas-Jan Stol, perl6-i...@perl.org

On Oct 1, 2005, at 18:11, Klaas-Jan Stol wrote:

> 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

Klaas-Jan Stol

unread,
Oct 3, 2005, 5:44:53 AM10/3/05
to Leopold Toetsch, perl6-i...@perl.org
Leopold Toetsch wrote:

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


Leopold Toetsch

unread,
Oct 3, 2005, 6:25:47 AM10/3/05
to Klaas-Jan Stol, perl6-i...@perl.org
Klaas-Jan Stol wrote:

> 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

0 new messages