At 07:21 AM 10/2/00 -0500, Jarkko Hietaniemi wrote:
>[random thoughts I had one week ago at YAPC::Europe and am jotting down now;
> was unsubscribed from the p6 lists during that time, awfully sorry if this
> subject has already been beaten to death]
We haven't touched this yet. Bytecode's on the list of things to get beaten
to death soon. (I hope, otherwise folks will have to make do with what I
plan on... :)
>When designing the bytecode of Perl 6 special care and planning should
>be directed towards data storage and representation. In more concrete
>terms, we should have bytecodes for example for
>
> newpvn
> newiv
> newuv
> newnv
> newav
> newhv
> newrv
>
>(using perl5ish terms like pv here just for the sake of clarity;
>whether those terms carry over to perl6 remains to be seen). The
>above list is not complete and it is there just for the sake of
>discussion.
Absolutely, yes. And the bytecode for the variables also needs to encode
attributes, name, and scope.
>Having such bytecodes available is essential for the proposed
>functionality of dumping the state of a live and running Perl virtual
>machine and breathing life into that later.
Or bits of it. Can't serialize objects without being able to do that...
>The knowledge gathered from writing the modules Storable,
>Freeze::Thaw, and Data::Dumper, should be studied very carefully.
>Of course also the other bytecodes like JVM, Emacs Elisp, and so on,
>should be researched. For example, have there been any backwards
>incompatible format changes? If so, why? What forced that change
>and how can we try to avoid such embarrassments?
Yep, that's something to investigate. I'd like to encode the bytecode
version at the head of any bytecode stream. There's also been a request for
creator tags in the bytecode. ('Creator' here being the version/tag of the
lexer&parser, bytecode creator, and optimizer)
>The data created by the bytecode should be stored in a binary format
>for speed and compactness. (At least so far) Perl's approach to data
>portability issues like integer width, character encoding, and
>floating point format has been 'do the what comes naturally for the
>current runtime platform', as opposed to Java's strict specification
>that e.g. an int is 32 bits, and floats are IEEE 32-bit. There are
>benefits to this approach, but I think it's wrong.
I agree, platform native is a good idea generally, as long as we have some
means of indicating how the platform encodes the data. The bytecode needs
to be transportable across platforms--I want the same bytecode to be able
to run on a VAX, x86, Alpha, and PowerPC box.
Also, transportable floats are rather problematic. It's one thing to tag an
integer with size and endianness. It's rather another to deal with floating
point formats. I have at least six available to me on my Alpha box, and who
knows how many elsewhere. I'd rather not have to have code to deal with all
of them in everyone's perl. (Of course, I'm not sure what the alternative
is...)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
