Hi Brian and all,
>> >> 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. I'd consider DLL calling from mcode rather hot. Had been thinking about this before I moved to the cross compiler quirk to produce EXEs for MS Windows. > > Would this work with any external .DLL (.SO) built using regular > compilers (gcc, gnat, maybe MSVC, etc)? > In theory I'd say yes, I've written some plugin code in th past to wrap DLLs (using the windows counterparts LoadLibrary() and GetProcAddress()) but it can get quite nasty under Windows with the calling conventions among different compilers. Pardon my bluntness, but there is a big calling standard mess on the windows side, depending on which compiler you use. Can be solved with documentation and possibly configuration flags though. > 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) > I don't really have the insight, but I don't really care so much about a VHPI compliance. As long as structures don't break, a lot can be solved using run time type information, the interesting question now would be how to store the interface information inside the VHDL code (Attributes?). Where do you see the weak points in particular? In my opinion, the only thing that might need some specification work is direct access via pointers to access types or nested structures. On the other hand, this direct access it not too crucial, for example, a RAM implementation could be hacked in C instead, just emulating the I/O by function calls from the VHDL side (I did it this way in the ghdlex code). Sorry for drifting off a little, maybe we should open another thread on the VHPI topic? Greetings, - Martin _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
