> On Sat, 2014-01-11 at 04:08 +0100, [email protected] wrote: > > 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)?
Yes, no restriction here as soon as they use the same ABI. In grt-cvpi.c there is an OS independent way of loading DLL/DSO. > 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... Yes. I think VHPI has a method to specify the DLL dependencies. > 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) Very difficult to me. For example, the type representation for non simple types is different in GHDL and in GNAT. Looking for good ideas (beyond accessing via VHPI). Tristan. _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
