[fpc-devel] fpc bug with M1

[Martin Frb]

On 30/12/2021 21:07, Jonas Maebe via fpc-devel wrote:
> On 30/12/2021 21:03, Florian Klämpfl via fpc-devel wrote:
>>
>> Yes, but the question is: if we load a shortint into a register, do 
>> we need to sign extend it to 32/64 bit or not? I tend more and more 
>> to say that we shouldn’t require this.
>>
>> Neither clang nor gcc seem to expect this for arguments/return 
>> values: https://godbolt.org/z/sv5fPP6GM
>
> This is not related to arguments/return values. We do the same on on 
> PPC, and afaik on all architectures that don't have 8/16 bit 
> subregisters. I initially did it on PPC because it simplified code 
> generation a lot and solved all kinds of small issues I got otherwise 
> because non-cleared higher parts of registers were used. Maybe with 
> our current code generators it would work better.

Well the issue is, that at some time it needs to be extended, as the 
full expression is

  Result := Result + (pn8^ shr 7) and ((not pn8^) shr 6);

Result is either 64 or 32 depending on architecture.
pn8 is pint8

On intel
- only the byte is loaded. "Not" applies to the byte only.
- Then on intel the value is sign extended, even though an (logical) 
"shr 6" could be done on the byte.
- For the addition, sign extension is needed.

That means that due to the early sign extension, the bytes 8..31 (or 
8..64) before the shift (or 2..25 after) might be set to 1.

Since shr is not arithmetic, and does not keep/fill the "sign bit", I do 
not see why a sign extension is needed at that point. (But that is 
another issue)