Subject: RE: [sv-cc] integrating directC code
From: David W. Smith (david.smith@synopsys.com)
Date: Tue Jan 28 2003 - 14:25:58 PST
You have far more serious problems on linking to Windows dlls then just the
extensions. You must define the decl_spec for import/export and for data
sharing (if allowed). This is very different than on Unix. By the way,
dlopen, etc... are not present on Win32 API.
Regards
David
-----Original Message-----
From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Kevin
Cameron x3251
Sent: Tuesday, January 28, 2003 2:17 PM
To: sv-cc@eda.org
Subject: Re: [sv-cc] integrating directC code
> From: "Francoise Martinolle" <fm@cadence.com>
>
> There was some discussion today about how to specify and link the
> directC code. Today there is dynamic shared library mechanism which is
> being widely used to be able to integrate C or C++ code and which is
> portable. It is not complicated to do. I believe that is sufficient
> for our purpose. I am afraid that allowing .o and .a may not be as
> easy as it sounds.
The dynamic loading code (dlopen) was in the example I sent out a while
back.
My proposal did not go further than specifying a library name along with a
routine within SV, e.g. "foo:bar" as a foreign code reference meant routine
"foo" in library "bar" - specifying how "bar" would map to .so,.dll,.a or .o
would be a vendor problem, or an issue for another committee.
> Either the user would have to make the code PIC (position independent)
> and indicate that it is relocatable otherwise here will be a linking
> error on dlopen or if the code has to be linked statically, this would
> have to be indicated as a non PIC object to the tool, the tool would
> have to statically link it with the main program, and re-exec the
> newly formed executable. I really don't think we should standardize on
> a method to link .o and .a files. A standard should concentrate on a
> minimum method that is portable and which provides maximum flexibility
> and leave it up to the vendors to provide additional specific
> user-friendly methods.
I agree that standardizing the linking would be a mistake. C/C++ language
definitions do not include how to do it, and I don't think we should either.
> Andrzej also mentioned allowing the C source and object code to be
> located in the same directory as the module which uses it. I believe
> that this is also a matter of convenience for some users and we should
> not standardize this specific way.
I agree again, this is only likely to be true in the simplest of cases.
> Andrzej 's other idea was to (if I understood it correcly) to use the
> -y-v flags for verilog library and file search to also apply to C
> libraries and source file. First I would like to note that these
> options are not specified in the Verilog 1364 standard, second that
> they are overly complicated and disliked by some users. Provided we
> specify a way to distinguish between a verilog library and a C
> library, I would not want to overload the semantics of these options
> with looking for C source code. No standard body can standardize on a
> set of tool switch names. Some shells may not accept arguments which
> start by a - or a +. This is not portable. A standard can say that
> certain switches may be provided to indicate a shared library list
> name for example.
>
> Francoise
> '
I think the only thing we need to specify is a "mapping file" that tells the
SV compiler what routines come from what library/object-file and where to
find it. Generating the object files and libraries is a job for "make". E.g.
something like the following you can run through cpp for machine/vendor
dependencies and use with make:
// SV code mapping
Function "foo" is in "bar"
#ifdef __Unix__
Library "bar" is "$(MY_DESIGN)/libbar.so" needs "common"
Library "common" is "$(COMMON_CODE)/libcmmn.so"
#else
Library "bar" is "$(SOMEWHERE)/bar.dll"
#endif
You would give mapping files rather than the object files to the SV
compiler. It would be up to the vendors whether or not they execute "make"
(or an equivalant) to create missing objects.
Regards,
Kev.
This archive was generated by hypermail 2b28 : Tue Jan 28 2003 - 14:25:26 PST