At 12:17 AM 9/24/2001 -0400, Michael Maraist wrote:
>Dan wrote:
> > For bytecode, it's not a big problem, certainly not one I'm worried about.
> > Machines that want 64-bit ints have, likely speaking, more than enough
> > memory to handle the larger bytecode.
> >
>That's not the problem. The problem is protability of the byte-code.
>I've heard various discussions about byte-code-compiling. One of which
>was that it is not considered cosher to let a program compile code and
>write into a "/usr/local/scripts" directory or any such thing. Many
>companies want to be able to distribute "byte-commpiled" code (such as
>with python).
Portability is why we tag the bytecode files with the size and endianness
of things, along with version numbers. That way the interpreter can either
handle things as appropriate or pitch a fit.
>Though I don't know what the powers on high want, are we saying here and
>now that the byte-code is strickly non-portable?
Speaking from on high here, bytecode is strictly identifiable as to its
characteristics. It will be as portable as a platform implementer wants it
to be. The only 'required' types of bytecode that need to be read are
32-bit integer (both big and little endian) with 8-byte IEEE floats for FP
constants. Everything else is optional, though if the code's small I fully
expect we'll ship with a full complement of translators.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
