Dan Sugalski <[EMAIL PROTECTED]> writes: > 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. I'm fine with a numeric type for the core, and have some extension type with named types if it is a speed issue, but I really dont like this positional approach. BTW: COFF and ELF use named sections. bye b. -- Juergen Boemmels [EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
