Subject: RE: [sv-cc] Polls on extern/export and representation of SV data types
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Thu Mar 06 2003 - 22:27:14 PST
Team,
Here is Joao's proposal, and my [DOUG:] suggestions
for clarifications and corrections. I will get all
this into the Frame LRM drafts (with change bars)
and send it out on the weekend. Andrzej, once I
send out the goods, please make sure to edit them
down and get them to the hands of the new LRM editor.
(Thanks)
Regards,
Doug
========================================
Proposed solution
========================================
At any scope where a function declaration can occur, permit the following
declarations:
extern "DPI" [pure|context] [cname=] <named_function_proto>;
export DPI [cname=] function fname;
[DOUG: The DPI above should be enclosed in " ".
Also, since there is no [context] attribute for export functions,
are we assuming that all export functions are always [context]?
If so, that should be clearly stated. I think it's a valid
assumption, since non-context export functions don't make sense.]
This syntax does not require any new keywords: "DPI" is a string qualifying
the type of extern/export. For SV3.1 only the string "DPI" is valid.
Note that the <named_function_proto>, as defined in SV3.1 draft3 spec (page
233)
must be modified slightly so that the argument list permits open arrays.
Only
extern DPI functions can use this argument type. We may additionally also
want to relax the prototype syntax to permit unnamed arguments, but this
will
be harder to sell to sv-ec.
Semantics:
----------
in both cases, cname is the name of the C side function (extern/export),
fname is the SV name for the same function.
If cname not explicitly given, it will be the same as the SV function fname.
An error will be generated iff the SV function name has characters that are
not valid in a C function identifier.
For any given cname, all declarations, regardless of scope, *must* have
exactly
the same type signature. The type signature includes the return type, the
number,
order and types of each and every arguments. Type includes dimensions and
bounds of
any arrays/array dimensions. Signature also includes the pure/context
qualifiers
that may be associated with an extern definition.
Only 1 extern declaration (extern or export) of a given fname is permitted
in
any given scope. More specifically, for an "extern", the extern must be the
sole declaration of fname in the given scope. For an "export", the function
must be declared in the scope where the "export" occurs and there must be
only one "export" of that fname in that scope.
Argument names and default values are permitted to differ between "extern"s
declared at different scopes *as long as* the type compatibility constraints
are met.
For exported functions, the exported function must be declared in the same
scope
that contains the "export extern" declaration.
Note that DPI functions declared this way can be invoked by hierarchical
reference
the same as any normal SV function.
This:
a) uses consistent syntax with other similar SV 3.1 constructs
b) permits straightforward extension later to extern/exported tasks
c) permits all information needed by DPI coder to be put in the scope
where such usage occurs.
d) by permitting extern/export declarations to be inside module scope,
this simplifies (permits) use of DPI inside library modules using just
normal library resolution mechanisms.
e) allows for later extension of DPI to handle tasks (if such is ever
necessary)
without syntax conflict with existing usage
f) permits later extension to address other interfaces (eg "extern VPI
function $foobar;")
without syntax conflict with existing usage
g) use of extern/export is more symmetrical and was recommended by sv-ec and
by
Friday's all-committees meeting.
NOTES:
1) do not need to put function prototype along with the export because
export has to
occur in same scope as the function definition being exported.
2) extern/exports can occur anywhere where function declarations can occur.
However
note that exports must be in same scope as the function being exported.
[DOUG: This is an important point, which boils down to the three main
locations mentioned in the "gnarly thread": module, program, and interface
items.
We should make it clear that extern and export declarations are ONLY allowed
in these scopes, and nowhere else.]
3) clarified some of the rules regarding the prohibition of multiple
extern/exports
in a single scope (prohibition is only with respect to a given fname)
This archive was generated by hypermail 2b28 : Thu Mar 06 2003 - 22:27:48 PST