Subject: Re: [sv-cc] compiling and linking source code
From: Francoise Martinolle (fm@cadence.com)
Date: Mon Feb 24 2003 - 13:29:21 PST
Michael,
thanks for the response. Let me try to clarify my position.
My main point in my previous email was to say that the goal of a
standard is generally to specify a process which is the main common
denominator and which can be used in all cases.
Tools are free to provide additional methods which may be practical but
which have limitations.
They should not be standardized.
In my previous email, I tried to point out the complexity of the task you
want to undertake by pointing to the C89 standard and Make utilities which
cover this subject. I tried to point out the limitations in your proposal has:
. many choices for compilers, linkers
. many variables for compilation and linking,
. a large number of C files will require multiple separate compilations,
. C code referring to other language code (C++...) ; the external
functions to be linked with
SV would be a C function, but internal functions can be any language.
DirectC expert users will prefer the share library approach.
Beginner users will have exactly the same trouble if they were trying to
directly compile in C because they still have to understand which options
to pass, what are the include files, the source files etc... I don't see
much advantage in this for anybody.
What is the difference between using
cc -kpic -c file.c -I svc.h
ld -G -o libdirect.so file.o
ncverilog verilog.v +loaddirect:libdirect
and
vcs verilog.v -csource file.c -Include svc.h -ccompiler cc -sv_root .
You still have to know which options to provide and their settings.
Separating the compilation and linking of the source files from the verilog
compilation
is
1) easier for diagnosing C compilation and linking errors
and 2) for making the generated share library reusable.
I can only compile once the shared library and use it on several verilog
designs.
ncverilog verilog1.v +loaddirectC:libdirect
ncverilog verilog2.v +loaddirectC:libdirect
If you propose a standard with limitations, then the user community will
soon ask you to remove
restriction by restriction and your proposal will have to handle more cases.
That is my opinion.
Francoise
'
At 06:38 PM 2/24/2003 +0100, Michael Rohleder wrote:
>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 - 13:30:22 PST