Path: utzoo!attcan!uunet!lll-winken!ames!elroy!orion.cf.uci.edu!ucsd!rutgers!njin!princeton!phoenix!mbkennel
From: mbkennel@phoenix.Princeton.EDU (Matthew B. Kennel)
Newsgroups: comp.sys.mac.programmer
Subject: Code generation in LSC
Message-ID: <5801@phoenix.Princeton.EDU>
Date: 25 Jan 89 08:21:30 GMT
References: <1112@dogie.edu> <6337@hoptoad.uucp> <5623@phoenix.Princeton.EDU> <11494@haddock.ima.isc.com>
Reply-To: mbkennel@phoenix.Princeton.EDU (Matthew B. Kennel)
Organization: Princeton University, NJ
Lines: 95

In article <11494@haddock.ima.isc.com> suitti@haddock.ima.isc.com (Stephen Uitti) writes:
>
>Some time ago, I ran some C benchmarks on a Mac II & Sun III.  Both
>machines have 68020's, the SUN ran at 20 MHz, the Mac II at
>15.something.  LSC 2.15 vs the standard Sun "cc".  Optimization flags
>were used on the Sun.  The Mac tended to have run times that
>were very close to those of the Sun, with some run times actually
>faster than the Sun.  Compilation speed is also tremendously greater.

Hmm. This is surprising.  What kind of benchmarks did you use?
How did you time them? 

>
>Compilation speed of Turbo C for a 7.16 MHz XT clone is more than
>three times faster than a VAX.

A VAX isn't everybody's idea of "Speedy Gonzales" :) but the point
is true.

>  "Even on microcomputers" is incorrect.
>The compilers for PCs and Macs are MUCH better than for larger
>machines.  It even makes sense.  There is more money in it.

In terms of compile time and overall convenience, undoubtedly.
Code generation?  No.

Just looking at some of my programs with MacsBug, I can see
many _obvious_ inefficiencies that a even a peephole optimizer could remove:

	MOV.L -(SP), DO
	MOV	DO, D6
or reloading the same expression which was already in a register.

LSC doesn't do other kinds of optimizations such as turning

for(i=0; i<=num; i++)
	d += a[i];

into

register int	*p;
for(p=a; p< a+num; p++)  /* a+num should _not_ be computed in each iteration */
	d += *p;	 /* of the loop! */	 


For these trivial examples, it's no big deal, but in complicated
computationally-intensive programs, all of these types of optimizations
combine and can be very significant.

Note that I generally write scientific programs with lots of loops, &
arrays and such in which good optimization can make a big difference.

I suspect that many Mac applications are of the type

	Sys_Call();
	twaddle structures()
	User_function()
	go back to beginning

and so these kind of "global" optimizations aren't so important.
Intelligent register usage should always be a win, though!

>
>Would gcc be better than LSC?  Well, gcc would never produce code as
>quickly, gdb would never be as nice as LSC 3.0, you'd need "make",
>etc.  The code *might* be as fast as LSC's code.

If it were _only_ as fast at LSC, I'd think it were broken! :)

Seriously, I've looked at the output from good optimizing compilers,
and in general, they do a better job than I (admittedly a non-expert
assembly programmer) could do without a very large amount of effort.
(This is on "normal" programs: not freaky things like device drivers
and interrupt handlers)

Looking at the output of the MIPSco C compiler, I am completely 
astounded as to the transformational magic that it manages to perform
on my programs.  (Then again, BASIC would scream on a MIPS)

>  It probably wouldn't
>be as fast, since one would probably make int's 32 bits.
>

Quite true.  But isn't this true only for a 68000, i.e. shouldn't
a Mac II be as fast w/ 32 bit ints as 16?  (I think that some minis
are _slower_ accessing 16 bits rather than 32!)

NOTE: My direct experience has _ONLY_ been with LSC 2.15.  If things
have changed significantly, please correct me!  Thanks.

>Stephen.

Matt Kennel
mbkennel@phoenix.princeton.edu
"Assume a spherical cow."