From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2001-06-24 22:04:55
Hi!
On Sun, Jun 24, 2001 at 09:32:30PM +0200, groepaz wrote:
> well, ofcoz optimization should be somehow control-able on sourcecode
> level..... so the programmer can exclude certain routines of which he
> knows they are already optimal.... other than that, all those
> optimization would never break the code (result in non-working code)
> but instead _maybe_ make it perform worse than before.... that can
> easily be determined through profiling (aka testing ;D) though, so i
> guess one can live with that.
What about something like
acia = $DC00
data = $00
lda acia+data ; dummy read
lda #$00
...
The first load is a dummy read, but it is needed in some way to initialize
hardware, acknowledge an interrupt or whatever. An optimizer would have a
really hard time to figure this out.
> 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)
You don't have to mess with expressions when using binary code. It is easy to
detect that things like
foo = $02
bar = $02
lda foo
...
lda bar
are accessing the same location. Or what about
foo = $02
bar = $01
lda foo
...
lda bar*2
Having an optimizer working on source code, you need to mimic the complete
symbol handling of the assembler, including local symbols and so on. Or
something like
.import foo, bar
jmp foo
...
jmp bar
foo and bar may in fact resolve to the same address which would allow some
speed and/or size optimizations, but an optimizer working on source code would
not have the necessary knowledge, while this would be easy to detect when
working with binary 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 : 2001-12-14 22:05:40 CET