Native code decorator should be best-effort
Port, board and/or hardware
MacOS X (Apple Silicon)
MicroPython version
MicroPython v1.23.0 on 2024-05-31; darwin [GCC 4.2.1] version
Reproduction
Try running the following code on a macOS device running Apple Silicon using a version of Micropython built for Apple Silicon:
@micropython.native
def test_fun():
print("Hello, World!")
Expected behaviour
I understand that native code execution is not supported on Apple Silicon, but I would expect to still be able to generally execute code even if marked up with native decorators (in order words, I would expect them to be ignored in that case).
Observed behaviour
When trying to test this code locally on my MacBook Pro M2, all functions with the decorator @micropython.native end up generating the following exception:
>>> %Run -c $EDITOR_CONTENT
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
SyntaxError: invalid micropython decorator
>>>
Additional Information
I understand that the @micropython.viper decorator has different behavior and might not be a good candidate for being ignored, so we may want different behavior there. Perhaps an opt-in for allowing it to be ignored? Something like this:
@micropython.viper(optional=true)
def test_fun():
print("Hello, World!")
This would force anyone wanting to test code like this to attest that the behavior would be the same.
Code of Conduct
Yes, I agree
Enable MICROPY_EMIT_RV32 for ESP32-C6 but compile error "invalid arch" with decorator @micropython.native
Port, board and/or hardware
ESP32 C6
MicroPython version
MicroPython 1.24.1
Reproduction
- Create a test file test.py inside frozen folder modules/test.py
- Write a function with decorator @micropython.native
- Build for target ESP32 C6
Expected behaviour
Compile successfully.
Observed behaviour
Compile failed with error "invalid arch"
Additional Information
No, I've provided everything above.
Code of Conduct
Yes, I agree