[fpc-devel] fpc bug with M1

[Jonas Maebe]

On 30/12/2021 21:03, Florian Klämpfl via fpc-devel wrote:
> 
> 
>> Am 30.12.2021 um 20:57 schrieb Jonas Maebe via fpc-devel <fpc-devel at lists.freepascal.org>:
>>
>> On 30/12/2021 20:55, Martin Frb via fpc-devel wrote:
>>> On 30/12/2021 20:46, Jonas Maebe via fpc-devel wrote:
>>>> On 30/12/2021 18:06, Florian Klämpfl via fpc-devel wrote:
>>>>>
>>>>> Ah yes, or like this. Nevertheless, the question is whether the ldrsb w0,[x0] is correct or not.
>>>>
>>>> Yes, I was unclear: with the "I don't know/remember where this is done" I meant "changing the load of the unsigned byte type into a signed load". I can't think immediately of a reason either why this is done.
>>> "unsigned byte"? The pointer in the pascal code is a pint8 => signed.
>>
>> Oh, I thought it was puint8. Then it makes sense. c90616944d3bde7b36e924d27a0790195d61f95c applies both to OS_8 and OS_S8.
> 
> 
> 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.


Jonas