Re: Lousy code generation (Re: MoriaGS 5.3.1 coming...)

[nathan@cco.caltech.edu (Nathan Mates)]

In article <jpenne.734744316@ee.ualberta.ca> jpenne@ee.ualberta.ca (Jerry Penner) writes:
>nathan@cco.caltech.edu (Nathan Mates) writes:
>
>>As a player of the previous "version" for the Apple IIGS, Rogue, I can only
>>say that I hope you're not using MPW C to compile it. Rogue had one of the
>>worst bits of bloated machine language generated of any compiler around.
>>MPW compared 2 numbers by subtracting them, and a lot of other stuff that
>>made the code lots bigger than it needed to be, and definitely slower.
>
>Subtracting two numbers takes just as long (or short) as comparing
>them.  I think you'll need to come up with a better example than that.
>What else about MPW C's generated code is bloated?
    Sorry to disagree with you. As the chart that came with my ORCA/M 1.1
assembler says, the sbc #xxxx and cmp #xxxx operands both take the same amount
of time. That I'll give you. But, look at what's necessary before subtraction
as opposed to comparing the numbers: a sec instruction. 2 measley cycles.
That's it...

   2 cycles multiplied by several million comparisons in the program is the
problem, though... I just pulled the game up (I've hacked it as part of my
GameHacker project, so I do have some intimate experience with taking apart
it), and dropped in at an honestly random spot, and listed it under the
monitor until I found an example. If you want to check it out, it's +720A
from the segment in memory that's $E58B long. Here's what the monitor says:
(long i,m mode on, paraphrased by me. Timing cycles are at right)

720A: lda F0              (4+)
720C: sec                 (2)
720D: sbc #0003           (3)
7210: bvs 7215 {+03}      (2,3)
7212: eor #8000           (3)
7215: bmi 7230 {+19}      (2,3)
7217: lda xxxx
   some other random code...
7230: lda yyyy

   This is from the version I have, dated 9 Jul 91 19:07. Let's take a look at
the code: It gets something from the current direct page, no big deal. Then,
it sets the carry flag for subtraction, then subtracts the test value from it,
3. Then, it plays around with its registers and all. I really don't want to
get into too much detail, but running this code fragment showed that if the
test value is greater than or equal to 3, it goes to 7230, if less, it goes
to 7217. You want lousy coding? Here you go. There are lots more that I could
find just looking through (ths code at 7230 sure seems to look suspicious :);
this code is bloody wasteful. 

   To show what I mean, let's see how anybody with some knowledge of 65816
assembly would write this:
720A: lda F0     (4+)
720C: cmp #0003  (3)
720F: bge 7230   (2,3)     (bge==bcs== branch GREATER THAN OR EQUAL TO!)

    That's it. Lots shorter, and much nicer than looking at random register
eor'ing, bvs's (what purpose do they really serve-- the carry flag has the
same info?), and all. The contents of the accumulator was trashed by the
random eor, and furthermore, the accumulator's contents are thrown out after
this segment. Thus, there is no real point to the accumulator's contents
after exiting this routine, and the flags aren't important.

   If you can point out something that I've missed in this, go ahead. The
code works, I'll give it that, but it's rather wasteful of memory and
processor time. I was half thinking of writing an optimization program to
go through the code, scanning for things like this, and replacing it with
the shorter code, but now that moria's coming out, why bother?

   Sorry for taking up so much net space and going into detail, but I honestly
beleived you challenged me to prove my assertations.

Nathan 

>-- 
>Jerry Penner   jpenne@ee.ualberta.ca   or   jjp@myrias.ab.ca


-- 
* Nathan Mates nathan@cco.caltech.edu * MSC #850, Pasadena  CA 91126
* No fancy quote, no disclaimers for irate employers, no .sig-- oops,
* Too late for that! Several Megabyte joke collector and IIGS hacker 
* operating out of Caltech, the world's best place for an education!