james@bigtex.cactus.org (James Van Artsdalen) (07/27/89)
In <115802@sun.Eng.Sun.COM>, plocher@sun.UUCP (John Plocher) wrote: > On the 386 Gnu gcc is better than the standard pcc based compiler > provided by ATT, but not much. It *is*, however, the best compiler in > its price range :-) gcc is in general better than pcc in code generation. It is substantially better in the source language (ie, gcc is ANSI). gcc is much better supported by the compiler "vendor" than pcc. gcc currently doesn't really know much about the 387. The stack architecture just doesn't seem to fit the gcc register model. As a result the FP code generated isn't very impressive. The gcc high level analysis is good enough to be generally competitive with PCC, but that's it. There is no Weitek support currently. Apparently no one wants it enough to implement it. I would expect gcc to do quite well with the Weitek, since gcc should understand the register model. The gcc 1.35 machine description was also missing a couple of entries, most notably integer division. gcc was also using the lea instruction too much, instead of using adds and shifts (which are faster when not moving between registers at the same time). The important question left out was reliability. I consider both compilers reliable, with PCC likely more reliable since it is trying to do a lot less. As for Hi-C and Greenhills, I decided to do a performance measurement of my own on a more reasonable benchmark: the GNU C compiler itself and emacs. This should be much more representative of the real world that some FP and string benchmarks. Unfortunately, neither GHS or Hi-C proved up to it. Most of the gen* utilities in gcc dumped core when compiled by Hi-C, preventing me from generating cc1. I would have figured out why with gdb/sdb, but Hi-C generated a bad symbolic debug table in the executable. I tried Hi-C on emacs, but Hi-C's preprocessor choked on ymakefile, and the compiler couldn't handle a couple of other constructs in the C code. GHS aborted on two files in the gcc source and caught an internal error in one other case. I did manage to build cc1 (by turning off -g and -O), but the result cc1 dumped core trying to compile c-parse.tab.c. I was going figure out why it failed, but GHS generated a bad COFF debug table too. I ran out of energy before getting to GHS & emacs. Neither Hi-C nor GHS worked with shared libraries. The point I'm trying to make is that when comparing gcc (or pcc) against other compilers, one can reach different conclusions depending on the tests run. Compiler vendors have a habit of tuning their compilers to match the trendy Benchmark of the Day, and failure to run larger or more general tasks can be misleading. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759 512-338-8789