<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 28/09/2024 10:56, Karoly Balogh via
fpc-devel wrote:<br>
</div>
<blockquote type="cite"
cite="mid:38fefc80-e95d-47cb-6a08-ddbcaeb57496@scenergy.dfmk.hu">
<pre class="moz-quote-pre" wrap="">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)</pre>
</blockquote>
<br>
Ok, so then on that platform the gap should probably also exist in
the record.<br>
<span style="white-space: pre-wrap">
</span><span style="white-space: pre-wrap">
</span>
<blockquote type="cite"
cite="mid:38fefc80-e95d-47cb-6a08-ddbcaeb57496@scenergy.dfmk.hu"><span
style="white-space: pre-wrap">
</span>
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
Yes, that would have to be deserialised to the gap format, for a
platform that has the gap.<br>
<br>
I would assume that e.g. gdb (if it supports the format at all)
would expect the gap on that platform.<br>
<br>
<span style="white-space: pre-wrap">
</span><span style="white-space: pre-wrap">
</span>
<blockquote type="cite"
cite="mid:38fefc80-e95d-47cb-6a08-ddbcaeb57496@scenergy.dfmk.hu">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">I don't know if floatx80 promises such compatibility. But it would be very
useful if it did.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
</blockquote>
<br>
Ok, well...<br>
<br>
Currently it is only needed on Win-64. For FpDebug. So the 64bit
debugger can cross debug a 32 bit target and show "extended" values
from the 32 bit target.<br>
<br>
I have test case that will detect if FPC changes anything.<br>
If that happens, I will simply have to add a copy of the current
working version to FpDebug.<br>
<br>
Technically, I agree it would then be FpDebug's task to translate
the format. But that would require that the format of floatx80 is
documented in such a way that it can (and is meant to be) written by
3rd party code. <br>
And of course, if I where cross debugging from Intel to M68000 the
adaption would certainly be my duty.<br>
<br>
Maybe the softfloat libraries can provide some routine that takes
memory in the native format and store it correctly into the record?<br>
On Intel: array[0..9] of byte<br>
On M68000: array[0..11] of byte<br>
<br>
Or a record of the correct size, or .... As long as it is
documented. Or does such a doc already exist?<br>
<br>
<br>
<br>
</body>
</html>