With such optimizations one has to wonder why are they turned off by default...

Heh, thanks. It will probably be good for 6502 asm optimization phase, though.

Yep:

OK, what I came up with is "storing" equality evaluation results in CPU regs. So when doing simple comparisons, instead of allocating new SP reg and using it as comparison destination, I'll set proper CPU flag as current Woling reg. I.e.

Insteade of this:

alloc SP, #1 // new reg
evaleq SP(0 ...

I'm thinking about something like this:

Instead of:

; 14: evalless SP(2)<__wolin_reg2>[bool] = 53280[ubyte] , #255[ubyte]

lda #1 ; mniejsze
sta 2,x
lda 53280
cmp #255
bcc :+
lda #0 ; jednak wieksze
sta 2,x
:
; 15: beq SP(0)<__wolin_reg2>[bool] = #1[bool] , __wolin_lab_loop_start_1<label ...

Hi HERE, Volker. Hope you find this at least a bit interesting:

viewtopic.php?f=2&t=5622&p=76787#p76787

Some compiler fun. I've compiled the same code with Wolin, cc65 and vbcc:

Wolin:


do {
border++
} while ( border < 255)


C (generated by Wolin C frontend :D)


do {
(*(unsigned char *)(53280))++;
} while ( (*(unsigned char *)(53280)) < 255);


And the results:

Wolin:

__wolin_lab_loop ...

OK, so it's actually not that simple - mixing Wolin code with C code that uses some special C ZP locations will require a dedicated linker config, special Wolin startup code, and losing some Wolin stack space for C registers, but it's absolutely doable. Maybe later. Meanwhile you can get the length ...

Anyone fluent in cc65? I was thinking about interfacing with its libs, since I'm using cl65 and ca65 anyway. So as we know the call convention is:

i = baz(int i, char c)

will result in:

lda _i
ldx _i+1
jsr pushax
lda _c
jst pusha

jsr _baz

sta _i
stx _i+1

While:

.proc pushax

pha ; (3 ...

A small step ahead - I was able to mark registers used to dereference a pointer unoptimizable. Look at below code:


setup HEADER
label __wolin_pl_qus_wolin_plot = 65520
label __wolin_pl_qus_wolin_chrout = 65490
setup SPF = 251[ubyte] , 40959[uword]
setup SP = 114[ubyte]
setup HEAP = 176[ubyte ...

Heh, after playing with long register chains for a few days I discovered that nothing beats my "naive" replacement by pairs. But at least I've learned some logic in reference flow... Anyway - here you can see source and optimized diagram of the very same print function.

With improved flow diagram now the optimizer is able to find long chains of optimizable registers (compare with attached diagram):

#0 -> __wolin_reg2 -> pl.qus.wolin.print..i
#0 -> __wolin_reg11 -> __wolin_reg9
__wolin_reg5 -> __wolin_reg4 -> pl.qus.wolin.print..char -> __wolin_reg10 -> __wolin ...

And here's a neat chart I was able to generate for print function with the new optimizer.

Small update - reworked optimizer to use real data flow trees. Up until now, the optimization was rather... erm... guerilla-style... Now I will be able to copy pointer received in function arguments to ZP stack and keep them there thanks to smarter logic in eliminating tree nodes.

Is it an assembler directive? Nope... Let me look that up...

Ha! That was it!