From: groepaz (groepaz_at_gmx.net)
Date: 2001-06-24 22:44:29
Hello Ullrich, UvB> What about something like UvB> acia = $DC00 UvB> data = $00 UvB> lda acia+data ; dummy read UvB> lda #$00 UvB> ... UvB> The first load is a dummy read, but it is needed in some way to initialize UvB> hardware, acknowledge an interrupt or whatever. An optimizer would have a UvB> really hard time to figure this out. yeah, sure.... and it _HAS_ a hard time to figure it out, even in all c-compilers i have seen ;=) i would expect the programmer to write: acia = $DC00 data = $00 .opt off lda acia+data ; dummy read .opt on lda #$00 ... or sth simelar ... same as using the 'volatile' keyword in C (i think i have actually seen some c-compilers which implemented the volatile keyword like this) >> 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) UvB> You don't have to mess with expressions when using binary code. It is easy to UvB> detect that things like UvB> foo = $02 UvB> bar = $02 UvB> lda foo UvB> ... UvB> lda bar UvB> are accessing the same location. Or what about UvB> foo = $02 UvB> bar = $01 UvB> lda foo UvB> ... UvB> lda bar*2 UvB> Having an optimizer working on source code, you need to mimic the complete UvB> symbol handling of the assembler, including local symbols and so on. Or UvB> something like UvB> .import foo, bar UvB> jmp foo UvB> ... UvB> jmp bar UvB> foo and bar may in fact resolve to the same address which would allow some UvB> speed and/or size optimizations, but an optimizer working on source code would UvB> not have the necessary knowledge, while this would be easy to detect when UvB> working with binary code. yeah you are right ofcoz, and to be honest... i havent even thought to handle things like this (i wouldnt need them personally) .... BUT i guess it would be the best idea to work on "precompiled" object files.... like a binary plus additional symbol-infos and alike (you really need that to handle those very common 8bit lo/hibyte adress loads and also certain other stuff). working on plain binaries without additional infos would require too much stages to gather all the sequence-points etc pp i think..... we had to 'guess' a lot of information that the sourcecode could provide. ... what about that .a64 (right extension?) relocatable stuff your linker can spit out? maybe thats a good starting point aswell? (but i guess that would already leave out all info about internal references/symbols etc?!) i really love the idea about not having to mess with expressions (would make the optimizer hell easier to write and debug) but it would definetly require more than a plain binary as input to do anything useful in the optimizer ,=) -- 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