At 11:27 AM 5/22/2001 -0400, Bryan C. Warnock wrote:
> 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?
They're definitely different.
>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?
We're going to develop an assembly language. Like so many others, it'll
basically be a human-readable version of the machine code. (Bytecode in
this case) Dunno about anyone else, but I've gotten a bit old to be
decoding hex dumps on the fly. (Plus I end up trying to turn 'em into 6502
assembly, and that's generally the wrong thing these days... :) Perl might
not have as fully-featured an assembler as you may find on other platforms,
but it will work.
Having an assembler may also make it easier for folks to write front ends
for perl--they can just spit out a text representation of the bytecode they
want, and we can build it for them. (Presuming that building the actual
binary bytecode is at all tricky, which I hope it isn't)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
