=head1 TITLE

Ordered bytecode

=head1 VERSION

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

=head1 ABSTRACT

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

=head1 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
C<NORMAL>. In fact, the module C<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 C<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.

=head1 IMPLEMENTATION

As above...

=head1 REFERENCES

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

RFC 302: Unrolling loops and tail recursion.