Author blaisorblade
Recipients ajaksu2, alexandre.vassalotti, bboissin, belopolsky, blaisorblade, christian.heimes, collinwinter, djc, facundobatista, gregory.p.smith, jyasskin, lemburg, pitrou, ralph.corderoy, rhettinger, skip.montanaro, spiv, theatrus
Date 2009-01-13.06:45:36
SpamBayes Score 0.0873567
Marked as misclassified No
Message-id <1231829138.54.0.853518537147.issue4753@psf.upfronthosting.co.za>
In-reply-to
Content
Ok, then vmgen adds almost just direct threading instead of indirect
threading.

Since the purpose of superinstructions is to eliminate dispatch
overhead, and that's more important when little actual work is done,
what about all ones which unconditionally end with FAST_DISPATCH and are
common? DUP_TOP, POP_TOP, DUP_TOPX(2,3) and other stack handling staff
which can't fail? To have any of them + XXX without error handling
problems? Removing handling of DUP_TOPX{4,5} is implied, you shouldn't
check functionality of the compiler during interpretation - indeed, even
the idea using a parameter for that is a waste. Have DUP_TOPX2 and
DUP_TOPX3, like JVM, is just simpler.

> Replication would be trickier since we want the bytecode generation to
be deterministic, but it's probably doable too.

Bytecode conversion during I/O is perfectly fine, to convert from the
actual bytecode to one of the chosen replicas. Conversion in a rescan
pass can be also OK (less cache friendly though, so if it's easy to
avoid, please do).
History
Date User Action Args
2009-01-13 06:45:38blaisorbladesetrecipients: + blaisorblade, lemburg, skip.montanaro, collinwinter, rhettinger, facundobatista, gregory.p.smith, spiv, belopolsky, pitrou, christian.heimes, ajaksu2, alexandre.vassalotti, jyasskin, djc, ralph.corderoy, bboissin, theatrus
2009-01-13 06:45:38blaisorbladesetmessageid: <1231829138.54.0.853518537147.issue4753@psf.upfronthosting.co.za>
2009-01-13 06:45:37blaisorbladelinkissue4753 messages
2009-01-13 06:45:36blaisorbladecreate