Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!mcsun!ukc!acorn!osmith
From: osmith@acorn.co.uk (Owen Smith)
Newsgroups: comp.os.aos
Subject: DG C compiler
Message-ID: <4471@acorn.co.uk>
Date: 13 Dec 90 17:52:50 GMT
Sender: osmith@acorn.co.uk
Distribution: comp
Organization: Acorn Computers Ltd, Cambridge, England
Lines: 46

>>Does anybody out there run AOS???  It can't be that bad...
>>I was hoping that someone might know of a C compiler for AOS/VS that can be
>>found off the network.  Any replies about anything would be appreciated!
>
>There are several public domain C compilers that could be converted for 
>the MV architecture, but you will have to write your own back-end code
>generator (with only 4 wonderful registers). Two common public domain 
>compilers are the Gnu and Small-C compilers, but I don't know if either
>of these has ever been ported to an MV.
>
>We do all of our code development at SAS Institute in C - current estimate
>is about 2+ million lines of code, and use DG's C compiler. Except for
>a few minor problems (which are usually fixed very rapidly by DG), and
>code generation inefficiencies it is pretty good.
>

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

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.

Owen.

(PS. I worked on DG/X.400 revision 1.10, and CS/X.400 Gateway revision 1.00.)