After reading various posts about the bytcode file format it occurred to me that we need to determine what we need :) Meta-information: * Magic cookie * version * endian/size markers * index of all chunks for fast lookup Things we need to store: * bytecode * external symbols/list of modules required * public symbols * source code * raw data (think: predefined PMCs, DATA sections ,etc) * other stuff :) So, in the spirit of KISS, what about this format: Offset Size Description 0 4 Magic Cookie 'PAR0' 4 8 Endian mark (0x0123456789ABCDEF) 12 4 Version (Major * 0x10000 + Minor) 16 4 Size Marker 20 12 Padding/Reserved for future use 32 n Index (n=# of entries * 16) 32+n m Data blocks, stored sequentially Each index entry 16 bytes, and is laid out like:: Offset Size Description 0 4 Type (bytecode, comment, source, fixup, etc) 4 4 ID (to differentiate blocks of the same type) 8 4 Offset (offset from beginning of file of data) 12 4 Length (in bytes) Block IDs are used when we need to differentiate between different blocks of the same type, i.e. constant data or multiple sets of bytecode in the same file as in libraries. Given this overall format, the format of each data block varies depending on its type. Type_id Name 00000000 Ignore/Empty/Invalid - This block is ignored 00000001 Bytecode 00000002 String Constants 00000003 External Symbols 00000004 Public Symbols 00000005 Source Code 00000006 Debugging Info Thoughts on *this* can of worms? Brian
