Subject: Re: DirectC: proposals for Open Issues 1.2, 1.3, 1.8, 1.9, 1.10.
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Wed Nov 27 2002 - 14:40:58 PST
Andrzej,
Nice drive towards closure of these issues.
My two cents on a couple of these topics is:
1) As per issue 1.9, we should postpone that until 3.2
and perhaps work with Basic like you say. IMO we don't
have enough time left to design a robust mechanism that
will have a long shelf-life into the future.
2) As per issue 1.10, I propose that we drop consideration
of cmodules now in the future. This was brought up in
the previous face-to-face, but we didn't vote on it due
to lack of attendance. Now I propose that we actually
vote on this at the face-to-face next week. Voting
attendance should be good.
Looks like we still have to tackle the big 1.7 and 1.11 issues.
John S's last-minute issue still isn't up on the website, either.
Thanks and regards,
Doug
Andrzej Litwiniuk wrote:
> 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 - 14:42:00 PST