[sv-cc] Issue 205 summary 10/05/04

Hi everyone,

A lot of debate has occured on issue 205 and related topics.
Some good points have been made.

Here is a summary of our current thinking on these points:

a) Regarding C ABI's and compatability of DPI arguments.
   These ABI's are notoriously hard to find. They appear to
   be tightly linked to machine vendor specifications. We have
   empirically determined the aggregate type layout and padding
   rules on the following platforms:
       sparcv8 (32-bit Solaris)
       sparcv9 (64-bit Solaris)
       linux (i686, 32-bit compile)
       opteron (64-bit compile)
       itanium2 (64-bit compile)
       hppa (32-bit and 64-bit modes)
       win32 (32-bit compile)
       aix (32-bit and 64-bit modes)

   On each platform, we ran all known compilers, including gcc
   and including native compilers. Without exception, all compilers
   on a given platform follow the exact same layout and padding rules.
   aix and linux have some differences from other platforms with
   regards to double and long long datatypes. I can send the
   experimental results to anyone who is interested.

   All 64-bit compilers follow the LP64 convention.
   LP64 => longs and pointers stored in 64 bits, ints stored in 32 bits.
   All 32-bit compilers follow the ILP32 convention.
   ILP32 => ints, longs, and pointers all stored in 32 bits.
   As far as I know this has been the case for at least 15 years.

   Our attitude on this issue is that we must be practical.
   We understand how C compilers work on all platforms used in EDA,
   and we must conform with the ABI's used by those C compilers.
   Otherwise DPI is useless. The compilers haven't changed in 15
   years. If they changed now, the bulk of the compiled library
   software in the world would be rendered useless. Just because
   there is no statement in the ANSI/ISO standard about how many bits
   C datatypes consume does not mean we should avoid this empirical
   knowledge when discussing DPI topics.

   In any case, this topic is orthogonal to issue 205, and we would
   request that those parties interested in bolstering the LRM
   with this type of information enter a new issue in Mantis.

b) Regarding 32-bit vs. 64-bit alignment issues.
   Once again, we should be practical. Annex G in the 3.1a SV standard
   requires that DPI be implementable as a shared object that can be
   loaded into a simulation kernel. As a practical matter, 32-bit object
   code must only be mixed with other 32-bit object code. Same for 64-bit.
   This goes for any objects combined into a shared object, and it goes for
   any executable program combined with any shared object it loads.

   So if a user wants to prepare a DPI library (shared object), they have
   to understand if they are going to be running a 32-bit or a 64-bit
   simulation kernel. They prepare the DPI object code accordingly.
   If Issue 205 is passed, 32-bit DPI object code will be binary compatible
   across all 32-bit simulators, and 64-bit DPI object code will be binary
   compatible across all 64-bit simulators.

c) Regarding data marshalling.
   Andrzej's example with the linux/solaris long long shows that some
   cases arise where data marshalling is a valid implementation option.
   We shouldn't attempt to write the standard in such a way that one or
   more simulators can avoid all data marshalling. We can try to reduce
   the need for it where practical, and where it doesn't adversely affect
   usability too much. Keep in mind that no two simulators are likely
   to have the exact same data marshalling sensitivities, so optimizing
   the standard heavily in favor of this is somewhat disingenuous.
   As Ralph points out, usability vs. performance is a balancing act.
   And, if a simulator detects a given argument datatype that is likely to
   be severely "performance challenged", that simulator should feel free
   to issue a warning to the user suggesting an alternative represntation
   that would avoid the detected performance penalty.

d) Regarding the crux of Issue 205: self-consistency in the standard.
   We agree with Andrzej that this is a datatype issue.
   Our opinion (and the reason for 205's existence) is that we need to
   get consistency between the handling of SV datatypes passed directly
   as arguments to DPI functions, and the usage of such types when embedded
   in larger aggregate arguments to DPI functions. We find it unintuitive
   and anti-user-friendly to require different user programming of those
   datatypes depending on their use context.

   We also agree with Andrzej that the current proposal is wasteful of storage.
   We are reworking the proposal to be more efficient. In fact, hopefully
   just like Verilog PLI's layout of 2-D memory data. Please stay tuned for
   a next draft containing the new and improved binary compatible proposal.

Regards,
Doug
   
Received on Tue Oct 5 23:21:43 2004