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