Mac write:
> 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
It is with regret that I must point out that this working group is
volunteering to play the part of a blindfolded Sysiphus. Blindfolded,
because others have rolled this rock up the standardization slope
without success, and we are not paying attention to why our forebears
have failed.
I am convinced that binary compatibility is a worthy goal, that it
is not feasible to achieve it by standardization, and that this
will not be a substantial problem in the real world. Let me break
down the issues, which apparently have not yet been raised in this
forum.
De Jure foundations and P1800 scope:
There is insufficient specification in ISO/IEC 9899 to support
binary compatibility. Indeed, that was rule out of scope for that
standard and the specification only provides for source code
compatibility between implementations. By way of example, the
following conditions make binary compatibility unspecified:
- Structure members may have unnamed padding between members and
at the end of the structure. There is no further specification
regarding whether or not padding must exist and if so, how much.
There is no requirement regarding the alignment of structure
members. There is only sufficient semantics to allow an
implementation to align the contents of the structure. The
standard also specifies that members are in fact layed out in
the declaration specified order.
- The actual size of most scalar types is constrained only by how
that size relates to that of other scalar types. There are only
a few exceptions, which you have to look hard to find or infer.
As a result you can only rely on:
char == 8 bits
short >= 16 bits && <= sizeof(int)
int >= sizeof(short) && <= sizeof(long)
long >= 32 bits && <= sizeof(long long)
long long >= 64 bits
Types of the form int<n>_t (such as int8_t, int32_t int64_t)
have the specified number of bits.
- Calling conventions for argument passing are not specified by
ISO 9899. So callers and callees that are processed in separate
translation units by different implementations are not constrained
to actually inter-operate.
To address these issues in the P1800 document is out of scope. Our
PAR does not permit us to add constraints to ISO 9899, to make the
behavior of the C language more palatable for our purposes. The
C language is what it is, and we have to live with that, or address
it in the ANSI and ISO working groups responsible for that standard.
Now there are those who will argue that in practice, interoperability
is not that big a problem. For every processor architecture there
is at least one Application Binary Interface (ABI) specification
which details rules for calling conventions, size and alignment
rules, library linkage conventions etc. The problem for P1800 is
trying to find and make normative all those documents so that you
can nail down an ABI that will solve the compatibility problem.
That has in the past been impractical, and previous efforts to
fully define a portable ABI across all platforms have been abandoned.
Practical considerations:
In practice, even for a single platform there are impediments to
binary compatibility. For GCC on the Intel ia32 platform, there
are by my count 64 different ABI combinations just involving
incompatible choices for size and alignment of data. This does not
begin to cover the options for modifying calling conventions or
choices of code generation and/or optimization that affect binary
compatibility.
For the C++ language, GCC has changed the generated ABI twice in
the last two years and there will be issues (subtle or obvious)
when mixing code from either side of one of those changes. And this
has occurred where the same default compiler options are supplied
to versions before and after this ABI change.
There are many ways to break binary compatibility, and standards
are just not up to the task of identifying and preventing them
all from happening. So it would seem that we are doomed to missing
the objective by at least a little, if not a lot. And as Mac has
observed compatibility is a binary condition.
Attempts to constrain choices of C behavior by SystemVerilog tools
would take us down a long path. It would also intrude on the
implementors perogative for how to build and optimize their product.
Should the standard take a position on the language in which
conforming implementations should be written? Are Fortran, Ada,
Java, or Common Lisp unsuitable? Why should a particular ABI for
the C language, fully conforming to ISO 9899, be unsuitable.
The reality of the marketplace is such that vendors and customers
will evaluate solutions based on more than just conformance with
the relevant standard. In some cases these choices rise to such
a degree of influence that we label them as "de facto" standards.
I fully expect that ABI conventions for DPI will evolve over
time. The parties which benefit from vendor interoperability will
support those conventions. Those who have other priorities may
make other choices. And in the end the customers and ISVs will
vote with their dollars for the solutions which work best for
the EDA market as a whole.
Conclusions:
There are steps that can be take to mitigate or minimize the
obstacles to compatibility. Many of these are in scope for
standardization, and should be specified. Fixing the values of
constants such as the VPI object kinds and methods prevents
the gratuitous differences that make tools incompatible. Defining
structures and representations for data passing establish
conventions which will provide compatibility if the tools
use a common ABI. We should take these steps to enable useful
interoperability. We should not spend time trying to roll the
rock of binary compatibility uphill.
What is impractical to specify in a standard is not impossible
to achieve in practice. The market is very capable, over time,
of converging on conventions and practices which achieve favorable
results. The fact that ISO 9899 does not provide an adequate
foundation for mandating binary compatibility does not preclude
actual results. I note the various efforts to provide wrappers
for using codecs and DLLs from Windows (in object form) on platforms
such as BSD and Linux. The fact that such object code can be
invoked in a completely different ABI should demonstrate that the
problem can be solved even if the standards cannot say how.
/sjd
Received on Fri Oct 15 07:59:38 2004
This archive was generated by hypermail 2.1.8 : Fri Oct 15 2004 - 07:59:46 PDT