Subject: RE: [sv-cc] extern/export function declarations
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Wed Mar 05 2003 - 09:31:34 PST
> From: "Warmke, Doug" <doug_warmke@mentorg.com>
>
> Francoise, SV-CC,
>
> A couple embedded comments.
> (I don't fully agree with Francoise's suggestions)
>
> Regards,
> Doug
>
> > -----Original Message-----
> > From: Francoise Martinolle [mailto:fm@cadence.com]
> >
> > In preparation for the meeting today, I put together what I
> > would like the
> > extern/export
> > declarations to be
> >
> > For providing function prototypes for external functions, I
> > like to have:
> >
> > a) matching the syntax of extern methods in classes.
> > If you really want to use the import keyword I would
> > prefer import
> > extern
> > to mean importing a function from an external language.
> > b) the full prototype required
> > c) the extern declaration can appear multiply in any
> > declarative scope
> > but at least an
> > extern declaration is required in the scope where SV
> > calls the C
> > function.
> DOUG: I see no reason for the complexity of c).
> It is hard to implement, hard to describe correct rules,
> and offers almost no advantagre to users.
I think $root and module scope would do, but you certainly need
to be able to multiply define extern declarations or you have
to start using pre-processor directives to avoid errors.
Kev.
> > d) extern declaration equivalence checks done by the SV compiler
> > e) an alias declaration used separately (because using a cname =
> > SVfunction_name is not
> > an alias declaration but a new syntax for aliasing names; we
> > need to reuse
> > the already designed components of the SV language and not
> > reinvent another
> > way of doing it.
> > The alias declaration must be in the same scope as the extern
> >
> > extern [pure|context] function return_type SVfunction_name
> > (ansi-style
> > arguments with mode, type, argument names and default value);
> > alias cname = SVfunction_name;
>
> DOUG: In my mind, the [cname=] is not equivalent to the existing
> alias. Here we are fooling around with linker-visible symbols.
> The "scope" of cname= is not the same as the "scope" of alias.
> In fact, other SV code can't make use of the cname at all,
> unlike with alias. I would vote we stick with cname=.
>
> >
> >
> > 2 extern declarations are equivalent iff:
> > . their signature are identical (both parameter types and
> > result types
> > of the respective 2 extern
> > declarations must be identical)
> > note: is it lexically identical or statically identical.
> > for example, an integer number (3) can be used
> > to specify the
> > left range in one
> > declaration and a binary
> > value 2'b11 could
> > specify the left and right ranges of the
> > other declaration, or even a
> > parameter
> > which value is 3.
> > . the number and order of the parameters is identical
> > . the name of the parameters can differ and are
> > optional, they are all
> > required if SV calls by name
> > and the names must match the names in the visible
> > extern declaration.
> > . default values are identical.
> DOUG: The above is a lot of complexity that can be avoided
> by not supporting c) above.
>
> >
> > For the export declaration, if the export declaration has to
> > be in the same
> > scope as the SV function declaration then no need for full
> > path name or
> > prototype.
> > If I want to be able to put the export anywhere in the
> > design, I need the
> > instance pathname and full prototype because this would help
> > in generating
> > the C code to call the SV function (allocation of space
> > for passing actual values to the SV function must be done in
> > C, the return
> > value of the SV function
> > may be used in the C code).
> > If the full prototype is given, then we must define the
> > equivalence between
> > an export and the real
> > function declaration and between 2 exports.
> > The advantage of being able to put the exports anywhere and
> > in particular
> > to put all of them
> > in a separate verilog file allows to change your C
> > application which would
> > call additional SV functions without having to recompile the
> > module which
> > contains the called SV function.
>
> DOUG: This is a reasonable advantage, but still it is difficult
> to get correct and it will be difficult to describe and enforce
> rules. The main problem is the easy ability to export all
> instances of a given module::function. Remember that :: operator
> we used to have? That was ugly and would have required introducing
> a whole new syntax into the language. And as JohnS explained
> yesterday, using hierarchical references to export given instances
> of a function is unacceptable.
>
> My thought on export is that since export functions are always
> declared right next to their definition, why not just do away
> with the declarations all together? Just slap the "export"
> keyword right in front of the function definition, and voila,
> it is exported!
>
> >
> > I like the following syntax:
> >
> > export function fname; // full prototype to be determined)
> > alias cname = function_name;
> >
> > a) we could have export extern to mean export to an external language
> > b) prototype or not depends of where the declaration can be
> > c) a separate alias declaration
> >
> > Francoise
>
> Thanks and regards,
> Doug
>
>
> > '
> >
> >
> >
>
>
This archive was generated by hypermail 2b28 : Wed Mar 05 2003 - 09:32:21 PST