Xref: utzoo comp.sys.att:2829 unix-pc.general:491
Path: utzoo!mnetor!uunet!umbc3!alex
From: alex@umbc3.UMD.EDU (Alex S. Crain)
Newsgroups: comp.sys.att,unix-pc.general
Subject: Re: gcc for the 3B[12] ???
Message-ID: <894@umbc3.UMD.EDU>
Date: 22 Mar 88 06:20:54 GMT
References: <4480@xanth.cs.odu.edu> <31200017@ccvaxa> <809@wucs2.UUCP> <1442@vu-vlsi.Villanova.EDU>
Reply-To: alex@umbc3.UMD.EDU (Alex S. Crain)
Organization: University of Maryland, Baltimore County
Lines: 68

In article <1442@vu-vlsi.Villanova.EDU> elh@vu-vlsi.Villanova.EDU (Edward L. Hepler) writes:
>In article <809@wucs2.UUCP>, dwex@wuccrc (David Wexelblat) writes:
>> In article <31200017@ccvaxa> aglew@ccvaxa.UUCP writes:

[stuff deleted about who's porting what and wher to get it]

>computer architecture work that I am doing.  alex@umbc3 has added unixpc tm and
>md files to allow gcc to generate code that the 3b1 assembler likes.  He has
>generated diffs and should be contacted for a copy.  I ran some of the common 
>"benchmarks" using both the distributed C compiler and GCC and thought that you
>all might like to see some of the results.  Note that since both compilers use
>a common I/O subsystem, the only real differences show up in "CPU intensive"
>benchmarks..  I haven't figured out yet why Dhrystone is slower with GCC??!
>
>Ed Hepler
>elh@vu-vlsi

[lots of benchmarks deleted. Most are fairly close between gcc and cc]

>dryr: 831 dhry/sec   1:01.1 1:00.5 0.1 1049 d/s48.6   47.9   0.1
>drynr: 831 dhry/sec  1:01.1 1:00.5 0.1  987 d/s51.7   50.9   0.1

	Alot of folks are talking about how wonderful gcc is, and it is, 
BUT...

	Gcc has a couple big advantages. It has fewer bugs than cc, and If
you find a bug, you can report/fix it. Try talking to AT&T about internal 
compiler errors. This is why it it my default compiler.

	Playing with gcc has also taught me ALOT about compilers and large
systems in general. It is very well designed, very portable, and well
documented.

	Gcc has a sizeable drawback. While the code generation algorithm is
superior to cc, It isnot/cannot be very machine specific. And on a 3b1 this 
is a big lose. All 'complex' math operations, ie: long * long, are machine
dependant. they are handled through calls into a library gcc-lib, which is
a batch of functions that look like:

mull2(i1,i2)
	long i1,i2;
{
	return i1 * i2;
}

which are compiled by /lib/cc and then linked into the gcc objects.

	All is not lost, however, This can be turned into an advantage. It
is possible to reconfigure gcc to generate inline code instead of function 
calls, or optionally call alternate libraries. So one could call a library
that did fixed point math instead of floating point, for a big WIN in graphics
programs. This works because the floating point format is entirely determined
by the library calls.

	The bottom line is, gcc is a wonderful toy. It is fun to play with and
has its advantages. But it won't add any MIPS to a 3b1, at least until someone
tunes it pretty heavily. 

BTW: I will be starting that tuning in a month or so, If someone could point me
at a source for some fast fixed-point routines in 68K assembly, I would 
certainly appreciate it.



-- 
					:alex.

nerwin!alex@umbc3.umd.edu
alex@umbc3.umd.edu