osmith@acorn.co.uk (Owen Smith) (12/14/90)
>>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.)
meissner@osf.org (Michael Meissner) (12/29/90)
(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?
osmith@acorn.co.uk (Owen Smith) (01/11/91)
I put in an SPR a year or two ago against the 4.01 compiler. I was writing a library which replaced the standard versions of malloc() etc. and free() with new versions which stuck an allocation backtrace on the end of every heap block. This was used to help track down heap rot. The problem was that when I used getfp() as a $builtin function, the compiler generated an infinite loop. The process would crash when the loop ran off the end of the heap into the first invalid page. The workaround was to turn the optimiser off, or to use the function call version of getfp(). The SPR also contained lots of comments about code generation inefficiencies, and shortly after filing the SPR I followed it up with some more comments about code generation. For instance, why don't you use the WCMT instruction to do strcpy() as a $builtin function? My SPR and comments may well have gone through Philip Gladstone - I was working for the same team and Philip was used as a contact point for this sort of thing. To my knowledge, nothing ever came of my SPR.Nuke 'em 'til they glow, then shoot 'em in the dark!