Re[2]: [cc65] optimizer?

Date view Thread view Subject view

From: groepaz (
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,

To unsubscribe from the list send mail to with
the string "unsubscribe cc65" in the body(!) of the mail.

Date view Thread view Subject view

This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:40 CET