Allocation of PASM registers (in PASM mode)

[Geoffrey Broadwell]

On Sun, 2009-01-11 at 13:10 -0800, Allison Randal wrote:
> The one argument against sane register allocation in PASM is that if 
> PASM is a "plain-english representation of bytecode", and bytecode deals 
> with literal registers, then PASM should deal with literal registers 
> too.

This I buy.

> But, I'd rather solve that with a convention that when dumping 
> bytecode to PASM, it dumps "P2" for PMC register 2 (for easy 
> identification). But, when you re-run the dumped PASM, it may allocate 
> the registers differently (especially if you've modified the dumped PASM).

This I don't.  If PASM really is a direct human-compatible
representation of bytecode, then we must always maintain the two key
identities:

  * PBC           == compile(dump(PBC))
  * compile(PASM) == compile(dump(compile(PASM)))

Breaking these will cause delay and confusion [1] (and lots of spurious
bug reports).

Essentially I think there's a binary choice to be made: Either PASM is
dumped PBC, and we maintain the round-trip identities, or it's not -- in
which case PASM loses a lot of its lustre as a usefuly different
language from PIR.

Note that I am NOT arguing that we need to maintain the other identity,
'PASM == dump(compile(PASM))'.   I don't think the bytecode annotations
need to be able to reproduce byte-accurate source.  At least not in
Parrot 1.0.  :-)


-'f

[1] If you recognize this reference, I'm sorry.  I feel your pain.