www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - 80 bit floating point emulator

reply Walter Bright <newshound2 digitalmars.com> writes:
It turns out we can use one for the D compiler, to support cross compilation
for 
machines that don't have 80 bits.

It doesn't have to emulate all the instructions, just:

neg
add
sub
mul
div
cmp
tst

conversions to/from double,float,int,long

The 128 bit integer emulator Iain and I worked on is a good starting point to
use:

   https://github.com/dlang/druntime/blob/master/src/core/int128.d

As well as the 64 bit floating point emulator from DMC:

   https://github.com/DigitalMars/dmc/blob/master/src/CORE32/DOUBLE.ASM

80 bits works a bit different from 64 bits, in that the hidden bit is explicit, 
and subnormals are present. But most of it will be just like double.asm, just 
with more bits. It should be easier being written in D, too, rather than
assembler.

This is a worthy challenge for anyone wanting a strong item on their resume.
Any 
takers?

P.S. It doesn't have to be fast. It just has to be written in portable D and 
produce the same answers as the x87.
Feb 05 2022
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 6 February 2022 at 04:30:25 UTC, Walter Bright wrote:

 P.S. It doesn't have to be fast. It just has to be written in 
 portable D and produce the same answers as the x87.


Is this paid work? Doesn’t 8087 use CORDIC for mul/div?
Feb 05 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 6 February 2022 at 06:21:22 UTC, Ola Fosheim Grøstad 
wrote:

 On Sunday, 6 February 2022 at 04:30:25 UTC, Walter Bright wrote:

 P.S. It doesn't have to be fast. It just has to be written in 
 portable D and produce the same answers as the x87.


 Is this paid work? Doesn’t 8087 use CORDIC for mul/div?


Hm, maybe not. This source:

http://www.righto.com/2020/05/die-analysis-of-8087-math-coprocessors.html

says it used only shifts and subtracts for division with 67/68 
bits for the significand/mantissa.

Using CORDIC for "approximate" division might be more recent.
Feb 06 2022
prev sibling parent reply Temtaime <temtaime gmail.com> writes:
On Sunday, 6 February 2022 at 04:30:25 UTC, Walter Bright wrote:

 It turns out we can use one for the D compiler, to support 
 cross compilation for machines that don't have 80 bits.

 [...]


Maybe just drop 80 bits floats support? They should die with x87. 
Just move to SSE/AVX.
Feb 06 2022
parent reply max haughton <maxhaton gmail.com> writes:
On Sunday, 6 February 2022 at 11:03:38 UTC, Temtaime wrote:

 On Sunday, 6 February 2022 at 04:30:25 UTC, Walter Bright wrote:

 It turns out we can use one for the D compiler, to support 
 cross compilation for machines that don't have 80 bits.

 [...]


 Maybe just drop 80 bits floats support? They should die with 
 x87. Just move to SSE/AVX.


We already have moved on, technically. There are still some 
places using real in Phobos IIRC that should be violently culled 
because it destroys performance, but having the precision 
available isn't so bad.
Feb 06 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 6 February 2022 at 11:27:28 UTC, max haughton wrote:

 We already have moved on, technically. There are still some 
 places using real in Phobos IIRC that should be violently 
 culled because it destroys performance, but having the 
 precision available isn't so bad.


The only thing needed is to load and save 80bits from 64bit and 
128bit. I wonder who would want 80 bits? If they need more than 
64bits then they most likely want 128 bits or 256 bits.
Feb 06 2022
parent reply max haughton <maxhaton gmail.com> writes:
On Sunday, 6 February 2022 at 12:02:56 UTC, Ola Fosheim Grøstad 
wrote:

 On Sunday, 6 February 2022 at 11:27:28 UTC, max haughton wrote:

 We already have moved on, technically. There are still some 
 places using real in Phobos IIRC that should be violently 
 culled because it destroys performance, but having the 
 precision available isn't so bad.


 The only thing needed is to load and save 80bits from 64bit and 
 128bit. I wonder who would want 80 bits? If they need more than 
 64bits then they most likely want 128 bits or 256 bits.


80 bits actually exists in the hardware.

real isn't defined to be 80bits, it's just the widest float 
available in the hardware.

If we ever have a fp128 risc-v machine real could be 128bit there.
Feb 06 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 6 February 2022 at 12:20:01 UTC, max haughton wrote:

 80 bits actually exists in the hardware.


Yes, IIRC it is partial hardware partial microcode in later 
generations. Intel has considered it to be legacy instructions 
for 20 years…


 real isn't defined to be 80bits, it's just the widest float 
 available in the hardware.


Yes, which is why I wonder why people would want 80 bits in 
software. If you do it in software it probably is better to use a 
struct with independent fields rather than bit-packing.

