🚀 go-pugleaf

(Note I wrote the front end for the AOS/VS C compiler, so I'm not
unbiased).

In article <4471@acorn.co.uk> osmith@acorn.co.uk (Owen Smith) writes:

| I assume we are talking about AOS/VS C rev 4.01? If so, "Pretty Good" is not
| a term I would apply to it. "Usable" and "Reliable" are about as generous as
| I can get. I worked for Data General for 3.5 years until a couple of months
| ago, and spent most of my time using AOS/VS C. The code generation is dreadful.

And how many of these places where it generated bad code did you
submit a SPR for?  I don't recall too many complaints about code
generation, particularly in the 4.00 compilers (and the only UK person
I remember was Phil Gladstone). Given the constraints of the machine
(particularly only two index registers, which pretty much requires the
frame pointer be kept in Ac3 in order to spill registers).  The DG MV
was an exceedingly difficult machine to generate good code for.

| When writing machine code patches I was frequently able to find room for them
| simply by optimising the existing code by hand. Also, the compiler is neither
| a traditional flavour compiler nor is it ANSI compliant. It is infuriatingly
| inbetween. 

Ugh, it couldn't be an ANSI standard compiler, since 4.00 came out
well before the standard became offical.  The C compiler started out
as a K&R compiler, not a PCC compiler.  As people noted differences,
we would address them, but given that we could not look at the PCC
sources (licensing requirements), it was a continual game of catch up.
Also, once you have an existing customer base, you want to manage
transiitions to different language rules gracefully.

|	     I had to write code that would compile with no warnings or errors
| under all three of AOS/VS C 4.01, GNU C for the Aviion 4.30, and Microsoft
| C rev 5.10. This was tough work as we had to have the highest level of
| warnings turned on. Most of the problems stemmed from the lack of various
| features in the DG compiler, often in the pre-processor. Also the way it treats
| all "word pointers" as being the same when doing prototype checking is
| criminal. A "struct foo *" and a "struct foo **" are very different and your
| program will go bang if you mix them up. Does the DG compiler tell you? Not
| on your life. The number of bugs I found at runtime which could have been
| found by the compiler was fairly high. Sometimes I didn't even find them at
| runtime and only spotted them while doing a code review.

Yeah, I knew about this, and tried fixing it, but it would have taken
a rewrite of a lot of the front end to deal with it, and management
always had 3 times more 'urgent' work for me to finish.  The core of
the problem is, the DG compiler suite started out with PL/1, which
does not have real user defined types, and only simple 'pointer' types
(the type of the object pointed to was determined when you use it).
Thus, the common symbol table didn't keep enough information around.

| About the only word
| of praise I have for the DG compiler are the compilation warnings. Most
| compilers just say "Type mismatch on line 23". The DG compiler tells you
| the two types involved, and also displays the line of the source file on
| which the error occurred. It also gives you the real line number as well as
| the #line setting, which can sometimes be wrong. GNU C guys take note - the
| GNU C warnings are about as helpful as a poke in the eye with a sharp stick.

Many unix people complained about the verbose error messages.  One
person wanted to see 24 different error messages on the screen at the
same time (hence -Cbrieferror which cut down the number of lines to
the minimum that the back end utilities would allow).  Evidently
nobody ever told you about GNU emacs' compile mode, where you run make
in a buffer, and do C-x ` (aka next-error), and it puts the file in a
buffer, and sets the cursor to that line.  I find it annoying when I
compile stuff with the MIPS compilers, because they don't work with
that method (and the fact that they don't chop the line being printed
out to 79 characters, so the output wraps several times in printing
the line).
--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?