Allocation of PASM registers (in PASM mode)

[Will Coleda]

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.

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