Permalink
Reply
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?
| Thread overview | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
February 05, 2022 80 bit floating point emulator | ||||
|---|---|---|---|---|
| ||||
 | 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. | |||
February 06, 2022 Re: 80 bit floating point emulator | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Walter Bright | ||||
February 06, 2022 Re: 80 bit floating point emulator | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | 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. | |||
February 06, 2022 Re: 80 bit floating point emulator | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Walter Bright | 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.
| |||
February 06, 2022 Re: 80 bit floating point emulator | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Temtaime | 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.
| |||
February 06, 2022 Re: 80 bit floating point emulator | ||||
|---|---|---|---|---|
| ||||
Posted in reply to max haughton | 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. | |||
February 06, 2022 Re: 80 bit floating point emulator | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | 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. | |||
February 06, 2022 Re: 80 bit floating point emulator | ||||
|---|---|---|---|---|
| ||||
Posted in reply to max haughton | 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. | |||
February 06, 2022 Re: 80 bit floating point emulator | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Ola Fosheim Grøstad | 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 | |||
February 06, 2022 Re: 80 bit floating point emulator | ||||
|---|---|---|---|---|
| ||||
Posted in reply to kinke | 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? | |||
Copyright © 1999-2021 by the D Language Foundation