On Tue, 2002-10-29 at 11:48, Brent Dax wrote: > [EMAIL PROTECTED]: > # > Well, on thinking a bit about this, there's no reason that > # we have to > # > worry--it's perfectly OK for us to declare, unconditionally, that > # > segment 0 is always bytecode, 1 line number info, and so on, with > # > everything after position X (for some value of X) left up > # in the air. > # > A bit dodgy, true, as it means that any new known segment > # types we add > # > in will be floating, but I don't think we're going to end > # up with too > # > many performance-critical pieces in the bytecode. (Arguably > # it's just > # > the bytecode itself, the symbols, and the constants, as the > # rest are > # > looked at under exceptional circumstances or on (rare) demand) > # > # *No* > # > # This really kills extendability, or makes it at least very > # ugly. It needs to prealloc a certain number of segments. Each > # of this has a fixed semantic. Extending means consuming on of > # the preallocated fields, or using some segment beyond the > # preallocated area but then it needs a type field. In fact the > # preallocated segments also have a > # type-field: the position in the packfile. > > How about this structure: > > HEADER > SEGMENT 0 > CHUNK 0 (DIRECTORY) > SIZE: > DATA: > CHUNK 0 ENTRY > TYPE: DIRECTORY (type 0) > OFFSET:
Is this really necessary? Seems like a chicken-and-egg thing: to know which chuck the directory is in, you need to read the directory. However, since you've defined that the first chunk (0) is always the directory, there's really no need to have it in the directory since you know it has to be the first chunk. Out of curiosity, would I need a separate segments if I was going to have multiple versions of the program (say, one debugging and one optimized) in the same file? It looks that way. Will the segment/chunk ids's be consistent between builds & how do I know what they will be in advance (for dynamically loading the 'debugging' version on demand) ? Brian
