At 01:56 PM 9/14/2001 -0700, Hong Zhang wrote:
> > 8-byte word: endianness (magic value 0x123456789abcdef0)
> > byte: word size
> > byte[7]: empty
> > word: major version
> > word: minor version
> >
> > Where all word values are as big as the word size says they are.
> >
> > The magic value can be something else, but it should byteswap such that if
>
> > you read it in you can tell whether it was a big-endian write or a
> > little-endian write.
>
>Since the magic value can tell the endian, there is really no need
>for the endianness field.
The magic value *is* the endiannes field. It's doing double-duty. (Or,
rather, what I mentioned was the value that went into the endianness field)
>Personally I don't like the word size concept. I prefer we use fixed
>4-byte word. If we support multiple word size, each runtime have to
>deal with several bytecode data format, 2, 4, 6, 8-byte word. I believe
>the 4-byte word will be 99+% of all practical use. We should let minority
>convert it, instead of asking every runtime to handle every thing.
There's a one-off conversion penalty at bytecode load time, and I don't
consider that excessive. I want the bytecode to potentially be in platform
native format (4/8 byte ints, big or little endian) with a simple and
well-defined set of conversion semantics. That way the bytecode loader can
manage it quickly, and the external conversion tool (To change between
types) can deal with it simply as well.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
