Subject: Re: DirectC: proposals for Open Issues 1.2, 1.3, 1.8, 1.9, 1.10.
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Fri Nov 29 2002 - 05:17:39 PST
Hi all,
first of all let me thank Andrzej for further driving these issues to closure.
There are some comments interspersed plus a proposal at the end of this email.
Regards,
Michael
P.S. Hope all of you enjoyed Thanksgiving and had a good time!
Andrzej Litwiniuk wrote:
> --------------------------------------------------------------------------------
> 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.
Correct, the ISSUE was written at a time it was not yet clear whether we are supporting C++ or not ...
> I propose to close this issue.
AGREED
> --------------------------------------------------------------------------------
> 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?
NO. It is an issue, and we better define it. Otherwise we have different methods,
which might even result in tool dependencies.
> --------------------------------------------------------------------------------
>
> 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.
Correct. And my bad experiences with all this stuff and the tremendeous integration effort we had to make for supporting multiple
HDL simulators within a system is the reason for requesting a standardized method here.
> Michael proposed that OMI (IEEE-1499) solution may be followed - one bootstrap
> file that tells where to find the rest.
I made a remark that this might be one possible solution, nothing else.
> 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.
Hmmm. This assumes that the compilation and/or linking of the C/C++ code becomes part of the simulation process.
THIS IS SOMETHING I DID NOT REQUEST. As a matter of fact I would even request NOT to do so.
There is no point in recompiling C/C++ code, if it has not changed. Also, the C/C++ source MUST NOT necessarily
be available. Someone else might have delivered me a set of C models in object form (somebody else's IP), so I might not
have access to the source.
> 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.
O.K. Let me be a little bit more precise here. I am interested in a standardized method for finding/including the _compiled objects_
resulting from C/C++ compilation. How and whether you do C/C++ compilation, this is a question of the tool and a decision of a
vendor [my only comment on this would be that it is not wise to always require the source code].
On the other side I also don't want to rule out an inclusion of C/C++ source code into the compilation, but in this case I would
make the generation of the intermediate object files transparent to the user.
The problem here is that the SV side only specifies the SV function declaration (which implicitely defines how the corresponding C
function has to look like). Assuming you want to include the corresponding C object code, you need to know where it is (in an
archive, in a shared library) and how to identify the corresponding objects (archives/libraries) in the file system. There is no
direct relationship between the names of the functions defined within an archive/library and the name of this file.
This is a problem specific for C/C++ API's, Vassilios and the DWG chairs have to decide whether the basic committee is the right
place for it.
> 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.
Here is my counter proposal for solving this problem. I wrote it in LRM like style,
because my hope is that something like this will become a section in the LRM.
X.X Inclusion of Foreign Language Code
Foreign Language Code can be provided in form of C/C++ source code or in form
of object code compiled for the actual platform. Supporting the inclusion of C/C++
source code is optional, but most follow the rules and guidelines of this section.
The inclusion of object code is a mandatory feature that must be supported by all
simulators according to the rules and guidelines in this section.
This section identifies
. how to specify the location of corresponding files within the file system
. how to specify the files to be processed (in case of C/C++ source code) or to be
loaded (in case of object code)
. in which form object code has to be provided (as a shared library or archive)
It does not identify
. how C/C++ source code is processed and finally included in a simulation (besides
that this must be transparent to the user)
. how object code files are loaded into a simulation
The inclusion of compiled objects and source code is assumed to be orthogonal and not to be
dependent on each other.
X.X.X Compiled Objects
The compiled object code to be loaded can be defined by one of the following three methods:
1) By an entry in a bootstrap file; this file and its content will be described in more detail below
2) By specifying the library path and name without the platform specific extension with one
instance of the switch -svc_lib <filepath_without_extension>. The application is responsible
to append the appropriate extension for the actual platform.
This switch may be used multiple times to define multiple libraries holding object code.
3) By including the library path and name without the platform specific extension in the list of
entries provided as value of the environment variable SVC_LIBRARIES; this variable uses
the same notation and syntax as the corresponding variables
(e.g. LD_LIBRARY_PATH (Solaris) and LPATH (HPUX))
Every location can be either an absolute pathname or a relative pathname, where the
content of the environment variable SVC_ROOT is used to identify an appropriate prefix for relative
pathnames.
Compiled object code must be provided in form of a shared library or as an archive library having
the appropriate extension for the actual platform. When there exists a shared library and an archive
library in the same directory, the shared library is used; otherwise the directory search order decides
upon the library to be loaded.
In case of multiple occurances of a file with the same name the above order also identifies the
precedence of the search; as a result a file located by method 2) will override files specified by method 3).
Any library must and will only be loaded once.
The bootstrap file has the following syntax:
1) First line: #!SVC_LIBRARIES
2) An arbitrary amount of entry lines, where each line holds exactly one library location and name
using the syntax <blanks><filename_without_extension>.
<blanks> denotes an arbitrary amount of blanks, at least one blank must be specified. The entry
<filepath_without_extension> is equivalent to the value of the switch -swc_lib
3) Any amount of comment lines can be interspersed between the entry lines; a comment line starts with
the character '#' and terminates with a newline
No other means shall be provided for identifying the location and filename of compiled object code.
Example:
Assuming the need to include the following object files into a simulation /home/user/myclibs/lib1.so,
/home/user/myclibs/lib3.so, /home/user/proj1/clibs/lib4.so, /home/user/proj3/clibs/lib2.so this can
be accomplished by:
[assuming SVC_ROOT has been set to /home/user]
a) bootstrap file containing
#!SVC_LIBRARIES
myclibs/lib1
myclibs/lib3
clibs/lib4
clibs/lib2
b) the following list of switches
-swc_lib myclibs/lib1 -swc_lib myclibs/lib3 -swc_lib clibs/lib4 -swc_lib clibs/lib2
c) the environment variable
setenv SWC_LIBRARIES "myclibs/lib1:myclibs/lib3:clibs/lib4:clibs/lib2"
d) Additionally, any combination of the above methods can be used, e.g. by specifying the switches
-swc_lib myclibs/lib1 -swc_lib clibs/lib2
_and_ the environment variable
setenv SWC_LIBRARIES "myclibs/lib3:clibs/lib4"
X.X.X C/C++ Source Code
Similarly the location of C/C++ source code can be defined by one of the following three methods:
1) By an entry in a bootstrap file; this file and its content will be described in more detail below
2) By specifying the file pathname with extension with one instance of the switch -svc_src <filepath>.
This switch may be used multiple times to define multiple source code files.
Additionally, directories holding include files needed for the compilation can be specified by:
3) By specifying the include file directory with one instance of the switch -svc_inc <directory>
This switch may be used multiple times to define multiple directories holding source code.
4) By including the include file directory in the list of entries provided as value of the environment
variable SVC_INCLUDES; this variable uses the same notation and syntax as the corresponding
variables (e.g. LD_LIBRARY_PATH (Solaris) and LPATH (HPUX))
Every location can be either an absolute pathname or a relative pathname, where the
content of the environment variable SVC_ROOT is used to identify an appropriate prefix for relative
pathnames.
In case of multiple occurances of an file with the same name the above order also identifies the
precedence of the search; as a result a file located by method 3) will override files specified by method 4).
The list of directories defined by -svc_inc and SVC_INCLUDES is combined, they do not override each
other.
The bootstrap file has the following syntax:
1) First line: #!SVC_SOURCES
2) An arbitrary amount of entry lines, where each line holds exactly one library location and name
using the syntax <blanks><pathname>[<blanks>':'<blanks><directories>]
<blanks> denotes an arbitrary amount of blanks, at least one blank must be specified. The entry
<pathname> is equivalent to the value of the switch -swc_src. The entry <directories> denotes
a list of directories (<directories> ::= <directory> | <directory><blanks><directories> holding
include files. Each entry directory is equivalent to the value of the switch -swc_inc.
The optional <directories> specification denotes the list of user specific include directories to be
specified for the compilation of the corresponding source code. In absence of this specification
the list of include directories defined by switches -svc_inc and SVC_INCLUDES is used for
the compilation. As such the optional <directories> specification overrides the standard set of
include directories defined by -svc_inc. The directories defined by SVC_INCLUDES will
be appended to the list of include directories defined in this file.
3) Any amount of comment lines can be interspersed between the entry lines; a comment line starts with
the character '#' and terminates with a newline
No other means shall be provided for identifying the location of user specific source code and include files.
There is no need to locate or identify the object code created from these sources; this is under the discretion
of the application, no further user interaction shall be needed to accomplish this. Also the creation of object
code from this source code shall be fully transparent to the user.
Example:
Assuming the need to include the following source files into a simulation /home/user/mycode/model1.c,
/home/user/sysc/model3.sc, /home/user/proj1/code/model3.cc, /home/user/proj3/c_code/model4.cpp.
Additionally, the include directories /home/user/mycode/includes, /home/user/common/sysc, and
/home/user/proj1/util must be referenced.
The C/C++ source code can be referenced by: [assuming SVC_ROOT has been set to /home/user]
a) bootstrap file containing
#!SVC_LIBRARIES
mycode/model1.c
sysc/model3.sc
proj1/code/model3.cc
proj3/c_code/model4.cpp
b) or the following list of switches
-svc_src mycode/model1.c -svc_src sysc/model3.sc -svc_src proj1/code/model3.cc -svc_src proj3/c_code/model4.cpp
The include directories can be defined by [assuming SVC_ROOT has been set to /home/user] any
combination of the following list of switches
-svc_inc mycode/includes -svc_inc /home/user/common/sysc -svc_inc proj1/util
and/or the environment variable
setenv SWC_INCLUDES "mycode/includes:common/sysc:proj1/util"
e.g. also by
-svc_inc proj1/util
_and_ the environment variable
setenv SWC_INCLUDES "mycode/includes:common/sysc"
c) Assuming the bootstrap file
#!SVC_LIBRARIES
mycode/model1.c : mycode/includes
sysc/model3.sc : common/sysc
proj1/code/model3.cc
proj3/c_code/model4.cpp
and the following switch settings
-svc_inc proj1/util
_and_ the environment variable
setenv SWC_INCLUDES "common/includes"
results in the compilation of:
* mycode/model1.c with the include dirs:
mycode/includes common/includes
* sysc/model3.sc common/sysc with the include dirs:
common/sysc common/includes
* proj1/code/model3.cc with the include dirs:
proj1/util common/includes
* proj3/c_code/model4.cpp with the include dirs:
proj1/util common/includes
--NOTE: The content of this message may contain personal views which are not neccessarily the views of Motorola, unless specifically stated.
___________________________________________________ | | _ | Michael Rohleder Tel: +49-89-92103-259 | _ / )| Software Technologist Fax: +49-89-92103-680 |( \ / / | Motorola, Semiconductor Products, System Design | \ \ _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_ (((\ \>|_/ > < \_|</ /))) (\\\\ \_/ / mailto:Michael.Rohleder@motorola.com \ \_/ ////) \ /_______________________________________________\ / \ _/ \_ / / / \ \
The information contained in this email has been classified as: Motorola General Business Information (x) Motorola Internal Use Only ( ) Motorola Confidential Proprietary ( )
*** This note may contain Motorola Confidential Proprietary or Motorola Internal Use Only Information and is intended to be reviewed by only the individual or organization named above. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this email and its attachments, if any, or the information contained herein is prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system. Thank you! ***
This archive was generated by hypermail 2b28 : Fri Nov 29 2002 - 05:55:31 PST