The Xtensa Instruction Set Architecture reference manual documents a quartet of instructions that load/store a float and update the address register (LSIU, LSXU, SSIU, SSXU). These are useful for stepping through arrays.
I first discovered the existence of these instructions when my attempt to build a esp-idf application generated:
The SSIU instruction word looks like:/tmp/ccdeTmSo.s:5633: Error: unknown opcode or format name 'ssiu'
Code: Select all
i i i i i i i i 1 1 0 0 s s s s t t t t 0 0 1 1
Code: Select all
Vaddr ← AR[s] + (i << 2)
Store32(Vaddr, FR[t])
AR[s] ← Vaddr
was encoded as:
Code: Select all
i i i i i i i i 1 1 0 0 s s s s t t t t 0 0 1 1
And some further digging turned up a GCC patch (eg https://marc.info/?l=gcc-patches&m=141315401507078&w=2) that stated "Earlier versions of xtensa FPU used to support preincrement FP load and store instructions (lsiu/ssiu). Recent FPU supports postincrement FP load and store instructions only (lsip/ssip)." The choice between pre-increment and post-increment is a compile-time option controlled by the XCHAL_HAVE_FP_POSTINC option in the core-isa.h file. The ESP32 core-isa.h files I can find (eg Customer ID=11657; Build=0x5fe96, supplied with esp-idf) do not mention XCHAL_HAVE_FP_POSTINC, hence GCC is defaulting to pre-increment mode and generating SSIU/LSIU instructions.
OTOH, some experimental code intended to check the actual behaviour suggests my ESP32-WROVER-B module is actually post-increment mode. Can someone confirm that all ESP32 modules use the post-increment definition.
(I will refrain on commenting on the wisdom of silently changing an opcode from meaning *++x to meaning *x++)