[SOLVED] micropython.native in frozen bytecode

[kevinkk525]

Is it possible to use the micropython.native emitter in frozen bytecode?

I tried to use it but when compiling the esp8266 firmware I get an error that the emitter is not supported.

[jickster]

Is it possible to use the micropython.native empitter in frozen bytecode?

I tried to use it but when compiling the esp8266 firmware I get an error that the emitter is not supported.

I also tried a few months back and same result.
I don’t think it’s supported.


Sent from my iPhone using Tapatalk Pro

[pythoncoder]

The clue is in the name: it's MicroPython bytecode which is frozen. The way I believe it works is that, on the PC, the MicroPython source is cross-compiled to bytecode. The bytecode for all frozen modules is then converted to data tables in C source (frozen_mpy.c) which is then compiled into the build. This process precludes native code emitters and inline assembler.

The frozen_mpy.c file (in the build directory for your port) is worth a look if you're interested.

[kevinkk525]

ok so if I use frozen modules, I can't benefit from the native emitter because only the internal compiler of micropython can do that?

[pythoncoder]

The way I deal with this is to partition the application into modules which can be frozen with a few, usually small, modules which can't. As you probably know, optimisation is best directed at the usually small number of functions which are performance critical.

[jickster]

ok so if I use frozen modules, I can't benefit from the native emitter because only the internal compiler of micropython can do that?

This isn’t a permanent restriction: if different emitters can run in C on the target there’s nothing stopping same code from running on PC.

It just hasn’t been implemented.


Sent from my iPhone using Tapatalk Pro

[jickster]

This process precludes native code emitters and inline assembler.
.

If C code on the target can use native emitters there’s no reason why same C code can run on PC.

It simply hasn’t been implemented.


Sent from my iPhone using Tapatalk Pro

[pythoncoder]

As I see it the limitation is in the cross-compiler which produces only bytecode. A modification to enable it to produce a mixture of bytecode and (correctly linked) native code would, I suspect, be nontrivial. It would also mean that the cross-compiler would need target-specific options (bytecode is generic). The build process would then need to convert the bytecode to C data. I'm not sure how it would handle and correctly link bunches of machine code. Perhaps the CC would need to emit assembler source, which could be assembled and linked?

All this is way above my pay grade

In practical applications I think there is little need: optimisation is best targeted at small amounts of code. The frozen bytecode option works well for the large modules. I've written some fairly hefty applications for the Pyboard and never found this to be a practical problem.

[kevinkk525]

Hmm sounds rather complicated. Doubt that anyone would want to put that effort into the cross-compiler just to get some more performance.
Thanks for you answers!