Esp32-c3 native and viper decorators

[megazhuk]

Hi !
Am i right, that esp32c3 port doesn't have:

• @micropython.native
• @micropython.viper

decorators?

This is very useful decorators, and so critical in some projects especially when processing kilobytes of arrays.
Are there any plans to add them in new versions? Are this decorators in roadmap?
I want to migrate from esp32 to esp32c3, but the lack of this functionality was an unpleasant surprise.

Is it disabled (because unstable or untested) in sources or it is just not implemented?

[jimmo]

It is not implemented. The C3 is a different architecture (riscv) compared to the earlier ESP32 (xtensa) and no native emitter has been written yet.

[george-hawkins]

I just hit this too. The original commit for py/asmxtensa.c that provides Xtensa emitter support looks quite involved but reasonably short at 170 lines (in the meantime, it has grown to 265 lines).

I wonder how the C3 RISC-V support even works? In the py subdirectory, I see asm*.c files for ARM, x86 and Xtensa but no such file for RISC-V. So, I guess it's somehow possible to support an architecture without something that can emit native assembler for it.

But that makes me wonder what's happening with the native libraries provided with the C3 port. Are they compiled or not? In my code, that maxes out the MCU, I get the impression that it's my code that's really suffering from the lack of @micropython.viper support, e.g. calls to my own functions seem much more expensive than calls into the libraries. I.e. the function call overhead (irrespective of what the function itself actually does) seems to be different between my code and the libraries.

Given the moderate size of asmxtensa.c, I wonder how much effort would be required to produce something similar for the C3? I presume as RISC-V MCUs become more popular, the desire for fast RISC-V code will grow. I'd be willing to partake in some kind of group sponsorship of this effort.

[jaguilar]

But something in MicroPython would have to be producing whatever the relevant toolchains can consume, whether it's assembler or IR. Do you know what bit of the MircoPython codebase handles this? And what exactly is being produced, is it e.g. LLVM IR?

It's possible I'm misunderstanding your question, but for @micropython.native and @micropython.viper, there are no toolchains involved. The machine code is generated directly by micropython. That's what's happening in, e.g. asmthumb.c. As far as I can tell, where all this code converges is in emit.h and the implementations of the functions in those files. You can see from there that in order to emit native code for a given backend, there needs to be an _emit_inline_asm_method_table_t for the given ISA. Since there is none for RISC-V, it's not possible for micropython itself to emit native code for RISC-V.

[jimmo]

@george-hawkins There are two different compilers at play here:

• gcc compiles the main firmware (written in C) for the target architecture. gcc has excellent support for riscv (and xtensa), and the Espressif SDK (the IDF) has all the necessary support for both architectures.
• micropython itself compiles python code for the target architecture (either via mpy-cross, or on the device, when using @native or @viper). riscv support for this compiler is not implemented yet (but I have seen people working on it, e.g. ports: Add RISC-V 32 bit QEMU port. #12853).

[george-hawkins]

That @jaguilar and @jimmo - the pointer to the #12853 PR is very interesting. There seems to have been a lot of activity on it back in November and little since. I hope @agatti has a chance to pick it up again 👍

[agatti]

@george-hawkins I wouldn't mind continuing the work - after all most of it is already done (platform definition, NLR, and code emitter: see agatti@ee99e55) and it just needs to be split up into reasonable chunks and merged in.

For #12853 I've been waiting for further feedback regarding licensing issues brought up from the maintainers' team and it may have slipped through (no worries, it can happen). I also noticed I need to rebase it - will do that later today. Anyway, once that's done and merged in then it's NLR to be polished up and submitted (once qemu is in place then things are much easier to reason about), and lastly the RV32IM code emitter.

If all of that gets in I don't mind to add compressed instructions support to the emitter and 64 bits support too :)

[agatti]

I've had to rewrite the emitter as the old drive failed and there was no push on GitHub for the most recent version I had :|

However, if anybody wants to try it out, the whole new and improved lot is now available from https://github.com/agatti/micropython/tree/nativeemit-riscv

This passes native and viper tests on both qemu-riscv (see #12853) and on an ESP32C3 board. Right now this is not merge-ready as it depends on #15094 (otherwise you'd have to guess where your setjmp implementation stores the registers holding emitter locals), and it probably won't build on windows due to the usage of GCC/Clang only __attribute__((unused)) decorators on some C functions (can't find the proper MSVC incantation to make it work, and I have no windows machine to test it with anyway).

No guarantees it will work with your code though :)

Right now the code it generates is not optimal as some code sequences can be optimised depending on the values they operate on. Changing the code size between compilation passes triggers an assertion when building with DEBUG=1, so generated code fragments have to be padded with NOPs to keep the fragment size constant. Some RISC-V implementations have a faster execution path for NOP opcodes ("ADDI ZERO, ZERO, 0", actually) so it's not all that bad yet. Once this bit is sorted (I see asm_thumb_mov_reg_i32_optimised generating sequences of different sizes depending on the value, wouldn't that misalign jump target addresses?), then support for compressed instruction (C extension) can be added, as then the instruction stream will mix 32 bits and 16 bits opcodes freely with no padding.

