Subject: Re: ISSUE:DirectC:How to find C/C++ code ???
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Nov 07 2002 - 17:12:17 PST
> From Michael.Rohleder@motorola.com Thu Nov 7 07:05:56 2002
>
> Comments interspersed.
Likewise..
> 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.
Others mentioned there may be aa ANSI standard coming for that.
> > 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?
Don't understand the question.
> > 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.
>
Non-global I want to implement as C++ style virtual 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?
The aim of this commitee is to build the bridge between C/C++ and SV, for that
you need a definition of what each looks like in the other's language.
Kev.
> > 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 - 17:13:06 PST