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