memcpy was taken off its byte-at-a-time loop in b66bb2659 and memset was left on
one, though the device memsets constantly and the loop is the same shape. This
gives it the same treatment, and it is the simpler of the two: with no source
buffer there is no alignment to match, so once the destination is word aligned
the word fill is always available.
Align the destination, build the fill word once, then store it four at a time
and singly for the remainder, with at most three bytes left over. Unrolled four
ways for the same reason memcpy is: at -Os the loop bookkeeping otherwise costs
more than the stores.
The bulk path goes from six instructions per byte to nine per sixteen bytes,
read off the disassembly:
old subs / cmp / bgt / strb / adds / b per byte
new str x4 / adds / b, plus subs / cmp / bgt per 16 bytes
Wall clock is not measured here. The closest anchor is memcpy's own figure from
b66bb2659, which measured 221us to 34us for a 624 byte aligned frame, and memset
has a store where memcpy has a load and a store.
Verified against libc memset on the host before flashing: 7224 cases, every
alignment from 0 to 7, every length from 0 to 300, and fill bytes 0x00, 0xFF and
0xA5, with no mismatches. Then on hardware, where a wrong memset would show up
everywhere rather than in one place: the DESFire simulation harness passes, and
hw status, hw tearoff, mem info, lf search, hf 14a info and hf mf info all
behave.
Builds for RDV4 and PM5.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The device ships its own string.c because there is no libc linked, and
memcpy was a byte at a time loop: six instructions per byte, 17 cycles
per byte measured, 221us for a 624 byte frame. Every copy on the device
paid that.
Take words when source and destination share their offset within a word,
which is the only case ARM7TDMI can do at all, and unroll the byte tail
four ways since at -Os the loop bookkeeping otherwise costs more than the
copy. 624 bytes aligned goes 221us -> 34us, misaligned 221 -> 125.
192 bytes, was 24. The bootrom does not link string.c.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
I have kept whatever copyright notices exist. Please add your own
copyright notice if you have made any nontrivial changes or additions to
the code. There are several files without any attribution, currently.
