Subject: RE: [sv-cc] integrating directC code
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Tue Jan 28 2003 - 14:40:38 PST
> From david.smith@synopsys.com Tue Jan 28 14:22:09 2003
>
> 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
Absolutely, which is why I didn't want to go down the path of describing
how the SV compiler/simulator should drive compilation and linking.
Kev.
> -----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:41:18 PST