Summary

This PR introduces improvements in the code that gets generated for integer-indexed load and store operations for various architectures.

The Viper integer-indexed generator bits are now able to utilise a specialised operation implementation if the platform emitter exposes one. This means that macros namedASM_{LOAD,STORE}{8,16,32}_REG_REG_OFFSET are used if they are present in the platform backend.

ASM_LOAD16_REG_REG_OFFSET,ASM_LOAD32_REG_REG_OFFSET, andASM_STORE32_REG_REG_OFFSET were already present since they are used by the native emitter, so their implementations are used also by the Viper emitter now. This may or may not reduce the code size, but it streamlines the current behaviour by having one single optimised implementation on each platform.

However, those three implementations are now exposed to scenarios where accessing larger than usual offsets is a somewhat probable occurrence - requiring some changes to make them work in all possible cases on Arm, Thumb, and Xtensa. The full set of integer-indexed load/store is not implemented for all Viper operations on all platforms, as the focus of this PR is ARMv7-M improvements. The rest of the changes is there to adapt the other platform backends to the infrastructure changes needed for ARMv7-M. The remaining load/store operations' code will come later in a different PR if the code size increase can be kept to a minimum.

The Arm emitter is now able to generateLDR andSTR integer-indexed opcodes whose offsets can span the full 32 bits address space. The original behaviour would be undefined if the offset was larger than 12 bits, as it would corrupt the upper bits of the generated opcode itself.

The Thumb emitter is now able to generate ARMv7-M opcodes for all data sizes if both ARMv7-M opcodes are allowed and if the opcode offset spans between 6 and 12 bits. In that case a single 32 bits opcode will be generated (LDR{B,H}.W andSTR{B,H}.W), falling back to the existing generic code sequence generator if the offset is too big to be embedded in a single opcode.

The Xtensa emitter is now able to generate opcode sequences spanning the full 32 bits address space for 32 bits loads and stores, and for 16 bit loads. The existing implementations would raise aRuntimeError if the offset could not be embedded in a single opcode.

Testing

The native and viper tests intests/micropython were ran successfully on QEMUMPS2-AN385,SABRELITE, andVIRT_RV32 boards, on a NodeMCU v3 8266 board, on a generic ESP32 D0WD board, and on x64 via the Unix port.

Trade-offs and Alternatives

I've tried to keep the extra code footprint as limited as possible without having to make the code too complex to follow (leaving some potential ARMv7-M only optimisations out as well, taking up a bit more space).

This is mostly evident for armv6/armv7 targets, where the overhead should be ~200 bytes. This was offset a bit by moving out some code from the native emitter to the platform backends, where a simpler implementation could suffice.

However there are some benefits in more optimised code being generated, and in a slight decrease of complexity in the Viper emitter as less platform-specific code is present there.