RE: [sv-cc] More information on C ABI's for those interested

The binary representation of DPI arguments is absolutely mandated
by the DPI standard. In Section E.6.3, it is unambiguously stated
that all unpacked types (including aggregates) must have C compatible
layouts.

Since C compatability is defined by myriad platform/vendor-specific
ABI standards, we should not attempt to copy from those standards
and redefine C object representation in the SV LRM. Even referring
to all those standards is highly cumbersome. We should take the
route that the ANSI/ISO C/C++ world does and just leave those
details out of the standard.

The statement that DPI arguments must be C ABI compatible
automatically enforces binary compatability among all simulators.
(Similar to how all C compilers are binary compatible, since they
are all compliant with the appropriate C ABI standards)

Thus you only have to prepare one 32-bit Solaris .so, for example,
and it will be reusable across all SV 3.1a DPI-compliant simulators.

The crux of Issue 205, which is undergoing some discussion, is to
determine if can we still achieve binary compatibility with certain
complex mixes of packed types embedded in unpacked aggregates.
Currently we don't have binary compatability in such cases.
Our proposal for Issue 205 is intended to achieve binary compatability,
and to reduce programming burden for the C programmer.

Regards,
Doug

> -----Original Message-----
> From: Michael McNamara [mailto:mac@verisity.com]
> Sent: Thursday, October 14, 2004 10:44 AM
> To: Warmke, Doug
> Cc: sv-cc@eda.org
> Subject: RE: [sv-cc] More information on C ABI's for those interested
>
>
> One of my initial challenges to the group was that it form a
> standard that one could use as a third party vendor to build a
> library which could be linked into any simulator, with out requiring
> vendor specific builds.
>
> I.E., I could provide a binary linkable library model of an ARM
> processor compiled on, say Solaris, to my partners, and they could
> link it in to any SystemVerilog simulator that ran on Solaris.
>
> I would have to provide a different library for my partners for Linux,
> and HPUX, et cetera, which I would be willing to do.
>
> What I would not be willing to do is to be required to provide the
> NCSIM Solaris library, and the VCS Solaris library, and the MTI
> Solaris library and the SpeXsim Solaris library, and the Fintronic,
> the Carbon, the ... and then all of these for Linux, and for HP, and
> for AIX, and for Windows-XP, and for...
>
> DPI will in my mind miss one of its key objectives if it ends up not
> being as good as the X library or the math library or the networking
> library; which each of these simulators can link to the same Solaris X
> library.
>
> We can do this by mandating the layout of the memory that crosses the
> boundry.
>
> If we do not mandate the layout, then we loose the interoperability.
>
> -mac
>
>
> -- On Oct 13 2004 at 21:37, Warmke, Doug sent a message:
> > To: sv-cc@eda.org
> > Subject: "[sv-cc] More information on C ABI's for those interested"
> > Hello folks,
> >
> > I'm aware that Francoise and others from Cadence had
> > some concerns about our SV DPI standard not directly
> > addressing C datatype layout issues.
> >
> > Here is some thoughtful information from one of our
> > low-level ABI experts:
> >
> > ABI specifications are not national or international
> > standards but rather "industry" standards typically
> > promulgated and controlled by a hardware or software
> > vendor or the user community. A processor architecture
> > may have more than one ABI, for example the Intel ia32
> > (x86) family has ABIs for Linux, Microsoft Windows, and
> > perhaps others. ABI specifications often change as
> > processor architectures are enhanced or extended, or as
> > components of the tool chain (compilers, linkers, loaders,
> > libraries, operating systems, and utilities) are upgraded.
> > Because the low level implementation details covered by
> > ABI specifications practically defy standardization,
> > high-level language standards almost universally say
> > nothing about them.
> >
> > For Sun Solaris, the SPARC Compliance Definition document
> > details the SPARC v8 (32-bit) and SPARC v9 (64-bit) ABIs.
> > The SCD can be downloaded from the SPARC Standards
> > Depository, http://www.sparc.org/standards.html.
> >
> > For Linux ABIs, look to http://www.linuxbase.org/spec/
> >
> > Google might be able to help find other ABI documents.
> >
> > As I looked into those two standards repositories, I found the
> > following relevant documents on the Linux i386 ABI and Sparc ABI:
> >
> > http://www.caldera.com/developers/devspecs/abi386-4.pdf
> > http://www.sparc.com/standards/psABI3rd.pdf
> >
> > These documents directly and completely describe the rules
> > for layout, alignment, byte ordering, and padding in aggregate
> > types (struct, array) and unions. We have experimentally
> > confirmed all rules in the standards for both platforms.
> >
> > In keeping with convention, it seems like our high-level
> > language standard should remain moot on this subject, with
> > the exception that it already specifies "layout of unpacked
> > type arguments must confrom to layouts used by C compilers".
> > Implementors of SystemVerilog are responsible to look up
> > such layouts in the appropriate C ABI specifications, and
> > then do the right thing.
> >
> > Thanks and regards,
> > Doug
> >
>
Received on Thu Oct 14 15:39:44 2004