Double literals, M*/ - #434
Conversation
Internal 48-bit precision
e.g.: 50000. , -2147483647. , etc.
|
Hi! |
No problem. I update the related issue with my new doubt about use of doubles for fixed point maths. The single-precision divisor of 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. |
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_NUMBERis 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.