Allocation of PASM registers (in PASM mode)

[Geoffrey Broadwell]

On Sun, 2009-01-11 at 11:41 +0000, kjstol wrote:
> On Sun, Jan 11, 2009 at 4:36 AM, Will Coleda <will at coleda.com> wrote:
>         On Sat, Jan 10, 2009 at 11:28 PM, Allison Randal
>         <allison at parrot.org> wrote:
>         > Klaas-Jan Stol wrote:
>         >> Should P42 be mapped to P0 (i.e. the first available
>         register), or
>         >> should P42 be used (thus allocating at least 43 (counting
>         from 0)
>         >> registers).
>         >> It's the difference between full power to the user (s/he
>         might know what
>         >> s/he's doing), or doing the allocation for the user.
>         >
>         > As far as the user is concerned, they have no guarantee that P42 is
>         > allocated to any particular register. The only guarantee they have is
>         > that P42 will hold the value they stored in it for as long as that value
>         > is used within the program. This allows us to plug in any number of
>         > allocation schemes behind the scenes.
>         >
>         > In PIRC you're free to do whatever you want, but I prefer option B):
>         > intelligently allocate registers, and don't allocate 1000 registers just
>         > because someone used P999.
>         
>         If P42 in PASM acts the same way as $P42 in PIR, why do we have two
>         different ways to say the same thing?
> 
> I would sure hate having to remove all '$' characters, should it be deprecated ;-) 
> 
> Seriously, Coke's point is valid. I was wrong in my earlier suspicion that IMCC is doing register allocation in PASM mode; it doesnt. (easy to test: write a PASM script, using register 42 (or any other non-zero, as IMCC's allocator starts at 0), compile to bytecode and disassemble it.

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?

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.

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


-'f