🚀 go-pugleaf

In article 1415@ittpub, wil@ittpub.nl (Wil Evers) writes:
>
>- The standard should require the compiler vendor to specify what forms of  
>external linkage are supported. At the very least, extern "C" and extern  
>"C++" must be supported.

That is already the case. "C" and "C++" linkage must be supported.


>- For each of these forms of external linkage, the standard should require  
>the compiler vendor to specify which name encoding scheme and calling  
>conventions are used. As Steve Clamage pointed out, such a requirement  
>could be satisfied by to referring to some well-defined ABI. For extern  
>"C", 'same as C compiler XYZ version 2.0.2' would be good enough, as long  
>as that compiler defines its name encoding scheme and calling conventions.

Now things get stickier. It's fine for you to say "name encoding scheme"
and "calling conventions". But the standard would have to define what
that means. What if there is no linker and no name encoding? What
exactly must be specified in "calling conventions": Register usage? There
might not be any registers. Stack frame layout? There might not be a stack
frame, or even a stack as it is commonly thought of.

The standard would have to say what the vendor must specify, but without
reference to hardware features which might not exist, and possibly missing
things which would be important on some platform. This stikes me as
a losing game. As I said before, what you want is an ABI, and specifying
an ABI, or even what an ABI must contain, is outside the scope of a
programming language standard. (Take a look at the Unix SVR4 ABI, for
example, and then notice it contains no hardware-sepcific data. You need
another document that gives the ABI details for the specific processor.)

Please also notice that you have been focusing so much on function linkage
that you have not mentioned things like commonality of data types: are ints
the same size and format with both compilers? Pointers? Do the compilers
use the same data alignment algorithm? And so on. These are at least as
important as function linkage, and are part of an ABI.

We cannot solve all problems with a language standard. Some people would
like the standard to be specific enough that any compiler that met its
requirements would be useful and efficient. IMHO, this can't be done,
and isn't worth trying to do. (If someone wants to spend several
person-years producing a C++ implementation that meets all the requirements
of the standard yet is useless, that's OK with me. But I won't buy it.)

As I said before, a C++ compiler vendor must, out of self-interest, strive
for compatibility with other popular systems, and document that
compatibility -- whether the standard says so or not.
---
Steve Clamage, stephen.clamage@eng.sun.com