Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site dicomed.UUCP Path: utzoo!watmath!clyde!burl!mgnetp!dicomed!boylan From: boylan@dicomed.UUCP (Chris Boylan) Newsgroups: net.wanted,net.lang.c Subject: Re: C compiler for pdp-11 under RSX Message-ID: <192@dicomed.UUCP> Date: Sat, 2-Jun-84 20:17:10 EDT Article-I.D.: dicomed.192 Posted: Sat Jun 2 20:17:10 1984 Date-Received: Tue, 5-Jun-84 08:27:24 EDT References: <1880@sdccsu3.UUCP> Organization: DICOMED Corp., Minneapolis Lines: 123 Keywords: DECUS C, Telecon Systems, Whitesmiths First, I am sorry this is so long. I know of three C compilers available for RSX. I would appreciate it if people would post something if they know of others. We use the Whitesmith C compiler here but are not terribly happy with it. This information is less than six months old. The worst is the Telecon C compiler available from: TELECON SYSTEMS 1155 Meridian Ave., Suite 218 San Jose, CA 95125 . . . Unfortunately, after examining your product we have determined that it is unacceptable. It contains numerous bugs that showed up with casual use. In addition the code generated seems well suited to an eight bit processor but is very inappropriate for a sixteen bit machine with multiple registers. Don't waste your time with it. It is basically garbage in it's current form. There is the DECUS C compiler, see your DECUS order book for more info. This compiler hasn't had a lot of work done on it recently and has a few problems. I worked on a 15K line C software package and we had to switch to the Whitesmith C compiler eventually. The only thing I can remember about our problems right off hand is that the floating point version we had was missing a file or it was just plain wrong as distributed. The problem was with doing floating i/o and everything seemed alright computationally although we gave it up before we did anything extensive with it. We found at least one bug in it (I don't have it written down) and a tendency to not generate errors where it should have. It is usable in non floating point applications. The Whitesmith C compiler preceeded itself with a bad reputation. The people who I know who have used it complained it had quite a few bugs in both the RSX version and the VMS version. I/they don't remember what they were, except that the VMS version didn't convert floats to ints right in coersion, something like that. I dislike their requirement that all global data be initialized to work but worse than that, they don't flag it if you don't initialize it which means you don't notice it until you try to link it. This is a real pain in the butt if your working with a lot of code ... Their coding style and thus their documentation is non-standard and they typedef EVERYTHING to a bunch of stupid names. (reverse flames to /dev/null.) The code generated isn't very compact but at least the thing is usable. The pointer/array bug was a real bitch to fix in our code which we did mostly under UNIX first. It in someways reflects a mistake in our coding style, but still it should have worked. Here are a few bugs from the Whitesmith C compiler: Whitesmith C Compiler Bugs. The first of these is with the 'switch' statement. Namely the compiler does not detect a syntax error for the following case : [this seems to be legal from net.lang.c but it should still issue a warning that the code is unreachable, shows the dangers of Y+P in vi] switch(v) { S1; case L1: S2; break; case L2: S3; break; ... } the statement 'S1' is not flagged as syntactically bad. Another bug in generated code also comes from the 'switch' statement. The 'default' label must have at least ONE statement, even if it is only a break. If nothing is present, incorrect code is generated. The third bug comes from a result of interchanging arrays and pointers. (Although the C programming Manual specifically has an example to show that this is indeed permissible) The declartions extern TYPE v[]; and extern TYPE *v; causes the WHITESMITH compiler to generate DIFFERENT code. Namely if we have extern TYPE v[]; .... p = v; the code generated is MOV #v,p which is what one would expect. whereas if we have extern TYPE *v; .... p = v; we get MOV v,p which is NOT what one would expect. -- Chris Boylan {mgnetp | ihnp4 | uwvax}!dicomed!boylan