From: kochmar@sei.cmu.edu (John Kochmar)
Subject: Re: Program in assembly...NOT! (was Re: Career in Video Games)
Organization: The Software Engineering Institute
Date: Fri, 11 Dec 1992 14:45:28 EST


In article <1992Dec11.092926.25433@cis.ohio-state.edu>, meekins@tortoise.cis.ohio-state.edu (Tim Meekins) writes:
|> ...
|> 
|> I've been programming the 65816 very actively since the day it was
|> released. Some of my experiences besides SNES programming is working
|> on a C compiler for the 65816. I've also worked with someone developing
|> 65816 generator for 'gcc', which you say is so great (and I believe you),
|> but even gcc could not grok the 65816. Even with the hardest effort,
|> gcc was outputting decent code for the 65816, nothing to be
|> ashamed about, but -any- 65816 programmer with any experience could
|> write the same program about 2 to 3 times faster.
|> 
|> To test some ideas awhile back, I wrote sieve program in C which
|> iterated 50 times.
|> 
|> my assembly version which I wrote ran in 4.19 seconds. the best C compiler
|> I ran with  full optimizarions took 9.5 seconds to run. Most other
|> compilers, including some using 'gcc' like optimizarions (though with
|> poor 65816 generation) took anywhere from 30 seconds to over a minute to
|> run. This is 10 times slower...you would think even a dumb compiler could
|> do better than this...but it can't due to the 65816 architecture.

You wouldn't expect a compiler, any compiler, to outrun a trivial
program hand written in assembler.  A lot of optimizations require an
overhead cost.  In a trivial program, this overhead will cause the
program to run slower than a hand-tuned assembly program.  I am
impressed that one of the compilers you ran produced code that was only
twice as slow as your program.  I would like to know whether at 50000
interations, which program ran faster.

But, back to the point, we're not talking about a trivial algorithm
that iterates 50 times.  We are talking about complex programs
requiring staff-years of work, and the effort of several people (at
least.)  It is not done in one sitting, and segents of code are
rewritten and rewritten.  A good compiler can methodically apply
optimization techniques each time the code is changed, even the best
programmers would be hard-pressed to do so.

I'm not going to comment on the increased burden of ensuring program
correctness in assembly, but I will say that assuming you know more
about the excentricities of the 65816 than any compiler writter (thus
making your assembly more efficient than any produced by a compiler) is
incredibly arrogant.

|> C was designed for processors like the Vax and 68000. fast C programs
|> use pointers and autoincrementors for the best possible code, such
|> as a strcpy: while (*a++=*b++); this sort of statement compiles
|> -very- poorly on a 65816. a for loop with array indexing will generate
|> much better code. this example shows that the 65816 just isn't
|> designed for 'C'. decent 'C' compilers can be written for it, but
|> the debate here is that the ever so broad statement that compilers
|> are better than any human programmers. This simply isn't true for
|> all processors, especially the 65816.

C was designed to reduce the burden of developing the Unix operating
system, and decrease the number of bugs introduced through programming
in assembly.  The intent of any high-level language is to allow you to
specify your program in logically defined constructs, and allow the
compiler to produce the most optimal code based on that specification,
while ensuring the logical correctness of the specification.  There is
no reason to generalize that just because a C compiler for the vax
would take advantage of the vax's strong points and avoid its
limitations, and that a compiler for the 65816 wouldn't do the same.

I never claimed compilers were better than human programmers,
obviously, since humans develop compilers.  But, what I did claim, and
I still maintain, is that for complex programs, a good compiler will
produce more efficient assembly code than doing so by hand.  I'm
sorry if you feel threatened by this statement, but that's the way
I see it.  Code generation and optimization techniques have come a long
way in the last 20 years.

|> TIM MEEKINS                    Ask me about GNO/ME! - MultiTasking on a IIGS!
|> meekins@cis.ohio-state.edu     Procyon, Inc., 11738 Aqueduct Drive
|> AOL: GNO Tim2 (@aol.com)       Littleton, CO 80127   (303) 933-4649
|>                           
|>       "Computers aren't intelligent, they just think they are."
|> 


-----------------------------------------------------------------------------
John Kochmar		 | Estimated amount of glucose used by an adult human
kochmar@sei.cmu.edu	 | brain each day, expressed in M&Ms: 250
SEI Computing Facilities |			-Harper's Index, October 1989
Newsgroups: rec.games.video