Interesting. Surprisingly, it decided to encode the multiplication and division as addition/subtraction loops, which is incredibly inefficient - multiplying e.g. 32,000 by 32,000 (ignoring the overflow ...) will take 1,024,000,000 iterations, so thousands of seconds on the speccy's humble 4Mhz Z80 (8 instructions, each taking at least 2 T-states ...)
Here is the multiplication loop (division is similar but in reverse, subtracting instead of adding).
mult_loop:
; Check if BC is zero
ld a, b
or c
jr z, mult_done
; Add HL to result
ex de, hl ; DE = multiplier, HL = result
add hl, de ; Add multiplier to result
ex de, hl ; DE = result, HL = multiplier
; Decrement counter
dec bc
jr mult_loop
No, but I would expect to do binary long multiplication and division, which have been used since before the intel 4004, and which it has surely seen in many Z80 and 6502 code bases fed into it.
oh interesting. One thing about the specy, is it's incredibly hard to hook in the eval technique (see middle/bottom of https://ghuntley.com/specs/ ) as deployment is manual/human. So I had to drive it all by hand and just accept it as afaik there's no testing framework. If this was another programming language I would have taken the approach of creating a `cargo bench` over the application and then looping _that_ back into the LLM to identify and resolve the performance issues. I've done it; it works well. Just not on the speccy :P
"Who cares if it's slow, at least the code is correct" - someone who never wrote 8-bit code in their life
It at least managed to regurgitate the fast multiply-by-10 algorithm, which of course exists in countless examples all over the web. But then, instead of maybe repeating that twice to multiply by 100, it produced absolutely insane code which - even at a glance - can't be correct unless the input happened to be zero:
; No decimal point, multiply by 100
ld b, h
ld c, l
add hl, hl ; * 2
add hl, hl ; * 4
add hl, hl ; * 8
add hl, hl ; * 16
add hl, hl ; * 32
add hl, hl ; * 64
add hl, bc ; * 65
add hl, hl ; * 130
ld b, h
ld c, l
srl b
rr c ; * 65
add hl, bc ; * 195
add hl, hl ; * 390
add hl, hl ; * 780
srl h
rr l ; * 390
add hl, hl ; * 780
srl h
rr l ; * 390
srl h
rr l ; * 195
srl h
rr l ; * 97.5
add hl, hl ; * 195
add hl, hl ; * 390
srl h
rr l ; * 195
add hl, hl ; * 390
srl h
rr l ; * 195
add hl, hl ; * 390
srl h
rr l ; * 195
add hl, hl ; * 390
srl h
rr l ; * 195
add hl, hl ; * 390
srl h
rr l ; * 195
add hl, hl ; * 390
srl h
rr l ; * 195
add hl, hl ; * 390
srl h
rr l ; * 195
jr done_convert
First a bunch of random left shifts and additions that overshoot the target, then an even more directionless attempt of correcting the result that seems stuck in a loop until it just gives up. Kind of reminds me of "PanicSort" (xkcd.com/1185)
And as you mentioned, it ignores overflow, which might be a real problem since even if it worked correctly, it could only handle amounts up to $655.35. A better solution would have used BCD arithmetic, which the Z80 provides some dedicated instructions for.
Here is the multiplication loop (division is similar but in reverse, subtracting instead of adding).