[fpc-devel] softfloat: sizeOf( floatx80 )

[Karoly Balogh]

Hi,

On Sat, 28 Sep 2024, Martin Frb via fpc-devel wrote:

> About the big endian issue: That means it is not memory compatible with a
> native "extended" because it has a gap.

Fromt the top of my head, I only know one example of a big endian system
which has an 80 bit extended type in hardware, and it's the Motorola 68000
family. Which actually stores exteded in a 96 bit format in memory, with a
gap. :) (See: Motorola 68000 Family Reference manual, Page 5-110)

> So if you load data from a file/stream that has been written with native
> (gap free) extended, then it wont work.

Well, 1., see above 2., if you _really_ want to have this compatible among
all systems, you need to decide on an on-disk format, including actual
endianness, then just properly serialize-deserialize it to match that.
Anything else is in the "might work" territory for a certain combination
of systems, but otherwise it will break.

> I don't know if floatx80 promises such compatibility. But it would be very
> useful if it did.

No, I don't think promises anything like that. I'd say it is primarily an
internal structure, and using it for I/O might simplify your use case, but
changing it globally to packed will be a massive performance penalty on
some systems where you need this performance the most. So we can't change
it globally in the compiler/RTL.

> On little endian, tests have shown that it can be used that way.

Yeah, the world is full such of little endian "shortcuts", for example
some JIT Javascript engines by design access the same address to get the
lower byte/word/etc of dwords, which just can't work on a big endian
system. I get it - it simplifies the engine and the code generation, but
this still doesn't make it a good practice or design.

Charlie