Allocation of PASM registers (in PASM mode)

[Geoffrey Broadwell]

On Tue, 2009-01-13 at 21:22 +0100, Bernhard Schmalhofer wrote:
> Allison Randal schrieb:
> > Geoffrey Broadwell wrote:
> >   
> >> 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)))
> >>     
> What the difference between these these two identies, when PBC == 
> compile(PASM)?

Given any particular PBC and Parrot [release/config/options], the dump
operation will produce one particular string of PASM, which we could
refer to as the "canonical" PASM for that PBC and Parrot.

However, there are many different PASM that compile to the same PBC, and
thus in general PASM != dump(compile(PASM)) for any given PASM.  (Seen a
different way, knowing that compile(PASM_1) == compile(PASM_2) does not
imply PASM_1 == PASM_2.)

Thus, the second identity declares that compiling roundtripped PASM
still produces the same PBC as a direct compile would, even for some
PASM source that is *not* the canonical version produced by dumping the
PBC -- and thus PASM != dump(compile(PASM)).

> PBC can be generated in several ways. So
>    compile(PIR)   == compile(dump(compile(PIR)))
>    compile(Perl6) == compile(dump(compile(Perl6)))
> has to hold as well.

Actually, I think that's not (necessarily) true -- because once the
register allocator is involved (i.e., for any language other than raw
PASM), there's no guarantee that register selections will be identical
from compile to compile.  In fact, as far as I can tell, the register
allocator is free to randomly shuffle its selection of the "real" Parrot
registers on every compile run if it wants to.  This would alter the PBC
output, but not cause a functional change to the program, assuming the
allocator is still "correct".  (It could of course alter performance,
but that's a different discussion.)
 

-'f