On 23.10.2012 20:46, Florian Weimer wrote:
* Peter Colberg:I quickly gave up that idea, since GCC uses non-standard extensions for the AST itself, which I honestly did not grasp yet. In particular, I have no idea what the GTY(â) constructs translate to in the AST.They are markers which are used to generate metadata for the garbage collector. They translate down to standard C for regular compilation.
... and as such (if I understand them enough), they are the only declarative source of hints needed for proper tree interpretation/walking (but most GCC parts do not need them, because they have the same knowledge hardcoded).
Further, changing a single variable (asm_file_name = HOST_BIT_BUCKET) would have meant the generation of large structs for ffi.cdef, only to access one field in a struct of structs. After this experiment, I was very glad to leave it at using the Lua C API for this task.A lot of the API consists of preprocessor macros, so it's not directly usable. And GCC 4.8 has switched to C++, so automatically generating a binding has become even harder.
All GTY hints, macros/inline functions actually represent the knowledge of the actual Tree memory interpretation beyond the node types C structs, right?.
What is your opinion - How would be seen across the GCC developers a documentation effort for extracting these bits from the source up to full declarative definition (which as a side effect, should be enough for generation of equivalent LuaJIT code for random Tree memory format reading/writing, which in turn should make the projects with goals similar to Interaspect gcc plugin more easily supportable being written in LuaJIT)
Kind Regards, Alek
