At 03:18 PM 10/3/00 -0400, Joshua N Pritikin wrote:
>On Tue, Oct 03, 2000 at 02:37:13PM -0400, [EMAIL PROTECTED] wrote:
> > At 12:27 PM 10/3/00 -0500, Jarkko Hietaniemi wrote:
> > >Serializing an optree is rather tricky especially if one wants to
> > >deserialize it on a different platform. Because of icky things like
> > >structure padding one effectively really needs to go the way of
> > >*byte*codes which makes for one ssslllooowww VM.
> >
> > Nah, it doesn't need to be that slow. There are a number of things we can
> > do to speed it up a bunch over the current way of doing things (which is
> > suboptimal). I don't see any reason why we shouldn't be able to
> > significantly speed up program loading, especially if we have async I/O
> > available.
>
>Can someone explain why we can't have a non-portable "byte-code" or
>"precompiled representation" in addition to a portable byte-code?
There's no reason the bytecode can't be both. If the bytecode streams have
a set of attributes tacked on (int size, pointer size, endianness and such)
we can have the bytecode loader check the header info and convert if need
be, but if things match the platform native stuff then that's great and we
don't convert.
Bytecode would be saved off with the platform native bits, so reloading it
on the same platform would be fast. (Possibly as fast as just mmaping the
file in, or slurping it bodily into one big buffer and doing some pointer
fixups)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
