Subject: [sv-cc] compiling and linking source code
From: Francoise Martinolle (fm@cadence.com)
Date: Fri Feb 21 2003 - 14:32:37 PST
This email explain my opinion on compiling and linking source code
standardization within
systemVerilog. It is based on a long experience dealing with
a very wide variety of C/C++ users.
The C user today has many variables to set for the compilation and link of
its program. The setting and order of evaluation of these variables is key
for the compilation and link to be successfull. Several choices are present
for him :
.various C compilers, from gcc (free compiler) to platform native
compilers, sometimes different versions of gcc,
. various linkers
. compiling with different level of optimizations/debugging information
. using C standard libraries and other open source libraries
. choosing the result of the compilation and linking: executable,
object code, shared
library static library.
I have seen users who take the latest CVS version of gcc on a daily basis.
Associating
the simulator executable with the compilation of the C files is going to
migrate issues with the gcc or C compiler to the a simulator bug.
The compilation process is very sensitive to the order of some of the
compilation options:
for example, -I and -L.
The compilation process options -D and -U change the result of the
pre-processed file.
Often the linking process requires a specific order for the external
references to be resolved which only the user can determine.
Sometimes, a lower optimization level must be used to compile a C file
because of a code generation bug.
The systemVerilog executable will have to be launched in the correct
directory to be able to
find the source files if relative names are passed.
All this to say that a project which includes more than a handful of C
files will have to go through several separate compiles.
Trying to merge the C compilation options with the regular systemVerilog
options
and use a single invocation is only going to be possible for only a fairly
small number of
application code out there.
And if we don't merge verilog and C compilation together in the same tool,
then we have
to create a new tool just for compilation and linking. There are many tools
which exist today
and which have existed for 20 years. Look at the Make utility, visual
studio etc...
Cadence has provided fairly complicated Makefiles with targets rules fro
compiling, linking,
and macros that the user can customize to provide the C files, headers,
flags etc...
We even have a gui application (kind of a wizard) which guides you through
the compilation
and linking of your application.
The fact is, even though our makefiles are quite general and handle both C
and C++,
fairly expert C users refuse to use them and have put together their own
brewed Makefiles or utilities. The beginner user sees only some advantage
in the gui application because he is guided through the process and the gui
wizard instructs him on what to set in sequence.
There are a lot of issues trying to handle mixed language compilation and
linking:
C, C++, edif, perl, tcl.... Is systemVerilog going to address all this?
Let's just look at C++ and C which may be the most common scenario today
and the one
we may want to support.
If some code is written in C++, even worse if different C++ compilers were
used, we have problems with static constructors initialization, exception
handling and run-time type identification. Static constructors service can
be handled by the dlopen service if the object files were produced with the
ELF format. This forces a certain format to be used for the C++
library.
But, in order to ensure that there is a default exception handler in place,
the application startup code needs to establish the required stack prior to
the call to the
"main" function. Since non-C++ compilation environments are not expected to
be knowledgable about the C++ semantics, a common practice is to compile
main with C++
to ensure that C++ services are established.
Therefore in order for systemVerilog to support compilation of C and C++
code, it will have to recreate its own executable (SV.exe) and fork exec
before invoking simulation.
I don't think we want to do this.
Finally if we still want to go that route and provide a general solution,
I suggest we look at previous standard work which has been done in this area:
C89 is a POSIX standard utility which provides an interface to the standard
C compilation system; it will accept source code conforming to the ISO C
standard.
http://www.opengroup.org/onlinepubs/007908799/xcu/c89.html
The system conceptually consists of a compiler and link editor. The files
referenced by operands will be compiled and linked to produce an executable
file.
It provides standard options from which you can provide source files,
libraries to search, optimizations level, etc... Most of the options that
can be passed to a C compiler
are available.
Note that C89 has been ignored by the C community...
I don't think that specifying source file inclusion, compilation and
linking should be
part of the systemVerilog standard. It should just be enough to specify a
mechanism
for providing a shared library of directC code and some entry points in
that library.
If we do specify source code compilation and linking, it will probably be a
wasted, limited and ignored effort.
Francoise
'
This archive was generated by hypermail 2b28 : Fri Feb 21 2003 - 14:34:12 PST