From: groepaz (groepaz_at_gmx.net)
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
useful.
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:
replace:
lda something
lsr a
lsr a
lsr a
lsr a
sta something
by:
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
optimization)
- re-order instructions to get better performance when conditional
branches are used a lot, eg
change:
lda value
bne 1
; do something if value==0
rts
1:
; do something if value!=0
rts
to:
lda value
beq 1
; do something if value!=0
rts
1:
; do something if value==0
rts
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,
groepaz mailto:groepaz_at_gmx.net
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:40 CET