Re[2]: [cc65] optimizer?

Date view Thread view Subject view

From: groepaz (
Date: 2001-06-24 20:20:11

Hello Ullrich,

UvB> The optimizer is built into the compiler and it makes several assumptions
UvB> about the generated code, so it may not be used for generic assembler code.

thats what i thought.

UvB> On the other side, I cannot remember having a need to run an optimizer over
UvB> hand written assembler code.

there arent many to be honest, but in some rare cases it is really

UvB> As far as I understand it, the whole thing with hand written assembler code
UvB> is, that it is optimized by the programmer.

hehe well, and ofcoz it still is. =)

UvB> What would you expect such an optimizer to do?

well, there are several things an optimizer COULD do for handwritten
code, the simpliest beeing peephole-optimization (which in itself
again usually isnt necessary unless the assembler code was written by
a _bad_ assembler coder ;=), with the exception of unrolled code
generated by assembler loops). this is the only thing the optimizer i
am currently using (derivated from the one daniel dallman published on
his lunix pages) can do to be honest. it is useful for quickly
checking the quality of old source-codes in the first place (if you
see ";removed" a lot, the code probably sux ;D), and sometimes very
handy for writing optimized unrolled code.

some things i was thinking of to add to it (some time in the future
... hell as if i ever had the time ;D) were:

- replacing sequences of "legal" 65x opcodes by "illegal" nmos6510
opcodes (that would be pretty much a c64 specific optimization stage
primarily useful for demos only)
- replacing sequences of register-shifts by hash-table-accesses (need
one index register, so may be used after peephole analyzing) eg:


        lda something
        lsr a
        lsr a
        lsr a
        lsr a
        sta something

        ldx something
        lda lsr4tab,x
        sta something

...saving some cycles (and memory if used often enough to compensate
the tablesize)

- inlining small subroutines (with configureable max size / overall
codesize growth etc) again saving some cycles

- swapping registers in code-sequences (may be part of peephole

- re-order instructions to get better performance when conditional
branches are used a lot, eg


         lda value
         bne 1
         ; do something if value==0
         ; do something if value!=0

         lda value
         beq 1
         ; do something if value!=0
         ; do something if value==0

since VALUE is probably !=0 more often than ==0 the latter will
perform better in general-purpose code. this optimizing stage can
improve performance a LOT in unrolled recursive algorithms and alike.
you cant imagine how often i have seen conditional branches going the
'wrong' way in innerloops of certain algorithms, thus wasting
potential speed.

UvB> Can give me an example from your standalone optimizer?

the only thing it can do is removing some unnecessary register-loads,
no instruction reordering, no register swapping, no inlining, no
anything ,=)

UvB> Maybe I need such a thing and don't know it:-)

well, it pretty much depends on what kinda programs you are writing i
guess.... the only 'common' case where i could think of an optimizer
makes sence for handwritten asm code is when you use large loop/macro
constructs for generating unrolled speedcode (and that is primarily
used in demos).

.....whatever, before i'll go for another project, i'll better finish
this disassembler i am working on aswell ;D (just recently changed the
output to ca65 syntax to be honest ;=)) seems that i really need that
one for my "aztec challange" bugfix thing ;=))

Best regards,

To unsubscribe from the list send mail to with
the string "unsubscribe cc65" in the body(!) of the mail.

Date view Thread view Subject view

This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:40 CET