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

[bazyar@teal.csn.org (Jawaid Bazyar)]

nathan@cco.caltech.edu (Nathan Mates) writes:

>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

  That code isn't random; it's a signed comparison.  Declaring a
variable as 'int' and then comparing that variable to values will always
produce the above code on a IIgs, because the compiler cannot assume
that you're never comparing it to a negative number.  To improve performance,
you'll need to go into the source yourself and change 'int's to 'unsigned's.
But make sure that negative values are never used, or you're hosed.

>    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. 

  Your code, while indeed faster, is not a signed comparison and thus
isn't the same, functionally.

  MPW C isn't all that bad; ORCA/C 2.0 is better but for the bugs.
-- 
 Jawaid Bazyar              |   Ask me about the GNO Multitasking Environment
 Procyon, Inc.              |   for the Apple IIgs!   
 bazyar@cs.uiuc.edu         |   P.O Box 620334
 --Apple II Forever!--      |   Littleton, CO 80162-0334   (303) 781-3273