On Fri, 2001-09-14 at 15:42, Dan Sugalski wrote:
> At 03:10 PM 9/14/2001 -0500, Brian Wheeler 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 :)
> 
> Nope. At the very least, a bytecode file needs to start with:
> 
> 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.
> 
> Followed by the offsets to the various segments in the file. The directory 
> (basically the offsets) *must* be at the very beginning, right after the 
> header.
> 
> Also, don't choose a stream format that makes writing the file easy--choose 
> one that makes reading easy and fast. Two or three passes before writing 
> are fine.
> 


And...in another message....

> Heh. Doing our bytecode files in IFF format would be really nifty. We 
> could even see about raiding the old Fred Fish library for C source to 
> read and write 'em... :)

Fred Fish...that's a name I've not heard in a long time.  I still have a
floppy or two with "fish disk ###" stuck on them.

Ok, I'll admit I was initially considering IFF but it seemed too
scary...but then it could be residual feelings from when I was a
youngster and tried to write them with BASIC :)

Ok, what if we did IFF with these caveats:
        * all chunks must be padded to 4 bytes (instead of IFF's 2)
        * no nesting of FORMs 

Chunks we'd need are:

Name:           'PINF' - Parrot Information
Size:           28 bytes + size of directory
Optional:       No
Data:
        long            magic cookie (or will PINF) be enough?
        8-byte word:    endianness (magic value 0x123456789abcdef0)
        byte:           word size
        byte[7]:        empty
        word:           major version
        word:           minor version
        long            count of directory entries
        --- directory goes here ---
        -- each entry as follows --
        long            type of chunk
        long            offset


Name:           'PBYT' - Parrot Bytecode
Size:           Varies
Optional:       Sure. :)
Data:
        bytes of the bytecode


Name:           'PSTR' - Parrot String Table 
Size:           Varies
Optional:       Yes
Data:
        long            Count of string entries
        --- each string as follows ---
        long            byte length
        n bytes + pad   string data


Name:           'PFIX' - Parrot Fixup Table
Size:           Varies
Optional:       Yes
Data:
        --- beats me...how are we doing fixups? ---


Name:           'PNOT' - Parrot Notes Block
Size:           Varies
Optional:       Yes
Data:
        free-form text for 'notes' about the file.




How's this?

Brian

Reply via email to