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

Michael McNamara wrote:

>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.
>
>
IMO that only works efficiently for small items. It would be expensive
in time and/or memory to do that for composite types that would normally
be optimized away when design hiearchy is flattened, and there are good
reasons for not using the 4-bits per logic bit representation that VCS
happens to use.

>If we do not mandate the layout, then we loose the interoperability.
>
>
My earlier postings on using virtual functions were intended to address
the issue of interoperability when data representations are not binary
compatible.

In addition to virtual functions you can also use dynamic
loading/linking and function overloading (previously proposed) so that
you can bind different versions of a particular routine at runtime
depending on what the kernel and user code support. I.e. you can support
more than one interface within one library.

I think efficient interoperability is not too hard too achieve, but it's
going to have to be smarter than the current direct/C-only interface
approach. We should be learning from C++, Objective-C etc. which have
already addressed most of these problems.

Kev.

>-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
> >
>
>

-- 
Altera Corp, 101 Innovation Drv, San Jose, CA 95134. T# (408) 544 7126