Re: Papers saying Ada as an overly complex language and hard to implement

[kilgallen@eisner.decus.org (Larry Kilgallen)]

In article <dewar.887765847@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> The factor of ten, if real, means that the C compiler was very poor indeed.
> Why do I say this? Because in a good C compiler, the code generator will
> be by FAR the largest component of the compiler, and the same is true
> of an Ada compiler. For example, in GNAT, the gcc backend is larger
> than the gnat front end.

One thing certainly missing from the first four years of the VAX C
compiler was reasonable debugger support (generating proper symbol
tables).  Although not measured in the size of the compiler, the
same team was responsible for code to go into the VMS debugger
for the language-specific command parsing, and that was also
among the missing.

I have my own opinions about the people involved not having the
habit of sticking with a project and seeing it through.  One
can avoid that rathole and say that it takes more than passing
validation tests and compiling well-formed programs correctly
to make a good compiler.  In fact if one makes the generalization
that passing a validation suite constitutes the measure of behavior
for correct programs, my primary differentiator between Ada compilers
would be how well they help me on incorrect programs.

> In fact I suspect the factor of ten was, for whatever reasons, an apple
> and oranges comparison (all sorts of things can distort such comparisons,
> e.g. static vs dynamic linked libraries, debugging information, inclusion
> of tools etc.

The VAX Code Generator (VCG) was initially built to support PL/I and C
to prove the point that a common back-end could serve two languages in
the DEC offerings.  It was subsequently used in many other DEC compilers
(not Pascal and not Fortran).  But along the way each language team added
their own enhancements to their own copy.  By the time it got to Ada it
might have grown quite a bit (perhaps to the better, but grown).

For Alpha, I believe DEC's GEM back end is more on the model of putting
all enhancements back into the common pool.

I would guess that the current DEC C for VAX compiler has a much more
elaborate front end than the former VAX C, since it must handle many
dialects, including ANSI and including the former VAX C (K&R) dialect.
Even within the latest standardized dialect, the compiler offers
options regarding how strictly to measure programs (such as the
recently discussed "ignore the results of a function").  VAX C
had none of that.

Larry Kilgallen