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

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

In article <bazyar.734856002@teal> bazyar@teal.csn.org (Jawaid Bazyar) writes:
>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:
>>>

>>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.
>
   Ok, so the compiler's trying a signed comparison? Hm. Basically, since
we`re comparing the value to #3, any negative value will be less than 3. Well,
at the expense of one more line, let's see what sort of assembly we can 
devise that doesn't have eor's and all running around. As this is getting more
abstract, I don't think that more abstract code would probably be better. 
Here's try #2 from me for a signed-word comparison with #3.

    lda value
    bmi LessThan
    cmp #3
    bge GreaterThan
LessThan ...

GreaterThan ...

   Yes, it would take some logic to use this type of code; namely seeing that
it is a signed comparison with an always positive number; for comparisons
with other variables, I the long form would probably still have to be used,
but for this case (and there are lots of them in standard programs that I've
poked at in the monitor), some improvement is called for...

Nathan 



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


-- 
* 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!