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 _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
