Hi, > > But if adding a fourth "flavour" is possible - in addition to gcc, > > llvm and mcode - > > which would be generation of shared lib of the parser (or anything > > not gcc or llvm specific) > > + corresponding headers for C/C++/bindings-for-your-preferred- > > language, > > then it would certainly be of great help for many synthesis and > > design instrumentation projects > > (there are many in my lab, even if I'm not working on that). > > > > Also YG: such a lib would also certainly be of great help to create > > your virtual machine > > as a new systhesis tool attempt :-) > > > > Tristan: How hard would it be to add such a "shared lib" flavour? > > Creating a binding to the AST, or dumping the AST in XML or JSON > would > be very easy. > > The problem is that the AST is not very stable and change frequently.
If the AST changes frequently, then it's a problem if it's dumped in some format for other tools to parse. Because the tools would be compiled for a certain version of GHDL in mind, but the GHDL version installed on the machine may not be the same. Hence the idea of having the parsing stuff of GHDL being compiled as a library, static or dynamic. Third-party tools would be compiled and linked with that lib. If static lib, no problem, the parser is then embedded in the third- party tool. If dynamic lib, then the tools would be linked the appropriate version of the lib and many versions of the lib can coexist in your system /*/lib/ directory. This is why I think having the possibility of generating a lib from GHDL (at least parser and walk/introspection functions for the AST) would be key for any other third-party tools, independent of them being synthesis / simulation / translation / instrumentation tools / wierd experimental virtual machine emulation stuff. Regards, Adrien _______________________________________________ Ghdl-discuss mailing list Ghdl-discuss@gna.org https://mail.gna.org/listinfo/ghdl-discuss
