C compiler for pdp-11 under RSX

[Chris Boylan]

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