[% setvar title Ordered bytecode %]
|Note: these documents may be out of date. Do not use as reference!|
To see what is currently happening visit http://www.perl6.org/
Maintainer: Simon Cozens <email@example.com> Date: 25 Sep 2000 Mailing List: firstname.lastname@example.org Number: 310 Version: 1 Status: Developing
Bytecode should be structured in such a way that reading and executing it can be parallelised.
(Note: this is slightly vague, and needs a bit of fleshing out. Help! :)
One of the speed problems with compiled Perl is that the whole op tree needs to be read into memory before being run, and reading in bytecode is slow. One solution would be to find a way of parallelising the reading and the running.
This RFC revolves around the concept of basic blocks. Basic blocks are
portions of the code which will execute "straight through" without
looping or forking; they're areas where the PP code currently returns
NORMAL. In fact, the module
B::Bblock walks basic blocks.
Now, there's always going to be one basic block which kicks off the
action; in Perl 5, it's the basic block from
PL_mainroot. This should
come first in the bytecode. After that, should come a small marker that
this is the end of the basic block, and the offsets of the next possible
This means that the VM can do at least a bit of the runtime while it's reading in the other possibilities; by the time the bytecode for the other possible paths is read in and ready to run, the previous bblock should have completed its run. The bytecode output should be arranged so that related blocks come as close to each other as possible, so that it's possible to seek a near-sequential path through the program.
"Compilers", by Aho, Sethi and Ullman.
RFC 302: Unrolling loops and tail recursion.