Subject: Re: [sv-cc] integrating directC code
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Tue Jan 28 2003 - 14:17:19 PST
> 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:18:06 PST