4 ms·
6502 was from a different era. Not really designed to be a great compiler target. Most other old 8-bitters have comparable issues. One nitpick, decrement 16 b
by vardump 8y ago
6502 was from a different era. Not really designed to be a great compiler target.
Most other old 8-bitters have comparable issues.
One nitpick, decrement 16 bit value by one. From the article:
4 ae a0 aa ldx a+0
2 ca dex
4 8e a0 aa stx a+0
2 e0 ff cpx #ff
2 d0 03 bne label
6 ce a1 aa dec a+1
.label
(20 cycles maximum, 14 minimum, 14 bytes.)
It'd be better to do something like this, 11 bytes, (max 24/min 12 cycles, assuming article cycle counts are correct):
4 ae a0 aa ldx a+0
2 d0 03 bne label
6 ce a1 aa dec a+1
.label
6 ce a0 aa dec a+0
4 more cycles for the worst case, but that occurs only every 256th time, in which time the best case has already saved cumulative 510 cycles compared to the article version.
On 6502 one should really keep the variables on the zero page. Same operation would take just 8 bytes for that case.
- vardump 8y ago> 11 bytes, (max 24/min 12 cycles, assuming article cycle counts are correct): Oops. Other numbers are correct, but of course the worst case takes only 18 cycles, not 24.
- jcmeyrignac 8y agoAnd you can extend the decrement for 32 bits as follows: lda a+0 bne .3 lda a+1 bne .2 lda a+2 bne .1 dec a+3 .1: dec a+2 .2: dec a+1 .3: dec a+0
- vardump 8y agoPretty logical extension. It still takes only 12 cycles if a+0 != 0. 24 cycles if also a+1 != 0 (=every 256th round), etc. The worst case time is when whole 32-bit counter is zero, 12 clk * 3 + 6 clk = 42 clk. (Disclaimer: clock counts assume original snippet counts were correct).