Michael Weiser michael.weiser@gmx.de writes:
These comment changes are bugging me:
diff --git a/arm/memxor.asm b/arm/memxor.asm index 239a4034..b802e95c 100644 --- a/arm/memxor.asm +++ b/arm/memxor.asm @@ -138,24 +138,24 @@ PROLOGUE(nettle_memxor) adds N, #8 beq .Lmemxor_odd_done
- C We have TNC/8 left-over bytes in r4, high end
- C We have TNC/8 left-over bytes in r4, (since working upwards) low
- C end on LE and high end on BE S0ADJ r4, CNT ldr r3, [DST] eor r3, r4
The correctness in all cases is not that obvious to me now, but the idea is that we write aligned words, and read aligned words. But since input and output may have different alignment, src words are shifted around so that matching bytes are xored together. The ascii art a bit higher up in the file tries to illustrate that.
At this point in the code, r4 holds an aligned word read from the src area (possibly reading to a word edge beyond the end of the input bytes). The first bytes in this word (on LE, those are the least significant "low end" bytes of r4) have already been xored with the previous destination word and stored back. The "left-over" bytes referred to in the comment are the bytes in r4 that have not yet been processed, and those are the last bytes, and which in LE are the most significant bytes of r4, located at the "high end" of the register.
And then not all of the left-over bytes should be stored back after xoring, since they may be read from beyond the end of the input.
Does that make sense?
The C code does something similar, except that I think it avoids reading anything beyond end of input, since that is undefined behavior in C.
Full patch for reference again below and at https://git.lysator.liu.se/michaelweiser/nettle/-/tree/arm-memxor-generic.
If it's acceptable shall I rather git send-email it or do a MR on gitlab?
Either alternative is ok (although I'm still not that used to gitlab MRs).
Regards, /Niels