Juergen, I completly agree with you. For my needs, the meta-data does not have to be loaded at the same time at all. I can be in a different file for I care. I just want to know how where we can put it. The Microsoft IL has a whole section on meta-data, and one wonders what Parrot might be doing to address the same issues. excuse my ignorance, I am sure you addressed this, and no I have not read the new pods yet.
> Bytecode reading must be fast. Ideally it is mmap and start. > Treewalking for bytecodegeneration should be done by the compiler. yes I agree, I just want to be able to reconstruct the tree for debugging or reverse engineering (if the compiler that produced the bytecode whats to produce this). I would like to prototype some meta-data storage of my gcc > 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. That sounds great. Normally you dont need this information, I just want to know how I can store it if I *do* need it. The metadata from the c++ that i am extracting even exceeds the size of the sourcecode itself. --- [EMAIL PROTECTED] wrote: > b. -- > > I agree that under normal circumstances the bytecode is primary. > I was observing that as more and more metadata is considered, > eventually its quantity (measured, say, in bytes) could approach > or even exceed that of the raw bytecode. In cases where one > would feel such a quantity of metadata is needed, it may not > always be necessary to get greased-weasel speed-of-loading > (but, see below). > > I understand the the mmap-and-go idea, although it doesn't > always work out even when mmap is available (for example, > prederef requires a side pointer-array to store its prederef > results). Sometimes its mmap-mumble-go (but, see below). > > > Certainly, there is nothing to prevent one from having > the linearized bytecode pregenerated in the PBC file even > when a metadata tree is also present (the tree could reference > contiguous chunks of that bytecode by offset-size pairs). If > you don't care about the tree, you don't process it. If you do > process it, you probably produce an index data structure mapping > byte code offsets to tree nodes for the debugger. I believe > we retain high speed with this approach. yeah, that is the idea. Reflection and introspector require the meta-data, that can be read by special reflection operations. > > > We do need to consider how the metadata makes it from the > compiler *through* IMCC to land in the PBC file. The compiler > needs to be able to produce annotated input to IMCC, and IMCC > needs to be able to retain the annotations while it makes its > code improvements and rendering (register mapping, etc.). > I'm thinking that, too, could possibly be a tree. IMCC can pick out > the chunks of IMC, generate bytecode, and further annotate the > tree with the offset and size of the generated PBC chunk. The > tree can be retained as the metadata segment in the PBC file. Sounds good to me. For me, it could also be a graph in triples formats (subject,predicate,object), and not a tree. This is what I wanted to know, what is defined, and what needs to be defined. Regards, mike ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
