Open burnsauce opened 2 years ago
Hi! Just wanted to say, sorry I haven't had the time to review yet! It's been a busy start of the year, and I haven't had much spare time or brain cycles. I will get to it when I can give it the attention it deserves.
Hi! Just wanted to say, sorry I haven't had the time to review yet! It's been a busy start of the year, and I haven't had much spare time or brain cycles. I will get to it when I can give it the attention it deserves.
No problem. I update the related issue with my new doubt about use of doubles for fixed point maths. The single-precision divisor of M*/
seems to be a severely limiting factor.
As fixed-point was going to be my primary use of doubles, I now doubt the utility of this patch.
I'll keep thinking about it and update this patch to my latest, but there's no imperative to merge this.
OK, I will keep it open for further pondering.
Did you think further about this topic? I have been undecided, if I think this functionality would be a valuable addition or not.
To get some bearings, I did a quick investigation on how other C64 Forths do. It seems double literals are near-universally supported, while M*/ is less common, but implemented by some high-quality Forths (e.g. Blazin` Forth).
Personally I do not care so much about either, as I prefer to do any serious number crunching on the PC, and then lift the results to C64. But I think it would be fair to argue that double literals is something one could expect from a 16-bit Forth. As such, I am open for this idea, if anyone wants it added.
This patch does 2 things:
M*/
Discussion of this feature at #433
M*/
is required to achieve the double literal because base conversion must use doubles as input to multiplication, and this is the only forth operator to do this. Internally it's a 32*32=64 bit multiplier with a 48/16=32 bit divider.There is no performance impact to the math.asm changes:
ud/mod
's changes come out in the wash when integrated withut/mod
, an unlisted function that accepts a triple (48-bit) dividend and a 16-bit divisor. It is effectively the exact same routine as before, as the cascading divison required a leading 0 to divide the top word anyways.READ_NUMBER
is slower, owing to the 32-bit multiplication, but now able to return a double.The code is obviously larger.
This commit updates the changelog and has cleared
include test
.