[fpc-devel] softfloat: sizeOf( floatx80 )

[Martin Frb]

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?