All the gnu stuff (long)
Alex S. Crain
alex at umbc3.UMD.EDU
Tue Sep 20 10:33:16 AEST 1988
Brant Cheiks (Hope thats spelled right) asked for the status
of all the GNU stuff, so I checked around. this information is as
accurate is I could make it.
BISON/GNUMAKE/GNUGREP, etc: These work as advertised. I think
that Bison generates better compilers then yacc, but I'm not sure.
last I heard, gnumake was moving towards compatability with system 5
make, so there's probably no gain there. I remember hearing thta
gnugrep was significantly faster then bsd or sysV grep, but again, I'm
not sure.
GNUCHESS: beats me every time :-). Still no graphics support
for the 3b1, although they include bitmaps for all the pieces with the
distribution.
GCC: The compiler works very well and is complete as of 1.26.
1.27 was released with bugs unrelated to the unixpc, (Shame, shame,
rms), they were corrected in a hurry, and 1.28 was released shortly
thereafter. gcc still (and always will) irritate a bug in /lib/cpp, so
boostrapping is a pain. Once you have a running gcc, though, just type
'make'. gcc uses the 3b1 assembly format, with sdb style debugging
info.
gcc offers a couple of advantaged over /bin/cc. It is true
ANSI-C, with all that that impies (function prototypes, volitile,
etc), with some non-ANSI extensions, such as inline functions, etc.
gcc supports optional 16bit default ints (-mshort).
Unfortunately, the librarys do not, but its nice to know. There are
also some other machine dependant switches like -momit-frame-pointer,
which are fun to play with, if nothing else.
With the exception of the gnulib math routines, gcc produces
much better code than /bin/cc. Since gnulib is produced by /bin/cc, it
contains a fair bit of overhead. It would be trivial, however, to tune
gnulib to the point where it was nearly as good as the stock librarys.
In fact I did it, but never finished it.
There arn't many bugs in /bin/cc, but they are there. I am not
aware of any bugs in gcc, which I use very regularly. sdb support is
still very new, but it appears to work well. If you do find a bug in
gcc it will be fixed, no one has touched /bin/cc for awhile.
GDB: Bob Rose (rrr at naucse.UUCP) built gdb for the 3b1, using
COFF object code and sdb debugging info. I haven't used gdb on the 3b1
yet, but I know that gdb on a VAX makes sdb look real cheesy. because
it uses sdb info, gdb will work with gcc or cc. Unfortunaty, Bob has
declined to support the port, so I imagine that it will be awhile
before its very stable :-(. On the other hand, GDB is moving in the
COFF direction, so if Bob sent his diffs off to mit, they will
probably help the general effort. (Bob? are you listening? send them
to rms at wheaties.ai.mit.edu).
GAS/GLD: This stuff works, BUT produces BSD format objects. It
also supports an extended symbol table format for gdb, and is
potentially really nice. I have heard reports of gas producing COFF
format object files, but have never actuall seen it. I've been asked
to work on a program to convert COFF objects to BSD and back
again...Interesting? yes. Useful? maybe. The idea is to generate a
write/make/debug system using bsd objects, and then convert them to
COFF for execution. I like the idea of a COFF object with BSD symbol
table info tacked on the end. All of its sort of goofy.
C-Scheme: I heard that someone had this running once, but not
much after that. Its reasonable to think that it might, but with KCL
and Xlisp up and running, I doubt that it will have much of a
following.
CONCLUSIONS: I've been involved in gcc for awhile now, and I'm
a bit biased, since alot of the code is mine, but here goes.
GAS/GLD/C-Scheme - hacker material, and will stay that way for
at least a year.
GDB - I don't know how well this works, I would image that its
at least as nice as sdb, even if it has bugs. In theory, gdb is really
slick, and since debuggers are programmers toys anyway, it probably
worth looking at.
GCC - I've been saying 'make CC=gcc' for so long that I hate
to rename it. I think instead that I'll play with the Makefile
defaults. In any case, I'm content with its performance. I'll be
posting assembly source for an optimized gnulib real soon, All I have
to do is wrap it. In any case, its at least as polished as /bin/cc,
with the exception of the intermitant bugs in 1.27.
GNUMAKE/GNUGREP/BISON/GNUCHESS.... - get em if you need em.
Bison is nice if you do alot of parsers, I wish that there was a
manual besides the yacc stuff.
--
:alex.
Systems Programmer
nerwin!alex at umbc3.umd.edu UMBC
alex at umbc3.umd.edu
More information about the Unix-pc.general
mailing list