--- Brian Wheeler <[EMAIL PROTECTED]> wrote:
> I've been thinking alot about the bytecode file format
> lately. Its
> going to get really gross really fast when we start
> adding other
> (optional) sections to the code.
>
> So, with that in mind, here's what I propose:
>
> * All data sizes are in longwords (4 bytes) because
> that's just the way
> things are :)
We can't do that. There are platforms on both ends that
have _no_ native 32-bit data formats (Crays, some 16-bit
CPUs?). They still need to be able to load and generate
bytecode without ridiculuous CPU penalties (your Palm III
is not running on a 700MHz Pentium III, after all!)
> * The file is composed of a header (which is really just
> a magic
> cookie) , a series of data chunks, and a directory (of
> sorts)
>
>
> Offset Length Description
> 0 1 Magic Cookie (0x013155a1)
> 1 n Data
> n+1 m Directory Table
> m+n+1 1 Offset of beginning of directory table (i.e. n+1)
>
No, we _really_ need some versioning info (either
major/minor or just a single integer (if we go through even
16000 revisions of the bytecode, we've screwed up
somewhere). As Dan said, we also need a BOM of some sort
and a word size indicator.
I think we certainly want the directory at the front,
especially since we will likely end up with data segments
that we might not want/need to load (e.g. the original
source code, debugging info (?), the optimized parse tree,
etc.). If we have to map in the entire file to find the end
so we can find what parts we don't want to map, that sort
of defeats the purpose.
-- BKS
__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/
