[EMAIL PROTECTED] writes: > Mike -- > > Thats a lot of metadata. Sounds like maybe the metadata is primary > and the bytecode is secondary, in which case perhaps what you > really want is a (metadata) tree decorated with bytecode rather than > a (bytecode) array decorated with metadata.
The bytecode is primary. This is whats get executed, this is what needs too be fast (both in startup time and runtime). Some kind of data is necessary for the bytecode, such as the string constants. These need also be accessed fast (don't know if this is called metadata, this is more data). The metadata is only needed in rare cases e.g. debugging, so it doesn't need to be as fast (but even here speed is nice) > Of course, the most natural candidate for the metadata would be the > annotated (file & line, etc.) parse tree, or some approximation to it > after compilation-related transformations. > > I can imagine a process that loads the tree, and linearizes the > bytecode with the metadata consisting of backpointers to nodes of > the tree, either in band as escaped noop-equivalent bytecode or > out of band in an offset-pointer table. Bytecode reading must be fast. Ideally it is mmap and start. Treewalking for bytecodegeneration should be done by the compiler. > With a suitable amount of forethought on the tree representation, > you should be able to have good flexibility while still having enough > standardization on how tree-emitting compilers represent typical > debug-related metadata (file, line, etc.) that debuggers and other > tools could be generic. The tree metadata can sure be some kind of intermediate output of the compiler (the output of the compiler front end), but normaly this should be fed into a backend which generates fast running bytecode or even native code. 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
