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 11:43:08 2004