xcc long double implementation

[David Jones]

The long double data type on the X86 cross compiler is broken, seriously broken. I'm just curious about what format they intend it to be. The sizeof operator says it's 16 bytes, implying it's using 128-bits. Are they assuming the assuming the hardware doesn't support 128-bit fp and trying to do a software implementation?

[Phillip Helbig (undress to reply)]

The long double data type on the X86 cross compiler is broken, seriously br=
oken. I'm just curious about what format they intend it to be. The sizeof o=
perator says it's 16 bytes, implying it's using 128-bits. Are they assuming=
the assuming the hardware doesn't support 128-bit fp and trying to do a so=
ftware implementation?

Can I conclude from that that you are getting the OSU server to run on
x86?

[David Jones]

Post by Phillip Helbig (undress to reply)
Can I conclude from that that you are getting the OSU server to run on
x86?

No. The OSU server's code doesn't use long double. SQLite uses long double, but
fortunately it's a soft requirement and you can substitute using a double. It only
uses long double (for best precision) in a few places related to converting text
representations of floating point numbers to the REAL data type (IEEE 64 bit format).

The host I'm using doesn't have the tcpip$*.h headers in the X86$LIBRARY
directory right now, complicating a cross build of the OSU server.

[Arne Vajhøj]

Post by David Jones
The long double data type on the X86 cross compiler is broken,
seriously broken. I'm just curious about what format they intend it
to be. The sizeof operator says it's 16 bytes, implying it's using
128-bits. Are they assuming the assuming the hardware doesn't support
128-bit fp and trying to do a software implementation?

x86-64 HW does not support 128 bit FP I believe so it will
have to be software.

But using IEEE standard format seems pretty obvious.

Arne

[Arne Vajhøj]

Post by David Jones
The long double data type on the X86 cross compiler is broken,
seriously broken. I'm just curious about what format they intend it to
be. The sizeof operator says it's 16 bytes, implying it's using
128-bits. Are they assuming the assuming the hardware doesn't support
128-bit fp and trying to do a software implementation?

Cross compilers are such sour sorrow.
long double is... weird... on x86.
It's usually 80 bits of actual floating point content stored inside a
larger 12- or 16-byte bag, but it's also sometimes "just" double,
depending on the compiler.
I'd suspect VSI is planning to follow gcc and clang here, and will be
using the x87 80-bit representation and not the 64-bit double
representation, but haven't confirmed.

x86 had the weird 80 bit FP's.

But wasn't those ditched in x86-64?

Arne

[John Dallman]

Post by Arne Vajhøj
x86 had the weird 80 bit FP's.
But wasn't those ditched in x86-64?

No. The short answer is that 80-bit float /can/ be used in 64-bit x86
code, and context switches on most (or all) OSes will save and restore
the relevant registers, but there's a strong convention of not doing it.
That convention is shared between Windows, Linux, and macOS to my
knowledge, and likely applies on many other OSEs.

