On 28/09/2024 09:34, Pierre Muller via fpc-devel wrote:
I think that the big endian version (see grep below)
would suffer if you would use packed
because the high field of size 2,
would put the low field of size 8 at offset 2,
which would trigger unaligned access to this field.
For the little endian definition,
it doesn't change anything, does it?
It's not to important (for my case ).
I have a case where the data comes from another process (just 10 bytes,
that are an extended in a 32bit process (Win), and get loaded by a 64bit
process into the softfloat.)
I was comparing; SizeOf(MyVAr) = 10
and that failed.
So now I had to hardcode everywhere that a floatx80 can take those 10 bytes.
If I had wanted to put that in a generic and specialize with floatx80,
double and single, then I had a problem because sizeOf would not work. I
don't currently need it as generic.
About the big endian issue: That means it is not memory compatible with
a native "extended" because it has a gap. So if you load data from a
file/stream that has been written with native (gap free) extended, then
it wont work.
I don't know if floatx80 promises such compatibility. But it would be
very useful if it did.
On little endian, tests have shown that it can be used that way.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
