> Am 30.12.2021 um 17:51 schrieb Jonas Maebe via fpc-devel > <fpc-devel@lists.freepascal.org>: > > On 30/12/2021 17:16, Florian Klämpfl via fpc-devel wrote: >> Am 30.12.21 um 14:52 schrieb Jonas Maebe via fpc-devel: >>> On 29/12/2021 00:48, Martin Frb via fpc-devel wrote: >>>> I don't have an M1 myself, but according to the data from the thread on >>>> the lazarus mail list, there is a bug in the 3.3.1 asm generator for M1 >>>> >>>> var pn8: pint8; // pointer signed byte >>>> >>>> In the below expression ...(not pn8^)... >>>> >>>> "pn8^" is loaded to w0 and sign extended. From this point onwards >>>> operations on the value should be 32 bits (the value has been extended, >>>> and the full 32 bits are later used). >>>> but "not" only affects the lowest 8 bit. >>>> >>>> Apparently in 3.2.2 (or was it 3.2.0) there was >>>> mvn w0,w0 >>>> >>>> If someone can confirm tihs.... >>> >>> It's probably caused by c90616944d3bde7b36e924d27a0790195d61f95c (Florian) >>> >> Isn't the sign extension during the load wrong? Martin didn't post the whole >> assemble code but I would expect that 3.2.2 produced an uxtb instruction >> afterwards which hide the problem. > > No, 3.2.2 afterwards sign-extendeds the result as a signed rather than > unsigned value: > > # [29] Result += (pn8^ shr 7) and ((not pn8^) shr 6); > ldr x0,[sp] > ldrsb w0,[x0] > mvn w0,w0 > sxtb w0,w0 > lsr w1,w0,#6 > ldr x0,[sp] > ldrsb w0,[x0] > lsr w0,w0,#7 > and w0,w0,w1 > sxtw x0,w0 > ldr x1,[sp, #16] > add x0,x1,x0 > str x0,[sp, #16] > > I admit I don't know/remember where this is done though, as AArch64's > a_load_ref_reg doesn't seem to have any special logic that would do this.
Ah yes, or like this. Nevertheless, the question is whether the ldrsb w0,[x0] is correct or not.
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