That said, if you want to try it out on an ESP32C3 you need these changes in your project's configuration:

--- a/ports/esp32/mpconfigport.h
+++ b/ports/esp32/mpconfigport.h
@@ -18,9 +18,12 @@
 
 // object representation and NLR handling
 #define MICROPY_OBJ_REPR                    (MICROPY_OBJ_REPR_A)
-#define MICROPY_NLR_SETJMP                  (1)
 #if CONFIG_IDF_TARGET_ESP32C3
 #define MICROPY_GCREGS_SETJMP               (1)
+#define MICROPY_EMIT_RV32                   (1)
+#else
+#define MICROPY_EMIT_RV32                   (0)
+#define MICROPY_NLR_SETJMP                  (1)
 #endif
 
 // memory allocation policies

If you use mpy-cross to pre-build .mpy files, you must pass -march=rv32i to its command line to generate native RISC-V code and bundle it in the final file.

Lastly, if you want to run the tests, then run-tests.py needs to be changed as follows:

--- a/tests/run-tests.py
+++ b/tests/run-tests.py
@@ -1085,6 +1085,8 @@
                 args.mpy_cross_flags = "-march=armv6m"
             elif args.target == "pyboard":
                 args.mpy_cross_flags = "-march=armv7emsp"
+            elif args.target == "esp32":
+                args.mpy_cross_flags = "-march=rv32i"
             else:
                 args.mpy_cross_flags = "-march=armv7m"

so running ./run-tests --target esp32 --device=<whatever> will pregenerate RISC-V code in your .mpy files.

The latter bit needs further changes as esp32 should be split into esp32-xtensa and esp32-riscv or into esp32 and esp32c3, but that's for later.

[kapest007]

Is there any news on the implementation of RiscV and xtensa?

[agatti]

It was merged into master last month, just enable MICROPY_EMIT_RV32 in your port configuration file.

Keep in mind that if you don't want to/can't disable MICROPY_NLR_SETJMP, you need to apply #15395 first, otherwise it will crash when native code needs to deal with exception handling.

[kapest007]

Thank you very much for the quick reply. I am currently trying out ARM-Thumb on the Raspberry Pi Pico.
I will wait for it to be included in one of the next releases.
With which Decorator will it be possible then?

[agatti]

Oh, if you're thinking of inline assembler (as in @micropython.asm_thumb for the Pico) it is not there yet, sorry. What was added was support for @micropython.native and @micropython.viper code generators, which take regular python code and emit RISC-V native code instead.

Adding RISC-V inline assembler support is in my list of things to do, but at the moment I'm busy working on native modules support. Once that is sorted out (debugging is slow due to #15408 making things harder to figure out), inline assembler is next in line to be worked on.

[kapest007]

Thanks for the info. I'm already looking forward to the inline assembler.
It doesn't matter if it still takes a while.

Thank you.