Page 2 of 2
Re: Optimization competition: An efficient calling conventio
Posted: Tue Jun 23, 2020 2:58 am
by johnwbyrd
For that reason, a 65816-only solution, that may or may not use the Z accumulator, is also of interest.
There is no "Z accumulator" in the 65C816. The 65C816's registers are
.A,
.B,
.X,
.Y,
DB,
DP,
PB,
PC and
SP.
D'oh! I was confusing the 65816 and the obscure 65CE02, which apparently had a Z register.
Re: Optimization competition: An efficient calling conventio
Posted: Tue Jun 23, 2020 3:13 am
by johnwbyrd
I certainly don't know if I'm misunderstanding or oversimplifying, but my attempt which does what you seem to describe would be:
Code: Select all
; add two 16-bit numbers in zp:
; x and y point to the addends, a points to the sum
; a and x are modified, y is preserved
If I count correctly (big if), 57 cycles between jmp main and brk, one cycle faster than BillG's fastest NMOS attempt.
At first glance, this code seems to me to behave as per the specifications -- let's see if any more cycles can be shaved off by others...
Re: Optimization competition: An efficient calling conventio
Posted: Tue Jun 23, 2020 3:48 am
by johnwbyrd
Code: Select all
org 0
P3 db 0 ; Pointer to third operand
SumLow db 0
Num1 dw 1234 ; First number
Num2 dw 5678 ; Second number
Num3 dw 0 ; Sum
;
; (P1) + (P2) -> (P3)
;
Add
sta P3
clc
lda 0,Y
adc 0,X
sta SumLow
lda 1,Y
adc 1,X
ldx P3 ; Point to sum
sta 1,X
lda SumLow
sta 0,X
rts
;
Start
ldy #Num1 ; Store pointer to first number
ldx #Num2 ; Store pointer to second number
lda #Num3 ; Store pointer to sum
jsr Add ; Add them
end Start
It's fascinating that juggling SumLow into a temporary zero page location, and handling the low byte last, seems to produce a faster result.
Re: Optimization competition: An efficient calling conventio
Posted: Tue Jun 23, 2020 4:06 am
by BigDumbDinosaur
For that reason, a 65816-only solution, that may or may not use the Z accumulator, is also of interest.
There is no "Z accumulator" in the 65C816. The 65C816's registers are
.A,
.B,
.X,
.Y,
DB,
DP,
PB,
PC and
SP.
D'oh! I was confusing the 65816 and the obscure 65CE02, which apparently had a Z register.
The Z register in the 65CE02 has no analog in the 65C816.
Re: Optimization competition: An efficient calling conventio
Posted: Thu Jul 16, 2020 10:24 am
by johnwbyrd
Any more suggestions? The existing entries seem optimal superficially, but I still hold out hope.
Lest that any of you think that this is purely an academic competition, let me quietly tease some screenshots of my current work.
Note the line number 7773, which is my attempt at a l33t spelling of LLVM.
Re: Optimization competition: An efficient calling conventio
Posted: Thu Jul 16, 2020 2:38 pm
by BillG
Are you working on a virtual machine or compiler backend infrastructure?
Re: Optimization competition: An efficient calling conventio
Posted: Thu Jul 16, 2020 8:09 pm
by johnwbyrd
Are you working on a virtual machine or compiler backend infrastructure?
Yes to both. The first is a by-product of the second. Code optimized for speed would be emitted in ordinary 6502 assembly. But code optimized for size would be emitted in an LLVM IR-like bytecode, to be parsed by a runtime language interpreter, and hence this calling convention would apply.
Re: Optimization competition: An efficient calling conventio
Posted: Mon Aug 10, 2020 7:27 pm
by johnwbyrd
Going once...
Re: Optimization competition: An efficient calling conventio
Posted: Fri Aug 14, 2020 7:57 pm
by johnwbyrd
Going twice...
Re: Optimization competition: An efficient calling conventio
Posted: Sun Sep 13, 2020 8:33 pm
by johnwbyrd
The optimization competition is now over!
I award
Top Honors to
BillG for embracing the problem so completely, and for eventually finding the fastest solution.
However, an important
Inspirational Award goes to
barrym95838, for finding the creative breakthrough that enabled the fastest solution to exist.
Congratulations everyone, and thank you so much for playing!
Re: Optimization competition: An efficient calling conventio
Posted: Tue Sep 15, 2020 1:41 pm
by BillG
I would like to thank the Academy...
Actually, I thank barrym95838 as well for the competitive spirit and out-of-the-box thinking which made the final result possible.