Skip to content
Snippets Groups Projects
  • Damien George's avatar
    1396a026
    py: Add support to save native, viper and asm code to .mpy files. · 1396a026
    Damien George authored
    This commit adds support for saving and loading .mpy files that contain
    native code (native, viper and inline-asm).  A lot of the ground work was
    already done for this in the form of removing pointers from generated
    native code.  The changes here are mainly to link in qstr values to the
    native code, and change the format of .mpy files to contain native code
    blocks (possibly mixed with bytecode).
    
    A top-level summary:
    
    - @micropython.native, @micropython.viper and @micropython.asm_thumb/
      asm_xtensa are now allowed in .py files when compiling to .mpy, and they
      work transparently to the user.
    
    - Entire .py files can be compiled to native via mpy-cross -X emit=native
      and for the most part the generated .mpy files should work the same as
      their bytecode version.
    
    - The .mpy file format is changed to 1) specify in the header if the file
      contains native code and if so the architecture (eg x86, ARMV7M, Xtensa);
      2) for each function block the kind of code is specified (bytecode,
      native, viper, asm).
    
    - When native code is loaded from a .mpy file the native code must be
      modified (in place) to link qstr values in, just like bytecode (see
      py/persistentcode.c:arch_link_qstr() function).
    
    In addition, this now defines a public, native ABI for dynamically loadable
    native code generated by other languages, like C.
    1396a026
    History
    py: Add support to save native, viper and asm code to .mpy files.
    Damien George authored
    This commit adds support for saving and loading .mpy files that contain
    native code (native, viper and inline-asm).  A lot of the ground work was
    already done for this in the form of removing pointers from generated
    native code.  The changes here are mainly to link in qstr values to the
    native code, and change the format of .mpy files to contain native code
    blocks (possibly mixed with bytecode).
    
    A top-level summary:
    
    - @micropython.native, @micropython.viper and @micropython.asm_thumb/
      asm_xtensa are now allowed in .py files when compiling to .mpy, and they
      work transparently to the user.
    
    - Entire .py files can be compiled to native via mpy-cross -X emit=native
      and for the most part the generated .mpy files should work the same as
      their bytecode version.
    
    - The .mpy file format is changed to 1) specify in the header if the file
      contains native code and if so the architecture (eg x86, ARMV7M, Xtensa);
      2) for each function block the kind of code is specified (bytecode,
      native, viper, asm).
    
    - When native code is loaded from a .mpy file the native code must be
      modified (in place) to link qstr values in, just like bytecode (see
      py/persistentcode.c:arch_link_qstr() function).
    
    In addition, this now defines a public, native ABI for dynamically loadable
    native code generated by other languages, like C.