From: groepaz (groepaz_at_gmx.net)
Date: 2001-06-24 21:32:30
Hello Ullrich,
UvB> I found the idea behind this peephole optimizer interesting and I've done some
UvB> tests with Daniels sources. However, any of my source files went through this
UvB> program unchanged.
like i said... this optimization stage is usually not needed for
hand-written code.... i just use that to make sure that i dont recycle
totally stupid old code of mine that should better be rewritten from
scratch ;=))
UvB> This sounds nice, but improvements are probably limited. I haven't tried
UvB> illegal opcodes for now, but my experiences with 65C02 code are somewhat
UvB> disapointing. Improvements (both speed and size) are somewhere in the range of
UvB> one percent or lower and portability is a problem. I would assume that the
UvB> advantages of using illegal opcodes (which are often not very useful) are even
UvB> lower.
yes, like i said, using illegals only makes sence in some rare
cases... the most common one i think is
replace sth like
lda something
tax
by
lax something
i have rarely seen any other illegals used except LAX.... well, except
for copy-protection (making code hard to read in disassemblers)...
UvB> [...]
UvB> It would be nice to see how these proposed changes affect existing code. As
UvB> said above, I've tried Daniels code and it had no effect on my sources
UvB> whatsoever.
UvB> Some of your proposed additions are also dangerous, since they may
UvB> defeat knowledge, the programmer has put into the code (maybe in this special
UvB> section of code, VALUE is zero more often than not zero?), so they should be
UvB> switcheable.
well, ofcoz optimization should be somehow control-able on sourcecode
level..... so the programmer can exclude certain routines of which he
knows they are already optimal.... other than that, all those
optimization would never break the code (result in non-working code)
but instead _maybe_ make it perform worse than before.... that can
easily be determined through profiling (aka testing ;D) though, so i
guess one can live with that.
UvB> If you really get something like this running I would be interested in some
UvB> results. There is one file in the cc65 C library (the free() function in
UvB> free.s) where I know that a few instructions can be removed by clever
UvB> rewriting/rearranging. I've avoided to do that, because the module is quite
UvB> complex and the changes would obfuscate the code even more. If your optimizer
UvB> manages to actually fix these locations, I would assume it's pretty good.
well... uhm.... _I_ would need the optimizer for use on large unrolled
loops only (which are in itself relativly trivial) so i'd use
different properties than needed for optimizing relativly small, but
rather complex routines...... good to know theres a potential routine
for testing though ;=)
UvB> Another idea would be to let such an optimizer work on binary code. There are
UvB> some additional problems (optimizations of hardware accesses are dangerous,
UvB> and code addresses loaded as 8 bit values into registers must be detected and
UvB> handled), but other problems (like handling complex expressions) would vanish
UvB> completely.
uhm well... would there be a real difference in optimizing binary vs
assembler code ? (except with assembler code you get much more
information about the code structure, dont have to guess code adresses
that are loaded as 8bit lo/hi pairs etc)
--
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