> Am 30.12.2021 um 21:07 schrieb Jonas Maebe via fpc-devel > <fpc-devel@lists.freepascal.org>: > > 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@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.
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 - fpc-devel@lists.freepascal.org > <mailto:fpc-devel@lists.freepascal.org> > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel > <https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel>
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel