On 28/09/2024 09:45, Martin Frb via fpc-devel wrote:
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.
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.
Just for my understanding.... As I haven't really looked deeply into the
representation of those numbers.
My current understanding starts of with the DWARF spec. That simply
specifies
- type: float
- size (in bytes or bit): ... e.g. 8/64 or 10/80.
In addition, now googled, on wikipedia there is only one format for
80bits? (unless I missed something). But it's in a paragraph referring
to x86...
https://en.wikipedia.org/wiki/Extended_precision#x86_extended_precision_format
From that any debugger on any platform seems to be able to read such a
float. So I presumed that for a given length there is a standard how the
number should be represented in memory?
I haven't tested if e.g. gdb would on a big endian be able to read an
80bit float. Or if it would just say that is an invalid size for the
platform.
But given that floats (like any other data) can be streamed to files and
other media, I would expect that the existence does not change by the
features of the CPU.
Of course the byte order may change. (I don't know if bytes or bits for
extended are in a diff order on a big endian? But if they are the reader
of a stream would know to fix that). But I wouldn't expect gaps in the
data, that is assuming the data can exist.
Now all of the above are just conclusions from one rather small starting
point. So I may well be wrong. If I am, I would like to know where?
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
