DOS ain't dead

> > What are all differences between W32 and F32 versions [NDN]
>
> The F32 (FreePascal) version for example has Big Calculator which uses the
> Int64/QWord types that are missing in Virtual Pascal.

I doubt you need my help. I don't actually know the mathematical theory behind these. Still, I'll list a few things here for my own amusement.

* QMATH0.ZIP (signed 64-bit arithmetic in (16- or 32-bit) assembly for DOS)
* BIGNUM.C (from Micro-C's MC323EXA.ZIP) for 64-bit calculator in 16-bit DOS
* 32math64.txt (20 kb text, excerpted from AMD optimization manual, uses 32-bit regs for 64-bit math)

I blindly assume this has been done to death thousands of times (literally). Somebody somewhere probably has oodles of bigint routines in various HLLs languages, optimized for various cpus. Check news://comp.lang.misc for potential contributors.

Also, I do wonder how such things are verified (especially on slow/old hardware). Do they brute force it? Prove it via mathematics? Or just (slowly, partially) run a fraction daily until they double-check all their ranges output valid data? How would somebody verify correctness on an old 286/386/486?

I'm sure it's been done many times over. I just don't know the details. Probably lots of papers, books, source code. (FPU? BCD? SIMD?)

> I blindly assume this has been done to death thousands of times
> (literally). Somebody somewhere probably has oodles of bigint routines in
> various HLLs languages, optimized for various cpus. Check
> news://comp.lang.misc for potential contributors.
>
> Also, I do wonder how such things are verified (especially on slow/old
> hardware). Do they brute force it? Prove it via mathematics? Or just
> (slowly, partially) run a fraction daily until they double-check all their
> ranges output valid data? How would somebody verify correctness on an old
> 286/386/486?
>
> I'm sure it's been done many times over. I just don't know the details.
> Probably lots of papers, books, source code. (FPU? BCD? SIMD?)

You don't need to verify the entire 64-bit or even 32-bit range, although the latter is already doable on a regular PC for many simple algorithms.

First, you can reduce your data format to fewer bits. This makes it more brute forçable(?). You don't really need all 52 bits of a double mantissa and 11 bits of exponent to simulate floating point behavior qualitatively. You can have all the same behaviors in IEEE half precision format, in 10+5=15 bits. Likewise with ints: use 8-bit ones to exhaustively validate your algorithm, no need to try doing it with, say, 32-bit ones.

Second, you are mostly interested in what generally happens in large subranges and at their much smaller boundaries (say, in one subrange everything's OK, while in the other you have an overflow or NaN, so you're interested in these two subranges and the boundary between them). A lot of bugs are typically at the boundaries.

Third, you may generate various bit patterns instead of trying to cover a large (sub)range. Say, a single bit set to 1, while zeroes are in all others. Move that one bit across all bit positions. Repeat the same with bits inverted. Repeat the same but with 2 bits set to 1. Ditto 3 bits. You can also replace single bits set to 1 with groups of a few 1's.

Fourth, to get away from the regularity of your test data patterns (and possibly some systematically missed cases), generate random inputs as well.

Fifth, yes, any degree of parallelization is good: multiple CPU cores, SIMD instructions, etc.

I forgot to mention MPCALC (see FPC announcement for 7.4):

> Units to perform calculations with real numbers and selectable precision
> from 10 to 1000 digits. The most usual operations and functions are
> implemented: arithmetic and bitwise operators, comparison functions,
> exponential, natural and base 10 logarithm, trigonometric and hyperbolic
> functions direct and inverse, factorial and other.

> I forgot to mention MPCALC (see FPC
> announcement
> for 7.4):


last week a new one popped up https://forum.lazarus.freepascal.org/index.php/topic,48925.0.html