At 03:47 PM 10/2/00 -0500, Jarkko Hietaniemi wrote:
> > 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
>
>This version info could quite naturally live in my proposed 'declaration
>block' or 'bytecode header'.
Works for me.
> > 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
>
>Ouch, too true...
I kinda like the ascii encoding scheme for floating point numbers, though I
could see going for two different ones--binary and decimal, for folks who
do have decimal floats.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
- data storage and representation when designing bytecode ... Jarkko Hietaniemi
- Re: data storage and representation when designing ... Dan Sugalski
- Re: data storage and representation when design... Nicholas Clark
- Re: data storage and representation when design... Jarkko Hietaniemi
- Re: data storage and representation when de... Dan Sugalski
- Re: data storage and representation when designing ... Nicholas Clark
- Re: data storage and representation when design... Jarkko Hietaniemi
- Re: data storage and representation when de... Nicholas Clark
- Re: data storage and representation whe... Dan Sugalski
- Re: data storage and representatio... Nicholas Clark
- Re: data storage and represent... Dan Sugalski
- Re: data storage and representation when de... Dan Sugalski
- Re: data storage and representation whe... Joshua N Pritikin
- Re: data storage and representatio... Dan Sugalski
- Re: data storage and representation when design... Dan Sugalski
