hardy@sdccsu3.UUCP (Jeff Hardy) (05/30/84)
I would appreciate any information leading to getting a C compiler for a DEC PDP-11 running under RSX. Thanks in advance. Jeff Hardy ..!sdcsvax!sdccsu3!hardy
ron@brl-vgr.ARPA (Ron Natalie <ron>) (06/01/84)
Friends of mine have had reasonable luck with the Whitesmith's one. -Ron
boylan@dicomed.UUCP (Chris Boylan) (06/03/84)
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!boylanboylan@dicomed.UUCP (Chris Boylan) (06/04/84)
I have to do a 1984 and unsay something. In my original article
on the Whitesmith C compiler I mentioned a problem we had with
external declarations and compatiblity between pointers and arrays.
Simply hordes of people have been sending me mail telling me that
they aren't compatible and that I'm confused, some less politely
than others.
While I, and the person I worked with on the project, remember
testing the code involved we cannot remember the specific problem.
As we remember it, the code did work correctly on UNIX but generated
a garbage assignment on RSX using the Whitesmith compiler. It is
unfortunate that that document I ~r'ed in was written after the
fact since the macro code was obvious correct for the pointer/array
question.
Since I cannot offer definitive proof that we weren't doing something
goofy, I will unsay what I said, if you follow what I mean.
Sorry for the confusion.
As to my contention that the Whitesmith C compiler was somewhat lacking
in optimization, it was clear from comparing the .s output that
it didn't do any significant amount of optimization.
If they used different csav/cret's for procedure calls we would
never have noticed it for the obvious reason.
--
Chris Boylan
{mgnetp | ihnp4 | uwvax}!dicomed!boylanstein@druny.UUCP (SteinDW) (06/04/84)
I have had bad experiences with the Whitesmith C compiler under RT-11. First, relatively small modules of code (200-250 source lines) would not compile. Pass 2 complained of no memory space. This made partitioning of the program into inconvenient modules a neccesity. Second, the "open" function destroyed the "onexit" (Whitesmith added function) chain making the Whitesmith exit handler practically useless (unless you opened EVERY needed file before intializing the exit handler). Don Stein "Aiko-Aiko"
dan@idis.UUCP (06/06/84)
A mild defense of Whitesmith's C compiler: I have been using a slightly old version of the Whitesmiths C compiler for several years. I have stumbled across a few circumstances in which it generates bad code, but for the most part it does just fine. I have occaisonally investigated other people's complaints about Whitesmith's C and have often found that the compaints were about behavior that was unexpected but not actually wrong. For example, Whitesmith's C requires that global variables be initialized in one source file. This is really a requirement of the RSX task builder (the RSX linkage editor) and I cannot fault Whitesmith's C for using the standard RSX task builder. Other typical complaints are about the Whitesmith's I/O library (not like the UNIX "standard I/O library") or the C preprocessor (allows at most one include file library directory; does not understand "../"). Gee guys, If you wanted UNIX you should have bought UNIX (instead of RSX). The worst thing I would say about the Whitesmith's C compiler for RSX is that it doesn't always complain about bad source code (garbage in ... garbage out) and is a little bit version 6ish. I have had much worse experiences with the DECUS C compiler (thought pointer variables took up zero bytes and didn't understand that casts implied conversion; no macros with arguments!). I believe some of these problems have been fixed. Does anyone know where I can get a current version of the DECUS C compiler? I want to use it with my RSX emulator to build RSX binaries on my UNIX system. Everything I get directly from DECUS seems to be out of date. Does anyone know of a public domain task builder for RSX? Dan Strick [decvax|mcnc]!idis!dan (412) 624-2135 (412) 624-5218