FPU Register Accuracy

Neither formally rejected nor actively developed
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

FPU Register Accuracy

Post by Robert »

Code: Select all

PROCEDURE  PiA () : REAL;
  BEGIN   RETURN  Math.Pi()  END  PiA;

PROCEDURE  PiB () : REAL;
  VAR
    x  :  REAL;
  BEGIN   x  :=  Math.Pi(); RETURN  x  END  PiB;

PROCEDURE  Pi*;
  BEGIN
    ASSERT (PiA() = PiB(), 40);
    ASSERT (PiB() = PiA(), 45)
  END  Pi;
Do you expect the Pi Command to TRAP, and if so with what number?
(Ok, the answer would have to be TRAP 45, or it would not be an interesting question.)
Louwy wrote:...make some simple expression like Math.Pi() == Math.Pi() get a FALSE result(like BB),
will confuse normal users. so most compiler select float64 as default(internal) precision.
I agree with Louwy that this behaviour is confusing, but I do not agree that this is a reason to choose 64-bit accuracy, or that choosing 64-bit accuracy is the solution to this issue.

One solution is to choose 64-bit accuracy consistently, another is to choose 80-bit accuracy consistently.

I propose that we alter the compiler so that when it spills the FPU registers to RAM it copies all 80 bits, not just 64 bits as now.

The advantages:
1 - Marginal extra accuracy in a few calculations.
2 - It avoids confusing results like the examples above
3 - It makes the floating point behaviour much easier to predict, and so greatly aids the analysis required to write correct algorithms by design.

To me point 3 is the important one.
Currently it is virtually impossible to even check if two different implementations of a function return the same results.

This proposal does not require any changes to the Language Report.

The disadvantages:
1 - A very small stack memory overhead - trivial!
2 - A small speed overhead - probably, pending measurements, too small to see.
3 - It will break existing code that relies on "Math.Pi() = Math.Pi()" returning FALSE.
I regard such code as pretty undesirable, but we would need to put a warning in the release notes.

Before taking this discussion much further does someone with compiler expertise have an opinion on the difficulty of implementing this proposal?

-- Edited to correct two spelling mistakes
Last edited by Robert on Sun Aug 28, 2016 11:11 am, edited 2 times in total.
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: FPU Register Accuracy

Post by Josef Templ »

I propose to stop all discussions until we have Release 1.7 out.
luowy
Posts: 234
Joined: Mon Oct 20, 2014 12:52 pm

Re: FPU Register Accuracy

Post by luowy »

Robert,
good proposal! we can discuss it after the release of 1.7.
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: FPU Register Accuracy

Post by Robert »

Josef Templ wrote:I propose to stop all discussions until we have Release 1.7 out.
I did not claim this was a bug. I do not claim it is high priority. I do not claim this is a pre-requisite for 1.7.

I do not think it is appropriate to try to censor (reasonable, polite, relevant, technical) discussion.

It is remarkable that you have managed to upset three different people in your last three posts - are you having a bad day?
cfbsoftware
Posts: 204
Joined: Wed Sep 18, 2013 10:06 pm
Contact:

Re: FPU Register Accuracy

Post by cfbsoftware »

I propose that we alter the compiler so that when it spills the FPU registers to RAM it copies all 80 bits, not just 64 bits as now.
I have my doubts that this is feasible. RAM is typically accessed in multiples of 8 / 16 / 32 / 64 bits. However, I'm a rank amateur when it comes to knowledge of the Intel architecture. I'd be interested to hear from others who might know more abut Intel to outline if / how this could be done.
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: FPU Register Accuracy

Post by Robert »

cfbsoftware wrote:I have my doubts that this is feasible
Section 8.1.2 of
Intel® 64 and IA-32 Architectures
Software Developer’s Manual
Volume 1:
Basic Architecture
The x87 FPU data registers (shown in Figure 8-1) consist of eight 80-bit registers.
Values are stored in these registers in the double extended-precision floating-point
format shown in Figure 4-3. When floating-point, integer, or packed BCD integer
values are loaded from memory into any of the x87 FPU data registers, the values are
automatically converted into double extended-precision floating-point format (if they
are not already in that format). When computation results are subsequently trans-
ferred back into memory from any of the x87 FPU registers, the results can be left in
the double extended-precision floating-point format or converted back into a shorter
floating-point format, an integer format, or the packed BCD integer format. (See
Section 8.2, “x87 FPU Data Types,” for a description of the data types operated on by
the x87 FPU.)
The FSAVE instruction description (volume 2)
The contents of the FPU register stack are stored in the 80 bytes immediately follow the operating environment image.
User avatar
DGDanforth
Posts: 1061
Joined: Tue Sep 17, 2013 1:16 am
Location: Palo Alto, California, USA
Contact:

Re: FPU Register Accuracy

Post by DGDanforth »

Robert wrote:
The contents of the FPU register stack are stored in the 80 bytes immediately follow the operating environment image.
bytes or bits?
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: FPU Register Accuracy

Post by Josef Templ »

Robert wrote:
Josef Templ wrote:I propose to stop all discussions until we have Release 1.7 out.
I did not claim this was a bug. I do not claim it is high priority. I do not claim this is a pre-requisite for 1.7.

I do not think it is appropriate to try to censor (reasonable, polite, relevant, technical) discussion.

It is remarkable that you have managed to upset three different people in your last three posts - are you having a bad day?
Did I censor anything? NO.
I proposed to delay the discussion until 1.7 is out.
The same as luowy proposed, by the way.

I am concerned about keeping focused on Release 1.7.
Any new discussion, as important and justified it may be,
delays the release of 1.7.

- Josef
cfbsoftware
Posts: 204
Joined: Wed Sep 18, 2013 10:06 pm
Contact:

Re: FPU Register Accuracy

Post by cfbsoftware »

DGDanforth wrote:
Robert wrote:
The contents of the FPU register stack are stored in the 80 bytes immediately follow the operating environment image.
bytes or bits?
It is bytes. There are 8 x 80 bit (960 bits) registers that are stored in memory as 80 x 80 bit bytes (960 bits).

I guess you would have to define a new data type (in C it is called a long double) to make use of these 10-byte data items and build support in the compiler to use them in expressions. You would then have to implement all the Maths functions to use these new data types etc. etc.
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: FPU Register Accuracy

Post by Josef Templ »

I was looking into the compiler and generated code for the
floating point register spilling strategy.
Using 80 bits for temporarily saved FPU registers is possible in principle but a
lot of work and a high potential for introducing bugs.
The advantage would be that ALL intermediate computations are then done
with full 80 bits precision. Only if a value is stored to REAL, a conversion happens.
A sequence such as x := Math.Pi(); ASSERT(x = Math.Pi()); would still trap
but in this case it is possible to understand why.

My understanding so far is that it would require a new structure form Real80 in the compiler
and an extended realSet:

Code: Select all

Real80 = 19;
realSet = {Real32, Real64, Real80};
Then all floating point operations must be extended for support of Real80 operands.
Such an operand will only occur with item mode Stk (relative to stack pointer).
Most FPU instructions support Real80 but not all. This needs to be checked carefully.

Alignment seems not to be a formal requirement but a stack size of 12 bytes for Real80,
i.e. 2 bytes padding, would preserve the existing stack alignment of 4.

- Josef
Post Reply