Re: ADA/C++ Compatibility problems

przemek@rrdjazz.nist.gov (Przemek Klosowski) writes:
> leichter@zodiac.rutgers.edu writes:
> ....consider what CALLG/CALLS, and more generally the VMS
> calling standard, gave you: The ability to call between languages *very*
> uniformally, with a well-defined semantics that included a completely
> general exception handling model. (C is an exception: While the calling
> standard itself is pretty neutral on the subject, the languages
> originally supported, and hence the interfaces offered by system and
> library routines, were strongly biased to reference parameters for most
> things, and descriptors for strings.
>
> Oh, c'mon, admit that the parameter conventions were biased towards
> DEC favorite system programming language, Fortran :^)
Actually, no. In 1977, FORTRAN and strings barely mixed. Strings in the
VMS calling standard provided much more than FORTRAN at the time - or for
quite a while after - required. Reference parameters may have been naturals
for FORTRAN, but they were also naturals for COBOL, PL/I, Pascal, and many
other languages. In fact, in the one area where FORTRAN and all other known
languages disagree - layout of multi-dimensional areas - there is, if
anything, a bias against the FORTRAN style. (There's a general "array
descriptor", which includes a bit that differentiates row- and colum-order
addressing. However, there's no generic access routine - and it's hard to
imagine anyone using one if it existed.)


> The language interoperability of calling conventions was achieved by
> defining a format for all allowable parameter types. Yes, every data
> format has its own VMS structure called parameter descriptor
> associated with it; here's a typical VMS way of constructing a string
> parameter:
>
> /* .. zero the descriptor.. and*/
> out->dsc$a_pointer=s;
> out->dsc$w_length=strlen(s);
>
> on call site, a reverse operation has to be done.


No language other than C would bother to do this. All other VAX compilers
can support at least one of the native string formats directly. For the
record, they all have similar descriptor layouts, but can have one of three
sets of semantics: Fixed length (length/pointer may not be changed);
varying length (fixed length interpreted as maximum; current length encoded
at the beginning of the string); dynamic (library calls may modify the
pointer and length as required). Varying length strings were added for, I
think, PL/I and perhaps PASCAL, and were a mistake: Fixed and dynamic strings
can be treated completely identically on input, and on output as long as the
result fits in the space available. With varying-length strings, you have to
remember to skip over the stupid length field each time.


> I happen to believe
> that this is morally homomorphic with Callg, in that both are
> overengineered. After all, different languages use different data
> structures: C strings are zero-terminated, Fortran's are static,
> counted areas.
It was a nobel, if ultimately only partially successful, attempt to allow
cross-language calls. It works to the degree that languages deal with
abstract data types. In all languages but C and, to a limited extent FORTRAN,
the internal construction of strings is invisible. All that matters is the
interface. Some language interfaces are more restrictive than others (e.g.,
simple PASCAL has only *really* fixed length strings), but the general
abstract interface is well understood.


C doesn't believe in abstraction, and doesn't get to enter this game.


> A short look through the catalog of VMS parameter
> descriptors is enough to conclude that the list is both too long and
> at the same time insufficient. For example, the issue of fast
> parameter passing, e.g. in registers, is not addressed by VMS
> conventions, if I recall correctly.


Actually, there are standards for passing arguments in registers, but in
general high-level languages have no access to them. However, this is a
*VAX* limitation. Essentially the same external standard is available on
Alpha VMS - but Alpha compilers pass arguments in registers.


> Just about the only thing I remember fondly from VMS calling
> conventions is the fat stack frame allowing nice tracebacks and
> unwinds, with source line info etc.


...something that few systems do nearly as well to this day. Oh, and to
repeat myself: On the Alpha, you get the same features, without the "fat"
stack frames, limitations on argument passing, etc.


> Some simple conventions that do exist on majority of systems go a long
> way: a standard procedure name mangling, especially for
> strong-type-checking languages,


Perhaps some time in the next century, we'll *finally* have linkers designed
for modern languages, not FORTRAN, COBOL, and assembler. Then we'll be able
to specify typechecking semantics directly in the object language, rather than
hiding it in mangled names. (By the way, the VAX object language actually
has constructs to specify types for matching. Unfortunately, this very early
start was never followed through, and the hints you can provide are not
checked by the linker.)


> standard compiler-generated stack
> format, standard convention for passing of C and counted strings.


There's no such thing as a C string! All there is is the address of a char.
With that little semantic information, it's impossible to do anything
sophisticated.


Perhaps we'll one day standardize on, say, the RougeWave string classes for
C++. Frankly, though, I doubt it. And as for C - forget it.


-- Jerry
[Sheesh, the Dartmouth linker did type checking without mangling in 1976.
-John]


--

Return to the comp.compilers page.
Search the comp.compilers archives again.