On Monday 21 May 2001 21:36, A. C. Yardley wrote:
> B<I<Bytecode>>
> This section gives detals on how the instruction is laid out in the
> bytecode of a class file. It shows a table listing the opcode for
> the instruction, as well as any additional parameters that follow
> the opcode in bytecode.
>
> B<Type> | B<Description>
> -----------------------------------------------------------------------
> u1 | This line usually shows the opcode for the instruction
> u1 | A "u1" field is an unsigned 1-byte integer field
> u2 | A "u2" field is an unsigned 2-byte integer field
> u4 | A "u4" field is an unsigned 4-byte integer field
> s1 | A "s1" field is an signed 1-byte integer field
> s2 | A "s2" field is an signed 2-byte integer field
> s4 | A "s4" field is an signed 4-byte integer field
> -----------------------------------------------------------------------
>
Camel III goes to great pains to differentiate Perl's bytecode (which would
be more or less how it is described above - the instructions as laid out in
a {whatever we call it} file) from the parse tree (the tree of opcodes that
are actually run), which seems to be what the rest of the document sort of
covers.
>From a design perspective, are they (bytecodes and opcodes) different, or is
it simply a structure (linear vs tree, for instance) distinction? Would
the above cover the execution engine, the data dumper/restorer, or both?
Secondly, we had talked at one point of actually writing an "assembly
language" for Perl 6 as a way of testing opcode flow independent of Perl 6:
The Language. (As a way to develop the two halves in relative(!) isolation.)
That was early on, but is it still the case? Are these two concepts we want
to merge, or keep separate?
--
Bryan C. Warnock
[EMAIL PROTECTED]
