Comparing RT C compilers....
User Rdkeys Robert D. Keys
AOS C compilers are (pcc, high-c, gcc)? I am trying to decide
which would be the best to use for things like generic compiles,
kernel compiles, etc. No fancy C++ is needed, except maybe for
groff where gcc is the only option.
Thanks
Bob Keys
Mark Whetzel
This was contributed a long time ago (1993) by Keith Moore, for the
AOS part of my FAQ. This tells a little of the compiler 'quirks' but
does not indicate which is best..
==**==**==**==**==**==**==**==**==**==**==**==**==**==**==**==**==**==**
Submitter: Keith Moore date: Mon Apr 12 17:14:45 1993
Three different C compilers came with the Dec 1988 release of AOS:
"hc" is the MetaWare High C compiler, version 2.1n.
"hc1.4" is an old version of MetaWare High C.
"pcc" is a port of the Portable C Compiler (dating back to Unix V7
days) to the RT. It does not generate very good code, but is
sometimes useful to work around hc bugs.
Each of the compilers is useful sometimes; none of them suffices
for every occasion. The MetaWare compilers generate reasonably good
code, but are notorious for optimizer bugs. They recognize a language
which is almost, but not quite, ANSI C. (One of its worst sins is
#defining __STDC__ when the language it accepts is not ANSI C;
adding a -U__STDC__ to the command line cures all kinds of evil.)
Pcc is sometimes good for compiling old code that the MetaWare compiler
barfs on, when you don't care about performance.
In fact there were at least three versions of hc2.1 available at
various times...hc2.1n was supplied with the Dec 1988 system, and
hc2.1s and hc2.1y were available via uucp from 'ibmsupt' later on.
Hc2.1n is buggy enough that you'll have trouble, say, building a
working copy of X11R? with it. Unfortunately, even the latest of
these (hc2.1y) had bugs in code generation which caused kernels
based on this compiler to break. In general, however, you can use
hc2.1s or hc2.1y.
To find out what version you have, compile a small program and look
at the resulting .o file. Like so:
echo 'main() {printf ("hello,world\n"); }' > foo.c
cc -c foo.c
nm foo.o | grep hc2.1
...and you'll see something like
00000000 A .oVhc2.1y
Here's a small hack that allows me to use these interchangably:
===========================================================
#include <stdio.h>
/*
* hc-hack.c
*
* This program allows you to install several different versions
* of hc and run each of them by name (e.g. "hc2.1s").
* This is useful because no version of hc yet produced compiles
* everything without significant brain damage.
* To install, copy this binary to somewhere in the
* search path (perhaps "/usr/bin"), and create a link for every
* version of hc you have (example: "ln hc-hack hc2.1n").
* Then create a directory for each version of hc in /usr/lib
* (example: /usr/lib/hc2.1n), and place the appropriate versions
* of hc1com and hc2com in that directory.
* One of these directories will probably contain links to the copies
* of hc[12]com in /usr/lib, which hc uses by default.
*
* Now you can run hc2.1n, hc2.1s, or hc2.1y as you need to.
*/
main (argc, argv)
char **argv;
{
char *basename;
char *strrchr (char *, char);
char **new_argv;
char hc_lib_dir[1024];
char *calloc (unsigned int, unsigned int);
int i;
basename = strrchr (argv[0], '/');
if (basename == NULL)
basename = argv[0];
else
basename = basename + 1;
sprintf (hc_lib_dir, "-B/usr/lib/%s/", basename);
new_argv = (char **) calloc (argc + 2, sizeof (char *));
new_argv[0] = "hc";
new_argv[1] = hc_lib_dir;
for (i = 1; i < argc; ++i)
new_argv[i + 1] = argv[i];
new_argv[argc + 1] = NULL;
fprintf (stderr, "%s", new_argv[0]);
for (i = 1; i < argc + 1; ++i)
fprintf (stderr, " %s", new_argv[i]);
fprintf (stderr, "\n");
execv ("/bin/hc", new_argv);
perror ("/bin/hc");
exit (1);
}
===========================================================
In addition to the compilers above, gcc 2.x can generate code
for the RT. It is availble for anonymous ftp prep.ai.mit.edu,
directory pub/gnu, and from other GNU/FSF archive sites.
==**==**==**==**==**==**==**==**==**==**==**==**==**==**==**==**==**==**
Hope this helps... perhaps others will know more about AOS compilers
and their failings..
Later,
markw
--
Mark Whetzel My comments are my own, not my company's.
Western Geophysical - A division of Western Atlas International Inc.,
A Subsidiary of Western Atlas Inc. addr: mark.w...@waii.com
VOICE: (713) 689-2544 FAX: (713) 689-2758
Derrick J Brashear
<rdk...@seedlab1.cropsci.ncsu.edu> wrote:
> > Can anyone give me some relative feedback as to how buggy the RT
> > AOS C compilers are (pcc, high-c, gcc)? I am trying to decide
> > which would be the best to use for things like generic compiles,
> > kernel compiles, etc. No fancy C++ is needed, except maybe for
> > groff where gcc is the only option.
I've used gcc 2.7.2 to build both kernels and AFS(*); I've also built kernels
with the newest hc, but never pcc. I did once have to build an all
hc-some-older-version kernel except one .o file, which I built with pcc, but I
immediately got a newer hc, which solved the problem
-D
Chris Chiappa
>Can anyone give me some relative feedback as to how buggy the RT
>AOS C compilers are (pcc, high-c, gcc)? I am trying to decide
>which would be the best to use for things like generic compiles,
>kernel compiles, etc. No fancy C++ is needed, except maybe for
>groff where gcc is the only option.
My experience:
pcc - Useless
hc - Almost useless. Use it only if you need it (ie the Kernel)
gcc 2.5.8 - Moderately useful, generates better code than hc but has a
certain set of bugs
gcc 2.7.2.3 - Most useful. Also generates better code than hc, but also has
bugs. These bugs are generally different from 2.5.8 bugs :)
Generally I try to build something with 2.7.2.3, but if that fails
(mysterious segfaults, assembler refuses to compile bad output etc) I drop
back to 2.5.8. I don't think I can recall ever having a problem solved by
using hc with the exception of one weird file in X11R5 I think.
My basis for the "better code" thing isn't very scientific; I compiled an
old rc5 client however with all compilers available and the 2.7.2.3 client
was twice as fast as the one generated by hc. Could be a fluke but I
wouldn't bet on it. As far as I know, egcs won't compile out of the box on
an RT, but it might be interesting to get it working and see how well it does.
--
+------- --- -- -- -
| gri...@snurgle.N0-SPAM.org / My opinions represent snurgle.org :
! Unspoilt by progress / http://www.snurgle.org/~griffon |
- -- -- --- -------+
User Rdkeys Robert D. Keys
>> In comp.sys.ibm.pc.rt User Rdkeys Robert D. Keys
> <rdk...@seedlab1.cropsci.ncsu.edu> wrote:
>> > Can anyone give me some relative feedback as to how buggy the RT
>> > AOS C compilers are (pcc, high-c, gcc)? I am trying to decide
>> > which would be the best to use for things like generic compiles,
>> > kernel compiles, etc. No fancy C++ is needed, except maybe for
>> > groff where gcc is the only option.
> I've used gcc 2.7.2 to build both kernels and AFS(*); I've also built kernels
> with the newest hc, but never pcc. I did once have to build an all
> hc-some-older-version kernel except one .o file, which I built with pcc, but I
> immediately got a newer hc, which solved the problem
I tried the gcc-2.7.2, and could not get it installed correctly. At what
tree level does it need to be installed out of the tarball, and where do
the binaries need to go, or should they just be linked from usr/bin?
Likewise for the manpages? When I installed it, things got mixed up and
it came back with an installation error message.
What version of hc was that, if you remember?
Thanks
RDK