Subject: DirectC: proposals for Open Issues 1.2, 1.3, 1.8, 1.9, 1.10.
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Wed Nov 27 2002 - 13:17:51 PST
Hi,
Enclosed are the proposals for the remaining open issues:
1.2
1.3
1.8
1.9
1.10
"Added Comment"-s come from the original issues.
Regards,
Andrzej
--------------------------------------------------------------------------------
Issue 1.2 A DirectC external C function should override a built-in
C function by the same name.
--------------------------------------------------------------------------------
Added Comment:
DirectC should have an explicit provision that allows user to write an external
C function that overrides a system provided function of the same name.
This will give a user complete independence to re-write, for example, cm_*().
This will be similar to the way a user-defined function $random overrides
the system function by the same name in PLI.
--------------------------------------------------------------------------------
I propose to add the following rules for the names of external functions,
in addition to the rule 5b, issue 1.6:
a) a name of external function must not start with '$' sign.
The above restriction exludes overriding system tasks in SV code.
Otherwise the new rules would be needed for resolving name conflicts
between external functions, PLI functions and system functions and
tasks.
b) with the above exception, any legal C name may be used for an external
function, including all names used in API-s for SV or any other library.
It would be user's responsibility to assure the desired linking.
Note that the above is consistent with C rules; in C the user
is free to redefine any library function.
The above addendum to 1.6 seems to close this issue.
--------------------------------------------------------------------------------
Issue 1.3 Name resolution between a Verilog task and a DirectC external C
function.
--------------------------------------------------------------------------------
This issue is addressed and resolved by the rules 6a and 6c of issue 1.6.
I propose to close this issue.
--------------------------------------------------------------------------------
Issue 1.8 Distinguish C and C++ code
--------------------------------------------------------------------------------
Added Comment:
This is actually not an issue, more a brainstorming proposal:
It would be nice to be able to distinguish C and C++ functions when defining
DirectC functions.
--------------------------------------------------------------------------------
In my opinion such distinguishing would be pointless.
There is no standard name mangling for C++ functions nor standard protocol
for C++ function calls.
SV compiler could perhaps support C++ function calls for a particular revision
of a particular C++ compiler, but then the coupling of SV compiler with one
version of C++ compiler will defy the requirement for binary compatibility of
the interface.
So, hence the SV compiler won't be able to support a nonexisting generic
protocol for C++ functions, the required distinguishment will be useless.
I propose to close this issue.
--------------------------------------------------------------------------------
Issue 1.9 How to find C/C++ code ???
--------------------------------------------------------------------------------
Added Comment:
This is actually more a question than an issue. Do we need to define how C/C++
code is being found/linked?
--------------------------------------------------------------------------------
The issue how to find C/C++ code is not specific to DirectC whatsoever.
This is a general issue common for all API-s and for any instance of user's
C/C++ code, be it VPI, PLI or DirectC.
Michael proposed that OMI (IEEE-1499) solution may be followed - one bootstrap
file that tells where to find the rest.
I propose to accept the following partial solution and to leave the rest to
the vendors of SV implementations:
a) The location and the names of files containing the C/C++ components of SV
design default to the basic file names (with appropriate extensions
like .c, .cc, .h, .hh, o, .a) of their SV counterparts source files
and to the same directories.
Therefore for any processed SV source file, all files from the same
directory and with the same basic name will be assumed to contain the
related C/C++ code (in a source, object or library form).
Such files will be included automatically in the compilation and
link-edit process.
b) All other user's files must be explicitly specified by the user.
The ways to specify the directories and source or binary or library file
names are tool specific.
For example, VCS allows to provide .c file names in a command line and
allows to provide options for C compiler or linker via command line flags
-CFLAGS, -LDFLAGS.
Should the team decide that LRM shall specify a complete mechanism for looking
for C/C++ code, I propose to pass such request to the basic committee.
The requested mechanism might become a part of a configuration.
Note that it would be nice to have a uniform mechanism for searching both
the SV libraries and C/C++ libraries. That's why I propose to resort to the
basic committee.
There is a related issue (sub-issue) of providing means for associating
the relevant C/C++ code with library modules.
Library modules may use external C/C++ code. Hence a library module source code
will actually consist of two parts: its SV part and C/C++ part.
The C/C++ component of a library module may have a form of a source code
or of an object file, or be a part of a binary library (or be empty).
I propose to add the following optional convention for library modules files:
c) Library file naming convention (optional)
The C/C++ component of a library module shall have the same basic name
(though with appropriate extension like .c, .cc, .h, .hh, o, .a)
as a library module source file and should be in the same directory
(with the exception of standard C/C++ libraries).
For example, if 'library/foo.v' contains SV source of a library module,
than files 'library/foo.*' [with appropriate extensions] are considered
to be related to that module.
--------------------------------------------------------------------------------
Issue 1.10 cmodules vs. external "C" tasks
--------------------------------------------------------------------------------
I propose to remove this issue from 3.1 timeframe considerations and move
it to 3.2.
This issue was entered in the context of "C" tasks.
It was proposed to consider both mechanisms before digging into "C" tasks, because
those two mechanisms seemed orthogonal and probably equivalent.
Since "C" tasks didn't make into 3.1, I propose to close this issue for now.
--------------------------------------------------------------------------------
This archive was generated by hypermail 2b28 : Wed Nov 27 2002 - 13:19:22 PST