Subject: Object Code vs. Source Code compatibility
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Sat Aug 31 2002 - 09:12:16 PDT
Hi all,
there is an action item with me to drive the already started discussion about 'Object Code vs. Source Code compatibility'. Until now I was unable to fulfill it, for various reasons (nothing but bad excuses), so I am trying to do my dues now:
(A) what is meant by 'object code compatibility' and 'source code compatibility'?
* Object code compatibility permits to integrate compiled objects using the SystemVerilog API
(to be developed) within all applications providing such an API. The same compiled object can
be used within all applications; there is no need to recompile the original source code.
* Source code compatibility permits to integrate any code using the SystemVerilog API (to be
developed) within all applications providing such an API, but will usually require a compilation
of the source code using the header files of the corresponding simulator.
(B) why is this so important?
* Some members of SV-CC believe that the need for object code compatibility can result in
excluding C++ from the implementation languages for the SystemVerilog API('s). Although
this might be the case, I would strongly suggest to start with the _real_ questions:
- Do we really need object code compatibility or would source code compatibility sufficient?
- Under the assumption we need object code compatibility, what are the implications of it?
- What problems would exclude C++ from being a usable language for the API?
- Why is PLI also not object code compatible, although it is just C?
So, instead of already making (implicit) decisions during the discussion, let's try to understand
the whole problem space. Then we can make informed decisions. I don't want to rule out C++
or get into a 'language war' between C or C++; so please stop any discussion in this direction.
Instead let's talk about the problems and their implications; probably there are also solutions.
-- O.K. let's start now. These are my two cents:
a) Why do I as an user of such an API believe that 'object code compatibility' is so important?
- We have to support more than 5 Verilog simulators (VL-XL,NC,ModelSim,VCS,Emulation).
Having to #ifdef code to take care of the (minimal, but still existing) semantic differences
between those simulators is the last thing a model developer wants to do.
- Usually there are at least 3 different versions of a model (one for debugging reasons, one with
maximum amount of checks, one with no checks for maximum performance)
- We have to support 5+ platforms (Solaris, HP-UX, Linux, AIX, Windows)
--> In case of object code compatibility this results in the need to provide 15 different models; in
case of source code compatibility we would need at least 75different models. Each new
simulator requires 15 more models
--> When there are additional compiler dependencies you can nearly double the amount of
models needed (SparcCompiler+GCC, HPCompiler+GCC, VisualC++/GCC, ...)
--> I will not talk about additional needs & models caused by incompatibilities between versions
of the same simulator...
Of course this is an 'idealistic' case. We do not necessarily need to support all models on all
simulators on all platforms. But in some cases this is the current reality!
b) What are the implications, when we assume object code compatibility is needed?
- we need a clear and inambigous method to integrate the object code into the simulation; this
includes loading of functions, interpretation of data values, and other aspects.
- the defined API must have a clearly defined execution semantic, with no room for interpretation
- the integration method must be simulator AND compiler independent
d) [Done before c) for discussion reasons] Why is PLI not object code compatible?
That's simple (from a general point of view) but also a rather complicated answer:
- General point of view: Verilog does not have clearly defined integration semantics that require
object code compatibility. Therefore nobody has ever seen the need for this ...
- Complicated answer: there is a lot of nitty gritty details that prohibit object code compatibility.
One example: One of the commercial Verilog simulators redefines the variable acc_error_flag
not to be a global object, but to be the return value of a function ... This is done by a #define.
The resulting object code is of course slightly different from the object code of others ...
c) As a matter of fact, some of the above problems in b) would exclude C++ from the languages of
choice for the API:
- C++ does not have clearly defined integration mechanisms; as a result these are differing from
compiler/linker to compiler/linker
- The C++ compiler performs a step called 'name mangling' that is needed to distinguish functions
having the same name, but a different signature (e.g.: to distinguish the function
'int MyFunc(double)' from 'int MyFunc(int)'). The generated names are not standardized
and may therefore differ between compilers and platforms.
- Processing of global C++ objects is not defined and therefore different between compilers
and/or versions.
I think these are important problems, that would soon require some technical solution, but I
believe there are also some problems in other languages we should also take care of. If we
think by just choosing C instead of C++ we solve this problem, we better start discussing now.
Hope this is sufficient dynamite to ignite some discussions.
Best regards,
Michael
___________________________________________________
| |
_ | Michael Rohleder Tel: +49-89-92103-259 | _
/ )| Software Technologist Fax: +49-89-92103-680 |( \
/ / | Motorola, Semiconductor Products, ASA Methodology | \ \
_( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_
(((\ \>|_/ > < \_|</ /)))
(\\\\ \_/ / mailto:Michael.Rohleder@motorola.com \ \_/ ////)
\ /_______________________________________________\ /
\ _/ \_ /
/ / \ \
This archive was generated by hypermail 2b28 : Sat Aug 31 2002 - 14:14:42 PDT