Portability of code compiled with mpy_cross

C programming, build, interpreter/VM.
Target audience: MicroPython Developers.
Post Reply
tomlogic
Posts: 13
Joined: Tue Jul 19, 2016 10:20 pm

Portability of code compiled with mpy_cross

Post by tomlogic » Mon Sep 12, 2016 10:30 pm

I want to confirm some assumptions I've made about the portability of code compiled with mpy_cross, based on my understanding of the QSTR interned strings:
  1. Compiled bytecode stores indices into the QSTR pool of the MicroPython build installed on the pyboard. This is why it's necessary to recompile MicroPython and flash it to the target device (per this thread).
  2. But, as long as two builds have identical bytecode generators and QSTR pools, a compiled MicroPython program should work on both.
  3. Therefore, if I modify my build to incorporate some new QSTR strings (changing QSTR pool indexing), I will need to recompile my .py files into new .mpy files.
  4. If I was sharing a compiled .mpy program with someone, I'd also need to share my MicroPython build for them to install on their hardware.

User avatar
pythoncoder
Posts: 3707
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Portability of code compiled with mpy_cross

Post by pythoncoder » Tue Sep 13, 2016 8:13 am

As I understand it you don't need to recompile the firmware on the Pyboard to run .mpy files. On other platforms you do, because you need to change compile time options.

You can save RAM by incorporating the strings defined in your code into the firmware build as QSTRs (this provisional doc describes a procedure http://hinch.me.uk/html/reference/constrained.html). This - inevitably - involves recompiling the firmware. To take advantage of the gain you'd surely need to cross compile the code otherwise the strings would be stored with the bytecode.

You'd then need to install the firmware build and copy the cross compiled code to other targets.
Peter Hinch

Post Reply