Subject: Re: ISSUE:DirectC:How to find C/C++ code ???
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Tue Nov 05 2002 - 10:41:55 PST
> From: "Michael Rohleder" <Michael.Rohleder@motorola.com>
>
> This is actually more a question than an issue. Do we need to define how C/C++ code is being found/linked?
>
> -Michael
Including extra code libraries is usually managed by vendors compile
scripts. The problem with C++ is that different compilers may use
different name-mangling schemes so the SV compiler may need to know
which compiler is being used for the user's C++ code - I think that
should be handled by the vendors and not the committee (since G++
is common and free I'd take it as the target C++ standard),
attributes may be required in the SV code.
For SV objects like modules and nets the committee would define
class header files with the standard methods and data types for
those objects.
IMO tasks and functions should not be treated differently WRT linking,
i.e. task "foo" and function "foo" would both be "foo" to the linker.
Tasks and functions declared in $root would be global and would have
a predictable (non-virtual) mapping to C++.
Module/interface tasks & functions are similar to C++ class instance
virtual functions, this is because parameterization of the instances may
make the task/function code different and precludes using a single
implementation of the task/function for all instances. In order for
user C++ code to access the tasks and functions the SV compiler would
have to either generate a C++ header specific to the module (a new
class that inherits from the base module definition - see above) with
the extra tasks and functions, or the SV compiler would need extended
to be able to inherit virtual task specifications into module
definitions (there was a previous e-mail on that) as required by the
user (explicit export); IMO both methods are probably required.
NB: Using virtual functions requires strict typing since the code is
assumed correct by construction.
Note: the virtual functions are purely an entry-point into the
simulator, virtual function tables can be generated on-the-fly and
can be mapped into interpreted code, they do not require static
linking. Instances with matching paramaterization may be able to
share method code.
Kev.
This archive was generated by hypermail 2b28 : Tue Nov 05 2002 - 10:42:33 PST