Subject: RE: [sv-cc] extern/export function declarations
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Wed Mar 05 2003 - 08:33:45 PST
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]
> Sent: Wednesday, March 05, 2003 6:44 AM
> To: sv-cc@server.eda.org
> Subject: [sv-cc] extern/export function declarations
>
>
> 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.
> 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 - 08:34:23 PST