Repository navigation
esp32: support for native code generation - #5082
Conversation
0f4177b to
8390e90
Compare
8390e90 to
6e1c672
Compare
|
YES YES PLZ, I NEED IT! YES. YOU'RE MY HERO! I APPROVE! |
|
So...what happens now? How can I help you get this merged? |
|
@maludwig I think testing is likely to to be the most helpful thing here. |
|
@jimmo is there a formal process? I have many ESP32s kicking about, I could try it out and just see if its awesome? And then just write here how awesome it is? |
There are still some WIP and TODO comments in some of the commits here, so they need to be addressed. But also, yes, feel free to test it and give feedback. There's no formal process (apart from running the test suite), just see if you can crash it :) |
6e1c672 to
68fc6b5
Compare
4868f24 to
ee10125
Compare
|
I've now finished this off and it should be good to merge. Just needs some final testing that it didn't break esp8266 (or stm32) native code generation. |
ee10125 to
c9fe7c2
Compare
Such that args/return regs for the parent are different to args/return regs for child calls. For an architecture to use this feature it should define the REG_PARENT_xxx macros before including py/emitnative.c.
To enable this feature the N_NLR_SETJMP macro should be set to 1 before including py/emitnative.c.
In which case place the native function prelude in a bytes object, linked from the const_table of that function. An architecture should define N_PRELUDE_AS_BYTES_OBJ to 1 before including py/emitnative.c to emit correct machine code, then enable MICROPY_EMIT_NATIVE_PRELUDE_AS_BYTES_OBJ so the runtime can correctly handle the prelude being in a bytes object.
Window-specific asm emit functions are added, along with a new macro option GENERIC_ASM_API_WIN.
Enabled via the configuration MICROPY_EMIT_XTENSAWIN.
Selectable via the command line: -march=xtensawin.
c9fe7c2 to
1d21b4e
Compare
|
This was merged! |
3 participants
This PR adds initial support for native code generation on esp32. This was quite difficult to do because of a few major differences with the esp32 architecture:
Native and viper functions work, and the native/viper tests in
tests/micropythonall pass. But I didn't do thorough testing and I'm sure there are still some bugs here and there.The code here requires some conditional compilation to switch behaviour for esp8266 vs esp32 when doing native code generation, along with some general clean up.
Also, a new native architecture will need to be defined to distinguish between esp8266 and esp32 in .mpy files.