[fpc-devel] softfloat: sizeOf( floatx80 )

[Florian Klämpfl]

> Am 28.09.2024 um 09:24 schrieb Pierre Muller via fpc-devel <fpc-devel at lists.freepascal.org>:
> 
> 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?

Yes, the record wouldn’t be aligned anymore like a real extended and on some platforms it would be accessed only bytewise.

> 
> Pierre
> 
> See this grep result:
> 
> muller at cfarm187:~/pas/trunk/fpcsrc/rtl/inc$ grep -inA9 "floatx80 *=" *
> softfpu.pp:139:  floatx80 = record
> softfpu.pp-140-    case byte of
> softfpu.pp-141-      // force the record to be aligned like a double
> softfpu.pp-142-      // else *_to_double will fail for cpus like sparc
> softfpu.pp-143-      // and avoid expensive unpacking/packing operations
> softfpu.pp-144-      1: (dummy : extended);
> softfpu.pp-145-      2: (low : qword;high : word);
> softfpu.pp-146-  end;
> softfpu.pp-147-
> softfpu.pp-148-  float128 = record
> --
> softfpu.pp:167:  floatx80 = record
> softfpu.pp-168-    case byte of
> softfpu.pp-169-      // force the record to be aligned like a double
> softfpu.pp-170-      // else *_to_double will fail for cpus like sparc
> softfpu.pp-171-      // and avoid expensive unpacking/packing operations
> softfpu.pp-172-      1: (dummy : qword);
> softfpu.pp-173-      2: (high : word;low : qword);
> softfpu.pp-174-  end;
> softfpu.pp-175-
> softfpu.pp-176-  float128 = record
> --
> ufloatx80.pp:32:      floatx80 = {$IFDEF FPC_DOTTEDUNITS}System.SoftFpuX80{$ELSE}sfpux80{$ENDIF}.floatx80;
> ufloatx80.pp-33-
> 
> 
>> Le 27/09/2024 à 20:00, Martin Frb via fpc-devel a écrit :
>> Is there any indention in
>>    floatx80 = record
>>      case byte of
>>        1: (low : qword;high : word);
>>        // force the record to be aligned like a double
>>        // else *_to_double will fail for cpus like sparc
>>        // and avoid expensive unpacking/packing operations
>>        2: (dummy : extended);
>>    end;
>> NOT being a packed record?
>> If it was packed, it should have the same size as an actual extended: 80
>> bits / 10 bytes.
>> Possible similar issues for other softfloat types
>> _______________________________________________
>> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
>> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> 
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel