On Sun, 2009-01-11 at 12:39 -0500, Andrew Whitworth wrote:
> This is something that obviously needs to be avoided. PASM doesn't
> require that P42 be the 42nd register in an array. It only requires
> that values put into P42 aren't overwritten and the register isn't
> repurposed later. The simplest allocator to avoid this problem would
> probably be hash-based, where the string "P10000000" maps to a
> small-numered but unique integer value. Each register name maps
> uniquely to an actual register storage location, just not necessarily
> the one specified in the name.
Do you propose to do this during PASM compile, PBC load, or PBC
interpret? There are tradeoffs:
* If only mapped in the PASM compile, then the bytecode is still
risky, and you haven't really addressed the root problem.
* If mapped during PBC load, that breaks the "mmap and execute"
optimized path. One possible mitigation is to only perform
the register remapping if the maximum register number seen in
the PBC is larger than some threshold. The max register number
might be available as a side effect of general PBC verification;
one hopes that it will not add too much CPU time to that pass.
* If instead the mapping is done during the PBC interpret phase,
that makes almost every op slower. This is probably just
unacceptable, performance-wise.
-'f
