> Am 30.12.2021 um 21:07 schrieb Jonas Maebe via fpc-devel
> <[email protected]>:
>
> 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
>>> <[email protected]>:
>>>
>>> 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.
Yes and no.
Gcc compiles
unsigned char f(int i)
{
return i;
}
into a single ret.
This means, that we cannot assume that the upper part of registers is cleared.
Of course, we could limit this to function calls but I guess doing it
consistently is easier to handle.
> 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
> _______________________________________________
> fpc-devel maillist - [email protected]
> <mailto:[email protected]>
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> <https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel>
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
