Subject: Re: ISSUE:DirectC:How to find C/C++ code ???
From: Michael Rohleder (Michael.Rohleder@motorola.com)
Date: Thu Nov 07 2002 - 07:07:21 PST
Comments interspersed.
I talked about a different topic. Sorry for the confusion.
Regards,
Michael
Kevin Cameron x3251 wrote:
> > 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.
This issue is not related to name mangling. I am sorry for this confusion.
This is a good hint, I think it falls more in the ballpark of language and compiler dependencies.
And yes, we should not define any name mangling scheme.
> For SV objects like modules and nets the committee would define
> class header files with the standard methods and data types for
> those objects.
I am not sure whether this goes not too far here... This would mean we extend the set of DirectC parameters to complete modules and
connectivity information, does it?
> 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++.
Yes, but what should this tell us? Do you also want to go into the namespace area with non-global functions.
> 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.
So, we have then classes for modules, nets and now also for interfaces. Does this not sound like SystemC II?
> 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 : Thu Nov 07 2002 - 07:07:55 PST