Where is Atalan's optimization features...

[Michel Iwaniec]

Hi,

According to the webpage, Atalan should perform extensive
optimizations for producing efficient 6502 code.

But why then does this function:

UploadEditCursorCHR:proc =
addr:0..65535
addr = EDIT_CURSOR_TILEID*16
PPU_DATA_ADR = hi addr
PPU_DATA_ADR = lo addr
for i:0..7
PPU_DATA = 0
for i:0..7
PPU_DATA = EditCursorCHR(i)

Result in this (obviously suboptimal) assembly code?:

UploadEditCursorCHR .proc
;### editmap.atl(31) addr = EDIT_CURSOR_TILEID*16
lda #240
sta UploadEditCursorCHR__addr+0
lda #31
sta UploadEditCursorCHR__addr+1
;### editmap.atl(32) PPU_DATA_ADR = hi addr
sta PPU_DATA_ADR
;### editmap.atl(33) PPU_DATA_ADR = lo addr
lda #240
sta PPU_DATA_ADR
;### editmap.atl(34) for i:0..7
lda #0
sta _s1__i
_lbl6:
;### editmap.atl(35) PPU_DATA = 0
lda #0
sta PPU_DATA
inc _s1__i
lda _s1__i
cmp #8
jne _lbl6
;### editmap.atl(36) for i:0..7
ldx #0
_lbl8:
;### editmap.atl(37) PPU_DATA = EditCursorCHR(i)
lda EditCursorCHR,x
sta PPU_DATA
inx
cpx #8
jne _lbl8
rts
.endp



The first surprising thing is that the stores to the 'addr' variable
aren't optimized away, even though it is only an intermediate
variable.

But even more surprisingly, how come writing a constant zero byte to
PPU_DATA can result in a much less efficient loop than writing the
contents of an array? That is really surprising.

Setting the optimization level does not seem to have any effect on
this behavior.