Mail Archives: pgcc/1998/03/14/03:37:53
On Fri, Mar 13, 1998 at 01:31:57PM +0200, Tuukka Toivonen wrote:
>
> If you want to have completely 80-bit floating points, you can have it.
> x86 FPU can store/load 10-byte floating points from/to memory.
> It will be slower, though. Blame C. It doesn't support 80-bitness.
Hmm, why doesn't it support it? It works pretty well last
time I checked...
> fsave/fxxx... don't remember these instruction names completely but they
> save/restore whole FPU state (well, they should. If you have _proofs_ about
> something else, please tell us.)
They store the exact fpu state, including the regs in 80 bits extended
format. (the fsave format is documented).
btw, it seems that the intel fpu's don't use any guard/sticky etc.. bits,
instead they rely on the 16 extra bits in the extended format, which
is plenty for implementing 64 bit (double) precision. (i'm not 100%
sure about the newer cpu's, though)
> >>Even better would be #pragma or something which would allow one to use
> >>IEEE-floats in some part of code and extra precision in another part.
> >
> >Nice idea, but works only with
> >*) good will without prototypes (K&R-C)
> >*) prototypes in ANSI-C
> >*) new name-mangling in C++
even worse, you can't use them in macros. c9x will change this, though
(with the _Pragma() syntax).
> I don't understand you. If user requests low precision, say `#pragma
> low-prec', compiler generates some opcodes
when does it generate such code:
>#include <stdio.h>
>
>#pragma low-proc
>
>double f(double) { ... }
???? on every procedure entry, of course (do you know about the cost
of fstenv?)
> (intel asm) And the same goes to high precision. Nothing else has to be
we are alrteady dead by then.
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg AT goof DOT com |e|
-=====/_/_//_/\_,_/ /_/\_\ --+
The choice of a GNU generation |
|
- Raw text -