From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2003-09-15 11:59:08
On Mon, Sep 15, 2003 at 01:05:01AM +0200, Groepaz wrote:
> a real true
> recursive macro expansion can probably do the job though :)
Your proposal will work with some efforts provided that macros are implemented
recursively - which they currently aren't.
> mmmh well... IMHO every optimization that does both decrease codesize and
> increase execution speed at the same time (as the immidiate lda/ora etc
> merging does) is worth the trouble. yes it probably does only save a few
> bytes, admittedly it even saves only a few bytes in code where i exploit
> certain special cases.
You will have to live with non perfect code if you're using a C compiler. And
if I add several hundred lines of C code to the compiler just to remove 5
bytes out of an 8K project written for a 6502 platform, the disadvantages are
far greater than the advantages.
> tjam, and i find it kinda hard to make any figures about how "worthy" a
> certain optimization is :=P
> it really depends on your testprogram what kind
> of possibly optimizations you will even spot - and even then the value of a
> removed instruction may raise and fall with that particular instruction
> beeing in the most inner loop of your program or not :)
cc65 is not a highly optimizing compiler and it will never be one (at least
not in the next few years). One reason is the implementation of the compiler
(generating explicit parse trees and intermediate code would be needed), the
second one is the strange architecture of the 6502. So you will have to live
with the fact that cc65 generated code will always be suboptimal. I know this
is hard, I'm myself working with (other) compilers where I have to avoid
looking at the generated code because this makes me very unhappy:-)
> some of the things that happen here may be really specific, i dont know....but
> actually i dont really think so - i am just copying some techniques that i am
> used to from assembler coding :) (and amazingly lot of the compiler generated
> code looks like what i would probably write when doing plain asm....after a
> peephole run with opt65 that is :=P)
So why not send me an example of this code snippet together with the generated
assembler code and a few numbers that say something like "26 occurences in a
626 line real world program, 513 bytes saved"? It is not that I refuse to add
additional peephole steps, I just want to have a reason for doing so.
> ouch! i wouldnt have expected that here really.... uhmz :=P the assignment
> somehow suggests that it doesnt touch Y at all (even if in reality it cant
> really avoid using it)
Which is the reason why there is no __Y__ and __X__:-) If you need explicit
loads of these registers, use inline assembly, so you are in control of all
the code.
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 : 2003-09-15 11:59:38 CEST