TITLE

Ordered bytecode

VERSION

  Maintainer: Simon Cozens <simon@brecon.co.uk>
  Date: 25 Sep 2000
  Mailing List: perl6-internals@perl.org
  Number: 310
  Version: 1
  Status: Developing

ABSTRACT

Bytecode should be structured in such a way that reading and executing it can be parallelised.

DESCRIPTION

(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 blocks.

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.

IMPLEMENTATION

As above...

REFERENCES

"Compilers", by Aho, Sethi and Ullman. B::Bblock