80 bit floating point emulation (page 2)

On Saturday, 9 July 2022 at 09:47:36 UTC, JG wrote: > On Friday, 8 July 2022 at 22:04:38 UTC, Walter Bright wrote: >> In order for DMD to become a proper cross compiler, it needs to be able to emulate 80 bit floating point. The full x87 doesn't need to be emulated, just >> add, sub, mul, div, cmp, neg, tst. >> >> [...] > > Thinking of spending a few hours later to get an idea of how long it will take to do. Any specification to work from? https://github.com/dlang/phobos/pull/8426/commits/60f5bfa45a4e14038d48d8489b9304923d463867?file-filters%5B%5D=.d&show-viewed-files=true#diff-ef198448dbb3bdace117f346640e1d06f0ada2a0867f995f31b6795a225eb9d7

On Saturday, 9 July 2022 at 06:56:25 UTC, Daniel N wrote: > LDC always uses 64-bit double for real, no 80 bit support anywhere afaik. Hmmm, so we have a proper cross compiler that doesn't use an 80 bit fp emulator? And it generates faster numeric code too?! Fascinating.

On Saturday, 9 July 2022 at 11:53:32 UTC, Adam D Ruppe wrote: > [snip] > > Hmmm, so we have a proper cross compiler that doesn't use an 80 bit fp emulator? And it generates faster numeric code too?! > > Fascinating. Well the reason to use 80bit FP isn't to produce faster code...

On Saturday, 9 July 2022 at 06:56:25 UTC, Daniel N wrote:

On Saturday, 9 July 2022 at 00:05:07 UTC, Adam D Ruppe wrote:

On Friday, 8 July 2022 at 22:04:38 UTC, Walter Bright wrote:

In order for DMD to become a proper cross compiler

(We don't use other peoples' emulators because of licensing issues.)

Does ldc have an emulator you don't use for licensing? or does it manage to be a usable cross compiler without 80 bit reals?

LDC always uses 64-bit double for real, no 80 bit support anywhere afaik.

A quick scan of LLVM code reveals support for a small menagerie of floating point types: f16, bf16, f32, f64, f128 and f80 for x86 targets.

I imagine LDC could support code generation for any subset of these relatively easily. I'd be surprised if gdc could not.

Which of these types should be supported at CT is an open question. I'd suggest all of them or just {f32, f64}.

A related question is how we might improve multi-target programming. Standardized introspection wrt target HW capabilities would be a good first step. There are others.

July 09, 2022

Re: 80 bit floating point emulation

Posted by Iain Buclaw
in reply to Bruce Carneal

Permalink

Iain Buclaw

Posted in reply to Bruce Carneal

Permalink

On Saturday, 9 July 2022 at 13:50:12 UTC, Bruce Carneal wrote:

On Saturday, 9 July 2022 at 06:56:25 UTC, Daniel N wrote:

On Saturday, 9 July 2022 at 00:05:07 UTC, Adam D Ruppe wrote:

On Friday, 8 July 2022 at 22:04:38 UTC, Walter Bright wrote:

In order for DMD to become a proper cross compiler

(We don't use other peoples' emulators because of licensing issues.)

Does ldc have an emulator you don't use for licensing? or does it manage to be a usable cross compiler without 80 bit reals?

LDC always uses 64-bit double for real, no 80 bit support anywhere afaik.

A quick scan of LLVM code reveals support for a small menagerie of floating point types: f16, bf16, f32, f64, f128 and f80 for x86 targets.

I imagine LDC could support code generation for any subset of these relatively easily. I'd be surprised if gdc could not.

GDC does software emulation for all floating point operations in the D compiler, it emulates the target platform by default, but it's written as such that it could support emulating native float with a 160-bit mantissa, and 26-bit exponent.

On 7/9/2022 2:47 AM, JG wrote: > On Friday, 8 July 2022 at 22:04:38 UTC, Walter Bright wrote: >> In order for DMD to become a proper cross compiler, it needs to be able to emulate 80 bit floating point. The full x87 doesn't need to be emulated, just >> add, sub, mul, div, cmp, neg, tst. >> >> [...] > > Thinking of spending a few hours later to get an idea of how long it will take to do. Any specification to work from? It's IEEE748 You'll mainly need to be aware of sticky bits, guard bits, and unnormals.

Forums