From: Groepaz (groepaz_at_gmx.net)
Date: 2003-09-16 02:34:17
On Monday 15 September 2003 11:59, Ullrich von Bassewitz wrote: > 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. if you are looking from the viewpoint of the compiler programmer, yes ofcoz :o) not many disadvantages for anyone else though hehe :)) > 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:-) you are working with SDCC ?! *GGG* but seriously, considering the 6502 arch and the fact that making a c compiler for that is kindof challanging by itself, and suboptimal code is more expected than anything remotely efficient - cc65 does its job amazingly well already, atleast at places where the programmer is aware of cc65's behaviour :) however, from the democoder's point of view i have to say that every possible optimization needs to be done - and there are no excuses :=P I do still understand what your reasons are, and if i would be writing a compiler i would probably argue in a simelar way - thats why i started toying with opt65 and the pattern-based optimizing myself.... who carez how the compiler generated code looks like if some additional optimizer run can remove the suboptimal bits? :o) (i'm using a simelar pattern based thing for SDCC/z80 code too for that matter :=)) - i would also rate things like the labels-in-inline-asm problem more important than things i can circumvent more or less easily. > 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"? i'll do as soon as i improved opt65's output a bit so you can easily see what it does without having to manually compare (currently it only allows to switch between *massive* debug output and none at all...not really fun to read :)) still gotta debug the opt65 linecounter stuff too....cant believe the current numbers myself (checking against small testprograms says everything is correct though :/) > It is not > that I refuse to add additional peephole steps, I just want to have a > reason for doing so. maybe beeing the best 8bit compiler out there could be a reason.... i fear thats already the case though :=P (for that matter, did anyone ever see the compiler from western digital? damned f****r didnt even want to tell me a price nor give any other further info about its capabilities ...grrr, could be really interisting to see it in action - if only to see that it sux :))) hehe well, i'll try to make opt65 output some useful statistics aswell (ie ouput what optimization was applied how often etc) :) it would probably be interisting too what kindof possible optimizations could be added to cc65's optimizer that are NOT catched by opt65 anyway. > 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. yes, i see .... gotta do that :) making the compiler throw a warning if an __AX__ assignment is done anywhere in a macro except its start is probably kindof hard i guess? :) ok whatever, getting the latest snapshot and then do some more testing :o) gpz ---------------------------------------------------------------------- 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-16 02:39:10 CEST