MicroPython Native Code Emitter Gotchas

[ndavenport]

Since we found the documentation on the native code emitter to be a bit brief, we decided to run some quick experiments to find out what currently works and what doesn't on the Unix and the ESP8266 ports.

Hope it's useful for somebody!

https://www.pozetron.com/blog/micropyth ... e-gotchas/

[pythoncoder]

That is useful information.

I take the view that Native and Viper are best used sparingly. I first evaluate which pieces of code are responsible for using a lot of processor time. After fully debugging the code using the bytecode emitter, I then apply the Native emitter to those portions of code only. If further optimisation is required I then move to Viper. It is normal to have to adapt the code for Viper (e.g. using type hinting). These emitters seem to work best for code containing a lot of bitwise operations or integer arithmetic.

If it still runs like a slug on Valium there is always the inline assembler. Now that is fast

[SpotlightKid]

From the article:

OK, the module was not imported because an exception was raised. But, surprisingly, it imports successfully on the second try (in CPython, it would fail every time):

I think I can clear up that one. It only looks as if the module imported correctly the second time. But it didn't. A current shortcoming of Micropython is that modules which fail to import, are nevertheless entered in the global modules dict, incomplete as they are. So the second time you try to import them, Micropython thinks that the module has already been imported and does nothing.

[pythoncoder]

Yes, this has caught me out. I wonder if it should be raised as an issue?