Subject: Re: [sv-cc] compiling and linking source code
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Mon Feb 24 2003 - 09:38:52 PST
Hello Francoise,
thanks a lot for sending in your concerns. I have tried to show my viewpoint on most of the issues you mention.
My believe is that you are very much working with other tool vendors that are exploiting PLI/VPI to attach bigger application
programs to a Verilog simulation. I doubt that these kind of users would be interested in using source code compilation or even the
DirectC interface. IMHO the typical user wanting to use such a facility is the "normal" engineer that wants to use some code doing
simple things (s)he has written in C/C++ within his Verilog application.
Anyway it was very good to see your concerns enlisted, as this gave me a much better chance to cross-check it with our discussions
and to certify that we have not forgot a major problem ... Thanks a lot for giving me this chance!
As a result I have embedded some more responses to your concerns in the email below. Happy reading ...
Best regards,
-Michael
Francoise Martinolle wrote:
> 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.
Correct. This is the reason, why it is possible to customize all of these for source code compilation (with exception of the linker,
for obvious reasons: if we would specify this, we would identify how to link object code created from the source into the SV
application, which would kill the transparency here. A vendor should be able to identify how to do this; e.g. by using the same
mechanisms as for compiled objects ...)
For object code inclusion, you anyway handle this on your own.
> 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.
I think I very well understand this problem. It's the same problem, if you wrap Cadence/Synopsys/Mentor/or somebody else's tool,
which we do ;-) The only aid (not solution) here is to properly identify where the problem is; usually this can be done by clearly
stating what is currently being done ...
> The compilation process is very sensitive to the order of some of the compilation options:
> for example, -I and -L.
Correct. This is the reason, why it is clearly spelled out, what the correct order for processing is. And, also, why there is a
prefix_flags, flags, and suffix_flags.
> The compilation process options -D and -U change the result of the pre-processed file.
This is why we permit the user to specify her/his options.
> Often the linking process requires a specific order for the external references to be resolved which only the user can determine.
Yes, you can specify this for object code inclusion, for source code inclusion for obvious reasons not. Would this be a problem?
> Sometimes, a lower optimization level must be used to compile a C file because of a code generation bug.
Yes, you can specify this as well.
> 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.
Nope. This is the reason for -sv_root.
> All this to say that a project which includes more than a handful of C files will have to go through several separate compiles.
I doubt that the source code inclusion capability will be used for more than a handful of files.
If this would be a problem you can _always_ do your own compilation as an user and run this route.
> 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.
What do you want to say us here:
- That expert user's won't use such a capability. Agreed, very likely not. They would mostly run the object code inclusion mode.
Although I have to say; if I would just have to stitch in a handful files with simple code (e.g. pure functions in DirectC sense),
this has some charme to me: no intermediate results to store, compilation options I could set on the fly when invoking the
application (in case of dependencies between SV code and Verilog defines), there are some more things I could think about ...
- That beginner's won't find this useful. Hart to say for me (I do coding since 24 years). The one's I know are happy for any aid.
- That there are better tools out for this. Agreed. But this is not the point. If I just want to include some simple code in C into
a SV design, this would be a perfect match. Most _designer's_ are just using some simple functions written in C.
> 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.
Do we say something else?
Besides that: for EDIF I still would need a netlist reader, but if you like lot's of brackets we can also use scheme or any other
LISP dialect as example. Perl and Tcl/Tk (as well as a scheme interpreter) can be integrated by including the interpreter kernel
(which are C/C++) and point to the corresponding Perl/Tcl/scheme code. None of these examples is real mixed language compilation and
linking, or did I miss something here?
Better examples would be: Fortran, ADA, SQL, or Java (although the latter two can also be interpreted).
> 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.
a) I doubt that ELF would help you much here. I am not aware of any section in the ELF standard/format (b.t.w. ELF-1 or -2 ?) that
would solve these issues in a compiler & OS independent way (ELF-3 I haven't looked at, but to my knowledge it is anyway not yet
released).
b) This is a problem of the C++ standard not defining those topics
c) This is a C interface, not C++ for exactly those reasons (+ name mangling)
d) It is already stated that this is the user's responsibility to avoid those problems or handle them
> 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.
I am sorry, but all these are arguments against a C++ interface (which we don't have anyway), not against defining how to integrate
C/C++ code.
> 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 really don't want to go into details to express my believes why the 'Single UNIX approach has been failed'; but I am sorry, I
don't understand your point here. We can not use the switch names defined in C89, the chance that they are already used is rather
high. We just want the user to permit to override certain switch settings, and this would be clearly compatible with C89 ...
> 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.
O.K. I think none of us can guarantee that the result of any of our efforts will be implemented, used or even accepted by the user
community. As such I fully honor your comments, but should this prevent us from defining a standard here? Source code inclusion is
still optional, so Cadence can even decide not to implement it ?!?
But think about the fact that a real user (me), not a newbie Verilog C/C++ programmer (who might benefit more from this effort)
spent some of his overtime to define such a thing. It must be a _real_ problem, otherwise many people won't do this, right?
--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 : Mon Feb 24 2003 - 09:39:46 PST