Page 12 of 12
Re: Wolin - a minimal Kotlin-like language compiler for 65xx
Posted: Mon Jun 29, 2020 10:34 am
by qus
Yep:
Code: Select all
__wolin_lab_loop_start_1:
; 12: add 53280[ubyte] = 53280[ubyte] , #1[ubyte]
inc 53280
; 13: evalless CPU.NC[bool] = 53280[ubyte] , #255[ubyte]
lda 53280
cmp #255
; 14: bift CPU.NC[bool] , __wolin_lab_loop_start_1<while_start>[uword]
bcc __wolin_lab_loop_start_1
Re: Wolin - a minimal Kotlin-like language compiler for 65xx
Posted: Mon Jun 29, 2020 2:07 pm
by BillG
; 13: evalless CPU.NC[bool] = 53280[ubyte] , #255[ubyte]
If X or Y is available, you can compare a byte with 255 (or 1) with something like:
Re: Wolin - a minimal Kotlin-like language compiler for 65xx
Posted: Mon Jun 29, 2020 3:19 pm
by qus
Heh, thanks. It will probably be good for 6502 asm optimization phase, though.
Re: Wolin - a minimal Kotlin-like language compiler for 65xx
Posted: Tue Jun 30, 2020 2:40 am
by dmsc
Hi!
Some compiler fun. I've compiled the same code with Wolin, cc65 and vbcc:
Wolin:
C (generated by Wolin C frontend
)
Code: Select all
do {
(*(unsigned char *)(53280))++;
} while ( (*(unsigned char *)(53280)) < 255);
cc65:
Code: Select all
L0015: ldx #$00
lda $D020
inc $D020
ldx #$00
lda $D020
cmp #$FF
jsr boolult
jne L0015
I wonder if I can make my bool operations any smarter and use V/C/N flags somehow (and obviously win brevity competition)... But I do like the way it works now - by storing the final bool result of an operation in SP reg. MAYBE instead of storing it at SP,x I just pretend I "stored" it at 6502 V/C/N?
You compiled the CC65 example without optimizations, here I get (using "cc65 -Osir test.c":
Code: Select all
L000B: inc $D020
lda $D020
cmp #$FF
bcc L000B
Have Fun!
Re: Wolin - a minimal Kotlin-like language compiler for 65xx
Posted: Tue Jun 30, 2020 6:37 am
by qus
With such optimizations one has to wonder why are they turned off by default...
Re: Wolin - a minimal Kotlin-like language compiler for 65xx
Posted: Tue Jun 30, 2020 10:36 am
by Chromatix
Most C compilers have no optimisation by default, so cc65 is not unusual in that respect. Unoptimised compilation results in code that does fewer unexpected things when single-stepping in a debugger.