From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2001-06-24 21:08:06
Hi!
On Sun, Jun 24, 2001 at 08:20:11PM +0200, groepaz wrote:
> 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.
I found the idea behind this peephole optimizer interesting and I've done some
tests with Daniels sources. However, any of my source files went through this
program unchanged.
> - 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)
This sounds nice, but improvements are probably limited. I haven't tried
illegal opcodes for now, but my experiences with 65C02 code are somewhat
disapointing. Improvements (both speed and size) are somewhere in the range of
one percent or lower and portability is a problem. I would assume that the
advantages of using illegal opcodes (which are often not very useful) are even
lower.
[...]
It would be nice to see how these proposed changes affect existing code. As
said above, I've tried Daniels code and it had no effect on my sources
whatsoever. Some of your proposed additions are also dangerous, since they may
defeat knowledge, the programmer has put into the code (maybe in this special
section of code, VALUE is zero more often than not zero?), so they should be
switcheable.
If you really get something like this running I would be interested in some
results. There is one file in the cc65 C library (the free() function in
free.s) where I know that a few instructions can be removed by clever
rewriting/rearranging. I've avoided to do that, because the module is quite
complex and the changes would obfuscate the code even more. If your optimizer
manages to actually fix these locations, I would assume it's pretty good.
Another idea would be to let such an optimizer work on binary code. There are
some additional problems (optimizations of hardware accesses are dangerous,
and code addresses loaded as 8 bit values into registers must be detected and
handled), but other problems (like handling complex expressions) would vanish
completely.
Regards
Uz
--
Ullrich von Bassewitz uz_at_musoftware.de
----------------------------------------------------------------------
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