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

Hi Mac,

I think we already had this discussion in the very early days of DPI;
see your and other's comments in the thread
related around http://www.eda.org/sv-cc/hm/0066.html.
You can be sure that there are other people watching this problem as
carefully as you ...

As Doug clearly pointed out we hope that Mentor's proposal will also
improve the situation here significantly.

I believe the current discussion is very healthy, will help us to find
other problems, and hope at the end
we will achieve a real '1' in the sense your binary problem.

Regards,
-Michael

Michael McNamara wrote:

>It is rather obvious, and also somewhat enjoyable to point out, that
>achieving binary compatibility is rather binary - either we have it or
>we do not.
>
>Telling the .so creator that you get binary compatibility as long as
>you don't pass (or are passed) a structure with one of these in it is
>not extremely useful.
>
>So I cheer on the effort to figure out these last little details,
>while reminding those that are tempted to just leave it unspecified
>that we will have failed our mission. And missing it by just a little
>bit is just as bad as missing it by a lot.
>
>-mac
>
>-- On Oct 14 2004 at 15:39, Warmke, Doug sent a message:
> > To: mac@verisity.com, sv-cc@eda.org
> > Subject: "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
> > > >
> > >
>
>

-- 
NOTE: The content of this message may contain personal views 
      which are not neccessarily the views of Freescale, unless specifically stated.
 
         ___________________________________________________
        |                                                   |
      _ | Michael Rohleder            Tel: +49-89-92103-259 | _
     / )| Freescale Semiconductor     Fax: +49-89-92103-680 |( \
    / / |      Freescale Halbleiter Deutschland GmbH        | \ \
  _( (_ |  _   Schatzbogen 7, D-81829 Munich, Germany    _  | _) )_
 (((\ \>|_/ >                                           < \_|</ /)))
 (\\\\ \_/ /    mailto:Michael.Rohleder@freescale.com     \ \_/ ////)
  \       /_______________________________________________\       /
   \    _/                                                 \_    /
   /   /                                                     \   \
The information contained in this email has been classified as:
General Business Information                     ( )
Freescale Internal Use Only         ( )
Freescale Confidential Proprietary  ( )
*** This note may contain Freescale Confidential Proprietary or Freescale Internal Use Only Information and is intended to be reviewed by only the individual or organization named above. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this email and its attachments, if any, or the information contained herein is prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system. 
    Thank you! ***