Allocation of PASM registers (in PASM mode)

kjstol parrotcode at gmail.com
Tue Jan 13 22:13:21 UTC 2009


On Tue, Jan 13, 2009 at 10:10 PM, Will Coleda <will at coleda.com> wrote:

> Leo!
>
> On Tue, Jan 13, 2009 at 4:45 PM, Leopold Toetsch <lt at toetsch.at> wrote:
> > Am Sonntag, 11. Januar 2009 18:13 schrieb Geoffrey Broadwell:
> >
> > First, I'm reciting Coke's argument here:
> >
> > "If P42 in PASM acts the same way as $P42 in PIR, why do we have two
> > different ways to say the same thing?"
> >
> > Seconded.
> >
> > And last time I checked, you could use P42 in PIR too.
>
> This was actually recently disallowed. You must now use $P42 in PIR.
> P42 doesn't compile in PIR: vice versa in PASM.
>

*Actually*.... this is kind of interesting. As it is now, macros are PIR or
PASM specific, if they're using registers, as usage of PASM registers will
render the macro unusable in PIR mode, and vice versa.

<wild thought> what if registers are ALWAYS written with a $?

kjs



>
> >> It feels like there is a stability/security question here.  If someone
> >> can ask for register 42 or 999, what's to stop them for asking for
> >> register 1000000000 and allocating all of main mem?
> >
> > You'll get out of memory error in that case.
> >
> >> Whatever solution chosen to catch this during the compile, we still have
> >> to do bytecode validation anyway.  An argument can be made to leave the
> >> problem entirely to bytecode validation (and runtime checks for e.g.
> >> memory allocation failures), as long as the bytecode annotations allow
> >> us to report errors nicely.
> >
> > Yep.
> >
> >> It is of course always nice to report insanity as early as possible, but
> >> since the PASM compile and bytecode execution can be done on separate
> >> machines, it may not be clear at compile time that a register allocation
> >> is insane ....
> >
> > Indeed. Runtime checks are needed _as well_. You might warn on insane
> > allocation and die on totally insane allocation according to some
> percentage
> > and a given amount for insaneness.
> >
> > Don't forget the debugging issues, when PBC register != PASM register.
> >
> >> -'f
> >
> > leo
> > _______________________________________________
> > http://lists.parrot.org/mailman/listinfo/parrot-dev
> >
>
>
>
> --
> Will "Coke" Coleda
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.parrot.org/pipermail/parrot-dev/attachments/20090113/ef7f086d/attachment-0001.htm 


More information about the parrot-dev mailing list