Re: Parsing timestamps?

mhx@iae.nl (mhx) writes:

What is there not to like with the FPU? It provides 80 bits, which
is in itself a useful additional format, and should never have problems
with single and double-precision edge cases.

If you want to do double precision, using the 387 stack has the
double-rounding problem
<https://en.wikipedia.org/wiki/Rounding#Double_rounding>.  Even if you
limit the mantissa to 53 bits, you still get double rounding when you
deal with numbers that are denormal numbers in binary64
representation.  Java wanted to give the same results, bit for bit, on
all hardware, and ran afoul of this until they could switch to SSE2.

The only problem is that some languages and companies find it necessary
to boycott FPU use.

The rest of the industry has standardized on binary64 and binary32,
and they prefer bit-equivalent results for ease of testing.  So as
soon as SSE2 gave that to them, they flocked to SSE2.

Another nudge towards binary64 (and binary32) is autovectorization.
You don't want to get different results depending on whether the
compiler manages to auto-vectorize a program (and use SSE2 parallel
(rather than scalar) instructions, AVX, or AVX-512) or not.  So you
also use SSE2 when it fails to auto-vectorize.

OTOH, e.g., on gcc you can ask for -mfpmath=386, for -mfpmath=sse or
for -mfpmath=both; or if you define a variable as "long double", it
will store an 80-bit FP value, and computations involving this
variable will be done on the 387.

- anton
--
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
EuroForth 2023 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/