Path: utzoo!censor!comspec!humvax!becker!ncrcan!attcan!uunet!tut.cis.ohio-state.edu!snorkelwacker.mit.edu!paperboy!meissner From: meissner@osf.org (Michael Meissner) Newsgroups: comp.os.aos Subject: Re: DG C compiler Message-ID: Date: 28 Dec 90 19:41:59 GMT References: <4471@acorn.co.uk> Sender: news@OSF.ORG Distribution: comp Organization: Open Software Foundation Lines: 75 In-reply-to: osmith@acorn.co.uk's message of 13 Dec 90 17:52:50 GMT (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?