On Sat, 2014-01-11 at 04:08 +0100, [email protected] wrote: > > Hi ! > > > > Le 2014-01-10 21:08, Brian Drummond a écrit : > > > Another user routinely links to C code (and I have linked to Ada) > > > using > > > the VHPI interface; as the mcode compiler supports neither of these > > > languages, the gcc version is essential to him. > > > > According to Tristan, support of external dynamic libraries is just a > > matter > > of dlopen/dlsym. Greate ! Now, it's only half of the equation because > > I > > have > > no idea of where to put these system calls :-D > > See ghdlrun.adb: Foreign_Hook. This function is called for each foreign > subprogram, and return the address of the foreign routine. That's where > dlopen/dlsym should be added.
Would this work with any external .DLL (.SO) built using regular compilers (gcc, gnat, maybe MSVC, etc)? If so, presumably we need some way of specifying the external DLL dependencies (command line option). Then the same approach should work for both mcode and gcc... My problem with VHPI as designed is that, being originally C-oriented, it supports an impoverished set of types allowing serious errors in the external code. There are "DPI" proposals for the next revision of VHDL that look like they may be making the same mistake. I wonder if there could be a way of better communicating type information across the VHPIdirect interface, so that foreign code could use type info where practical, or ignore it if C-style) - Brian _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
