Re: ADA/C++ Compatibility problems

przemek@rrdjazz.nist.gov (Przemek Klosowski)
Wed, 13 Sep 1995 22:37:47 GMT

          From comp.compilers

Related articles
[2 earlier articles]
Re: ADA/C++ Compatibility problems bobduff@world.std.com (1995-08-21)
Re: ADA/C++ Compatibility problems stachour@klondike.winternet.com (1995-08-25)
Re: ADA/C++ Compatibility problems jan@neuroinformatik.ruhr-uni-bochum.de (1995-08-30)
Re: ADA/C++ Compatibility problems gbaker@rp.CSIRO.AU (1995-09-07)
Re: ADA/C++ Compatibility problems jan@neuroinformatik.ruhr-uni-bochum.de (1995-09-07)
Re: ADA/C++ Compatibility problems leichter@zodiac.rutgers.edu (1995-09-07)
Re: ADA/C++ Compatibility problems przemek@rrdjazz.nist.gov (1995-09-13)
Re: ADA/C++ Compatibility problems jbuck@Synopsys.COM (1995-09-17)
Re: ADA/C++ Compatibility problems leichter@zodiac.rutgers.edu (1995-09-21)
| List of all articles for this month |
Newsgroups: comp.compilers
From: przemek@rrdjazz.nist.gov (Przemek Klosowski)
Keywords: architecture, design, C, Fortran, Ada
Organization: U. of Maryland/NIST
References: 95-08-127 95-09-031 95-09-082
Date: Wed, 13 Sep 1995 22:37:47 GMT

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 :^)


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


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.


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, standard compiler-generated stack
format, standard convention for passing of C and counted strings.


--
przemek klosowski (przemek@nist.gov)
Reactor Division (bldg. 235), E111
National Institute of Standards and Technology
Gaithersburg, MD 20899, USA


(301) 975 6249
--


Post a followup to this message

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