Related articles |
---|
ADA/C++ Compatibility problems dasilvia@sonalysts.com (1995-08-18) |
Re: ADA/C++ Compatibility problems papayd@gtewd.mtv.gtegsc.com (Dave Papay M/S 7G32 x2791) (1995-08-21) |
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) |
Newsgroups: | comp.compilers |
From: | leichter@zodiac.rutgers.edu |
Keywords: | architecture |
Organization: | Rutgers University Department of Computer Science |
References: | 95-08-127 95-08-189 95-09-031 |
Date: | Thu, 7 Sep 1995 21:42:49 GMT |
> As a more readily accessible exmaple [of inter-language calls] tha[n]
> Multics, try the VMS calling conventions. DEC's compilers have had
> inter-language calls from day one. The necessary "hacks" to get languages
> requiring initialization to co-operate properly are less well documented,
> although a general mechanism (LIB$INITIALIZE) is provided.
>
> [I gather there are (were?) performance problems -- the heavyweight CALLS
> and CALLG instructions used in the common calling sequence were complicated
> and slow. -John]
Our moderator provides a perfect example of how not to learn from history.
Yes, there was one repeatedly-cited study that showed that on one particular
VAX model (the 750, I think) you could beat CALLG/CALLS by coding individual
instructions. In general, this was not true, however, except in special
cases. (BTW, the single thing that cost the most was that the register save
mask - which had a bit for each register to be saved on the stack - had to be
handled one bit at a time. Sure, in theory you could build hardware to look
at the whole thing in parallel and send registers to memory in big blocks.
But no one was ever able to afford to throw enough hardware at the problem
to do that.)
But even if it was, 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.
In C, these are painful since you have to construct them explicitly.)
The VAX also provided very simple calls (branch to subroutine) which are the
equivalent of typical RISC calls. Low-level code makes extensive use of
these, and in fact there is even a standard for such thing. BLISS could
generate code that used these interfaces, and VAX C started to at the end of
its life - but DEC C, which replaced it, dropped that stuff as inherently non-
portable.
In any case, this is all a non-issue. CALLG/CALLS as the centerpieces of a
calling standard were typical of CISC designs. VMS on the Alpha supports an
equally complete calling standard, without the underlying hardware support:
The Alpha has only the most basic "jump and save PC" "call" instruction.
Everything else is done through the cooperation of compilers and run-time
support code. The calling sequences can be as light-weight as on any RISC
machine. It can be, and is, used throughout the system, from the bottom of
the kernel through all compilers. Handling of exceptions and such things as
debugging tracebacks are much more complex, and relatively much more
expensive, on an Alpha than on a VAX. There's no free lunch - but in fact
this is a good tradeoff, since these things are (a) even rarer than was
expected by the VAX designers; (b) given the speed of modern machines, not in
practice too expensive.
By the way, DEC Unix uses a very similar calling standard.
When the VAX was designed, the designers not only thought they could get
better performance by providing so much semantics in the call instructions,
they also thought that was the only way to get an effective cross-language
standard. At the time, there was little dissent. We've learned a great deal
since then. Everyone loves to remember that the first claim - better perfor-
mance though complex instructions - proved to be unsupportable. No one seems
to want to think about the fact that the second claim also proved false. It
*is* possible to design effective, efficient calling standard for multiple
languages, and build and run programs built out of components written in a
multiplicity of languages. You have to be willing to make the investment in
developing the standard and implementing it in a variety of compilers, though
- an investment that those who believe that only one language (C? C++?)
matters are unlikely to want to make.
-- Jerry
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.