80-bit floating-point is poor value: it doesn't give you much more
precision, no other modern hardware supports it (the Motorola 68000
family floating-point did, but that's dead), and it takes up a lot of
memory: 12 byes (two wasted) or 16 bytes (six wasted).

The registers and instructions that give access to 80-bit float have been
retained because there is old 32-bit software that uses that instruction
set, although rarely for 80-bit. Intel and AMD would probably be happy to
drop it, but there would inevitably be complaints.

If one company did it first, the other would exploit the fact to gain
market share; if they agreed to do it together, an anti-trust suit would
likely succeed, and the costs of replacing "faulty" processors would be
horrific.

John

[George Cornelius]

Post by John Dallman
The registers and instructions that give access to 80-bit float have been
retained because there is old 32-bit software that uses that instruction
set, although rarely for 80-bit. Intel and AMD would probably be happy to
drop it, but there would inevitably be complaints.
If one company did it first, the other would exploit the fact to gain
market share; if they agreed to do it together, an anti-trust suit would
likely succeed, and the costs of replacing "faulty" processors would be
horrific.

When something is fouled up beyond recognition, look around for the
lawyers! (Cor. If there are no lawyers, then it's the military.)

Post by John Dallman
John

[Simon Clubley]

Post by George Cornelius
When something is fouled up beyond recognition, look around for the
lawyers! (Cor. If there are no lawyers, then it's the military.)

Sometimes it's not the military that's responsible for really fouling
things up but the clueless politicians/civilians in charge of them...

Simon.

[Bill Gunshannon]

Post by Simon Clubley

Post by George Cornelius
When something is fouled up beyond recognition, look around for the
lawyers! (Cor. If there are no lawyers, then it's the military.)

Sometimes it's not the military that's responsible for really fouling
things up but the clueless politicians/civilians in charge of them...

Or the politicians wearing uniforms with stars on them who only
claim to me military. Remember, The Commander in Chief is not
military, he is a civilian. And the current one was a draft
dodger with absolutely no military experience.

bill

[Henry Crun]

Post by Bill Gunshannon

Post by Simon Clubley

Post by George Cornelius
When something is fouled up beyond recognition, look around for the
lawyers! (Cor. If there are no lawyers, then it's the military.)

Sometimes it's not the military that's responsible for really fouling
things up but the clueless politicians/civilians in charge of them...

Or the politicians wearing uniforms with stars on them who only
claim to me military.  Remember, The Commander in Chief is not
military, he is a civilian.  And the current one was a draft
dodger with absolutely no military experience.
bill

... as opposed to the previous one?

[Bill Gunshannon]

Post by Henry Crun

Post by Bill Gunshannon

Post by Simon Clubley

Post by George Cornelius
When something is fouled up beyond recognition, look around for the
lawyers! (Cor. If there are no lawyers, then it's the military.)

Sometimes it's not the military that's responsible for really fouling
things up but the clueless politicians/civilians in charge of them...

Or the politicians wearing uniforms with stars on them who only
claim to me military.  Remember, The Commander in Chief is not
military, he is a civilian.  And the current one was a draft
dodger with absolutely no military experience.
bill

... as opposed to the previous one?

The previous one was 4F from the beginning. The current one played
youth sports, high school sports and college sports. And then after
22 years of being an athlete he suddenly had asthma just in time for
his student draft exemption to expire. I know, just a coincidence.

bill

[Arne Vajhøj]

Post by Henry Crun

Post by Bill Gunshannon

Post by Simon Clubley

Post by George Cornelius
When something is fouled up beyond recognition, look around for the
lawyers! (Cor. If there are no lawyers, then it's the military.)

Sometimes it's not the military that's responsible for really fouling
things up but the clueless politicians/civilians in charge of them...

Or the politicians wearing uniforms with stars on them who only
claim to me military.  Remember, The Commander in Chief is not
military, he is a civilian.  And the current one was a draft
dodger with absolutely no military experience.

... as opposed to the previous one?

The previous one was 4F from the beginning.  The current one played
youth sports, high school sports and college sports.  And then after
22 years of being an athlete he suddenly had asthma just in time for
his student draft exemption to expire.  I know, just a coincidence.

Amazing what one can learn from Wikipedia.

Also about recent presidents military history:

46: 5 student draft deferments + 1 conditional medical deferment due to
asthma

45: 4 student draft deferments + 1 conditional medical deferment + 1 not
acceptable for service due to bone spurs

44: too young to be drafted - never volunteered for military service

43: did serve during Vietnam War - in Texas Air National Guard stationed
in Texas

42: several student draft deferments - eventually registered for draft
but pulled a very high number so was not drafted

The last US president to have actually seen combat was 41.

Arne

[Craig A. Berry]

Post by David Jones
The long double data type on the X86 cross compiler is broken,
seriously broken. I'm just curious about what format they intend it
to be. The sizeof operator says it's 16 bytes, implying it's using
128-bits. Are they assuming the assuming the hardware doesn't support
128-bit fp and trying to do a software implementation?

The last time it came up, it wasn't actually settled:

https://groups.google.com/g/comp.os.vms/c/cjiX6ue7BaY/m/zPR-DJPzFQAJ

the gist of which seems to be that what the cross compiler does is no
indication of what we'll end up getting, and the problem will probably
be swept under the rug until the native compilers come along.

[John Reagan]

Post by David Jones
The long double data type on the X86 cross compiler is broken, seriously broken. I'm just curious about what format they intend it to be. The sizeof operator says it's 16 bytes, implying it's using 128-bits. Are they assuming the assuming the hardware doesn't support 128-bit fp and trying to do a software implementation?

The other interesting twist to long double is parameters and functions that return them. On Alpha & Itanium, they are returned by hidden parameter as the largest immediate return is 64-bits. On the AMD64 ABI, long doubles come back in xmm0. Unfortunately for us, the GEM CIL representation exposes this knowledge about that. This isn't something our GEM to LLVM converter can easily paper over.

[David Jones]

LLVM 3.4.2 only supports the 10-byte/80-bit hardware floating point. However, we want a 16-byte/128-bit floating type (IEEE X_float).

Yeah, I figured you'd want that for consistency with the other OpenVMS platforms. I notice LIBOTS.EXE on X86
doesn't have OTS$CVTQX() and related functions.

SQLite doesn't seem to be consistent across platforms. the SQL statement:

SELECT CAST(9223372036854774800 AS real);

gives slightly different results on my Intel Mac (9.22337203685477e+18) and my Arm-based Pi4
(9.22337203685478e+18). That's the same discrepancy I see between my Alpha/IA64 and X86
builds on OpenVMS. Note that the i64 value being converted has more the 15 significant
decimal digits, the the '4800' is getting rounded up on platforms that don't have long double.

[John Reagan]

Post by David Jones

LLVM 3.4.2 only supports the 10-byte/80-bit hardware floating point. However, we want a 16-byte/128-bit floating type (IEEE X_float).

Yeah, I figured you'd want that for consistency with the other OpenVMS platforms. I notice LIBOTS.EXE on X86
doesn't have OTS$CVTQX() and related functions.

Yes, both for sharing of binary data and alignment of structures.

For f128, current LLVM calls routines in the LLVM-provided 'compiler-rt' library. It is LLVM's equivalent of LIBOTS with a bunch of compiler support routines for code sequences too large to put inline. The f128 routines in compiler-rt have the same names and API as the ones that gcc calls for their f128 support. At this point, I'm leaning on putting those compiler-rt routines into LIBOTS but haven't make my mind up yet.

[gah4]

Post by David Jones
The long double data type on the X86 cross compiler is broken, seriously broken.
I'm just curious about what format they intend it to be.
The sizeof operator says it's 16 bytes, implying it's using 128-bits.
Are they assuming the assuming the hardware doesn't support 128-bit fp
and trying to do a software implementation?

The sizeof operator includes any padding needed. So, being 16 does NOT imply that
it is using 16 bytes, but only that when padded appropriately it will take that many.

Either 8 or 16 byte alignment will round 10 up to 16.

The original idea behind the 80 bit format was to allow extra precision for
intermediate results in calculations. It does that somewhat well, though compilers
complicate even that. Some compilers try to keep values in registers between
statements, giving unexpected extra precision. When compared to results without
that precision, surprising differences occur.

But otherwise, it mostly works well for intermediate values. I never wanted to
use it otherwise. I sometimes do wish for true REAL*16 like IBM S/370 and VAX
have, and more recently RISC-V has, at least an option for it.

It seems that there are now real servers with RISC-V chips, but I don't know if
they implement it.