The demand for more than 64 bits is low, I think people that want 
this will use a well tested and maintained multi-precision 
library.
Feb 06 2022
parent reply kinke <noone nowhere.com> writes:
On Sunday, 6 February 2022 at 13:10:46 UTC, Ola Fosheim Grøstad 
wrote:

 Yes, which is why I wonder why people would want 80 bits in 
 software.


This is for the DMD frontend, e.g., if DMD is built as a native 
Apple AArch64 program (with 64-bit native `real` - as an 
Apple-divergence; all other AArch64 targets use 128-bit quadruple 
precision AFAIK), but limited to cross-compiling to x86 (as only 
arch supported by the DMD backend). It still has to parse and 
perform CTFE computations in 80-bit extended precision to yield 
the same results a native x86-DMD would.
Feb 06 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 6 February 2022 at 13:23:13 UTC, kinke wrote:

 x86 (as only arch supported by the DMD backend). It still has 
 to parse and perform CTFE computations in 80-bit extended 
 precision to yield the same results a native x86-DMD would.


But WHY would you compute compile time in only 80-bit?
Feb 06 2022
parent reply kinke <noone nowhere.com> writes:
On Sunday, 6 February 2022 at 13:29:23 UTC, Ola Fosheim Grøstad 
wrote:

 But WHY would you compute compile time in only 80-bit?


For `log(0.1L)` at CTFE, the compiler must when targeting a 
platform with x87 real.

 From https://dlang.org/spec/float.html#fp_const_folding:

 1. Regardless of the type of the operands, floating-point 
 constant folding is done in real or greater precision. It is 
 always done following IEEE-754 rules and round-to-nearest is 
 used.
Feb 06 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 6 February 2022 at 13:36:37 UTC, kinke wrote:

 On Sunday, 6 February 2022 at 13:29:23 UTC, Ola Fosheim Grøstad 
 wrote:

 But WHY would you compute compile time in only 80-bit?


 For `log(0.1L)` at CTFE, the compiler must when targeting a 
 platform with x87 real.

 From https://dlang.org/spec/float.html#fp_const_folding:

 1. Regardless of the type of the operands, floating-point 
 constant folding is done in real or greater precision. It is 
 always done following IEEE-754 rules and round-to-nearest is 
 used.




It says "or greater precision", so you can use a higher precision 
library. Which is what you would want when building lookup-tables.

But in general, it would be better to have real be a compile time 
type only and instead have ieee32, ieee64, ieee80, ieee128 etc.
Feb 06 2022
parent reply kinke <noone nowhere.com> writes:
On Sunday, 6 February 2022 at 13:42:16 UTC, Ola Fosheim Grøstad 
wrote:

 It says "or greater precision", so you can use a higher 
 precision library.


GDC does this. LDC could use an 128-bit emulation to fix e.g. 
cross-compilation from x86 to non-Apple AArch64 (but LLVM has 
such functionality already). And yeah, according to the spec, a 
128-bit emulation should suffice for targeting x86 too, but CTFE 
results might slightly diverge from a native x86-DMD then.


 But in general, it would be better to have real be a compile 
 time type only and instead have ieee32, ieee64, ieee80, ieee128 
 etc.


I strongly disagree. `real` is the cross-platform solution for 
'max hardware precision' or 'C long double', and most code should 
probably use float/double.
Feb 06 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 6 February 2022 at 13:47:37 UTC, kinke wrote:

 I strongly disagree. `real` is the cross-platform solution for 
 'max hardware precision' or 'C long double', and most code 
 should probably use float/double.


And when would you use this?

D has alias, so you all you need is a feature that allows you to 
query what is compiled to hardware instructions and what is 
compiled to software, then bind it.

This what actual production code does in C/C++ too. If you are 
flexible about precision you typically bind it to an alias. E.g. 
in signal processing you might bind "sample_t" to a known fixed 
floating point type in your configuration header.
Feb 06 2022
parent reply kinke <noone nowhere.com> writes:
On Sunday, 6 February 2022 at 14:22:05 UTC, Ola Fosheim Grøstad 
wrote:

 D has alias, so you all you need is a feature that allows you 
 to query what is compiled to hardware instructions and what is 
 compiled to software, then bind it.


I'm not sure we're talking about the same thing. This has nothing 
to do with adding software-emulated D floating-point types, but 
solving a cross-compilation issue for the compiler itself in case 
target `real` != host `real`. User code with such demands should 
probably use a well-established library - but that's not probably 
not really an acceptable solution for the DMD frontend itself.
Feb 06 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 6 February 2022 at 14:38:21 UTC, kinke wrote:

 types, but solving a cross-compilation issue for the compiler 
 itself in case target `real` != host `real`.


Ah, ok. So it is only for cross compilation. Then it makes sense.
Feb 06 2022