Re: i387 rounding mode and long double support

[Matthias Drochner <M.Drochner%fz-juelich.de@localhost>]

joerg%britannica.bec.de@localhost said:
> i386 and amd64 force the FPU into IEEE double precision
> rounding mode
> [...]
> I do question the use for AMD64 though, because
> normal float and double operations are done using the SSE units

I had thought about that too. If we can be sure that the compiler
really does no "double" arithmetics in the x87 (except transcendent
functions etc where we don't have exact promises about accuracy
anyway), this would be feasible.

You might have a look at the release notes of gcc-4.5 - the section
about -std=c99 and floating point performance. The gcc developers
have apparently realized that an x87 in long mode doesn't give
standards conform rounding. Their workaround is to issue a
store+load to a "double" memory variable after each operation.
This kills performance, but not for us, with x87 in "double" mode.
(needs some definition in gcc's config, didn't commit it yet)

> The alternative would be to
> either accept that long double doesn't actually have the advertised mantissa
> length

FreeBSD deals with that, see the TARGET_96_ROUND_53_LONG_DOUBLE
definition in gcc.

Anyway, this stays a tradeoff between "double" speed and accuracy
on one side and "long double" mantissa length on the other.
Given the real-world use of "double" vs "long double", this needs
more consideration than an "ease porting of a library".

best regards
Matthias



------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------