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.


Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 1 of 1 | next ›
Discussion Overview
groupperl6-internals @
postedJan 12, '09 at 12:06a
activeJan 12, '09 at 12:06a

1 user in discussion

Geoffrey Broadwell: 1 post



site design / logo © 2021 Grokbase