On Mon, 7 Aug 2023, Anders Magnusson wrote:
Though, hmm, it has struck me that the program might expect the IEEE 754
exponent range of the double FP type, which raises a question: which of
D_floating and G_floating format has our port chosen? If it's G_floating,
then I'd expect the very narrow difference from IEEE 754 double highly
unlikely to hit, however with D_floating where the width of the exponent
is the same as with F_floating, i.e. the single FP type, it's actually
very likely.
The vax port uses FD floats.
I have thought so, but wanted to double-check.
Overall I think we ought to support both, but it might be a bit tricky on
the toolchain side, as it's an ABI issue to sort out. Did any machine
actually implement H_floating in hardware, or was it only ever emulated?
The 780 had H-float in hardware. Actually, it had all instructions in
hardware (microcode).
Do we actually support or intend to support that model? If not, then I
would yet need to verify if that's actually legal by the ISO C language
standard (which I reckon has certain requirements as to the ranges of the
real data types defined), but I think it would be a reasonable idea to map
F_floating, D_floating and G_floating quantities respectively to the
`float', `double' and `long double' data types.
This might not immediately help the case at hand, but would lay grounds
for the ABI (think C++ symbol name mangling), and then with a clever
arrangement we might be able to make most things designed with IEEE 754 in
mind work as expected. I.e. we could have a compilation flag that makes
the `double' and `long double' data types both map to G_floating, but
encoded as `long double' at the ABI level, so that interlinking with code
that uses the D_floating data type works. I think it can be made seamless
as hardware supports the four FP data types all at once without the need
to switch modes or suchlike.