Dan Sugalski wrote:
Since it looks like it's time to extend the packfile format and the in-memory bytecode layout, this would be the time to start discussing metadata. What sorts of metadata do people think are useful to have in either the packfile (on disk) or in the bytecode (in memory).I'm currently simplifying the whole packfile routines. It still does read the old format, but the compat code is centralized now in one place.
The main change is now this structure:
struct PackFile_funcs {
PackFile_Segment_new_func_t new_seg;
PackFile_Segment_destroy_func_t destroy;
PackFile_Segment_packed_size_func_t packed_size;
PackFile_Segment_pack_func_t pack;
PackFile_Segment_unpack_func_t unpack;
PackFile_Segment_dump_func_t dump;
};
All registered types define these funtions to make pack/unpack/dump work for their type.
Registered types are consecutively numbered, unknown types still get unpacked or dumped:
typedef enum {
PF_DIR_SEG,
PF_UNKNOWN_SEG,
PF_FIXUP_SEG,
PF_CONST_SEG,
PF_BYTEC_SEG,
PF_DEBUG_SEG,
PF_MAX_SEG
} pack_file_flags;
All packfiles sizes/offsets are in opcode_t not bytes for simplicity - though this might need a conversion (but we don't seem to handle wordsize transforms now anyway).
leo
