Skip to content

Add MicroPython cross compiler: mpycross #1839

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Feb 25, 2016

Conversation

dpgeorge
Copy link
Member

This is my latest attempt at a proper MicroPython cross compiler. It is now fully dynamically configurable so we only need one cross compiler binary (this one) to target all MicroPython runtimes (regardless of the host or target compile-time configurations).

The PR is split into 2 major parts: first, support for some dynamic configuration variables is added to py/ core (see mp_dynamic_compiler_t structure in py/mpstate.h); second, it includes the cross compiler itself, in a new top-lever directory mpycross. (There are also 2 other commits to enable loading of persistent bytecode in unix and stmhal ports, so that .mpy files can actually be used.)

Note: this PR supersedes #1619, and should also be considered and merged before #1811.

The way to specify options to the cross compiler is using -mxxx flags, eg:

$ ./mpycross -mno-unicode -msmall-int-bits=31 foo.py -o foo.mpy

The default settings target pyboard, cc3200 and esp8266.

The main thing to discuss is the name of the new top-level directory and the name of the cross compiler executable. I opted to have both the same, being "mpycross". Thoughts on this or other things most welcome!

@dpgeorge
Copy link
Member Author

Any comments on this? In particular, is mpycross a good name for the uPy cross compiler binary?

@danicampora
Copy link
Member

I like the name :-)

On Thu, Feb 18, 2016 at 3:18 PM, Damien George notifications@github.com
wrote:

Any comments on this? In particular, is mpycross a good name for the uPy
cross compiler binary?


Reply to this email directly or view it on GitHub
#1839 (comment)
.

@pfalcon
Copy link
Contributor

pfalcon commented Feb 18, 2016

In particular, is mpycross a good name for the uPy cross compiler binary?

Well, micropython-cross would be natural name, but too long. Then staying with the same initial letter is good idea, so "mpycross" is better than "upycross". So, yeah, name is good enough.

@dpgeorge
Copy link
Member Author

There will also be mpytool.py for working with .mpy files. I hope it's no too confusing having so many "mpy"'s :) Maybe the unix binary can be renamed/symlinked to "mpy" as well :)

@pfalcon
Copy link
Contributor

pfalcon commented Feb 18, 2016

Nope, having a common prefix is good idea, and luckily "mpy" prefix isn't even taken, based on pretty well-populated linux system, so sounds good.

@dpgeorge
Copy link
Member Author

Maybe mpy_ is a solution after all for #704?

@pfalcon
Copy link
Contributor

pfalcon commented Feb 18, 2016

well, for executable prefixes, I'd prefer hyphen, "mpy-". I don't know if having such separator is useful too much, but perhaps commands will look more distinctive with it.

@dhylands
Copy link
Contributor

I also prefer hypens over underscores (and get annoyed when I have to use undescores in the names of my .py files that have to be imported - but that's life).

I lilke mpy-cross better than mpycross (it reads better when looking at Makefiles etc).

@dpgeorge
Copy link
Member Author

For files, we use underscore a lot, and hyphen as well. I'm happy with mpy-cross instead of mpycross (and also mpy-tool.py).

For prefixes within the C code, mpy_ could be used instead of mp_.

@pfalcon
Copy link
Contributor

pfalcon commented Feb 18, 2016

With that clarification, yes, makes sense, but you aren't going to change C prefixes with additions to this patch, right? ;-)

@dpgeorge
Copy link
Member Author

With that clarification, yes, makes sense, but you aren't going to change C prefixes with additions to this patch, right? ;-)

No, of course :)

Ok, to be clear, it was just a side note that mpy_ could be used as a prefix for C functions, as per discussion in #704. And that would be consistent with using mpy as the prefix of the binary executable name for the cross compiler.

If we want a separator in the executable name then hyphen is preferred over underscore.

Then it comes down to whether to use a separator or not for the command-line executables. I.e. mpy-cross and mpy-tool.py, or mpycross and mpytool.py. Personally I have a weak preference for the non-hyphenated versions, they are shorter and simpler to type.

This new compile-time option allows to make the bytecode compiler
configurable at runtime by setting the fields in the mp_dynamic_compiler
structure.  By using this feature, the compiler can generate bytecode
that targets any MicroPython runtime/VM, regardless of the host and
target compile-time settings.

Options so far that fall under this dynamic setting are:
- maximum number of bits that a small int can hold;
- whether caching of lookups is used in the bytecode;
- whether to use unicode strings or not (lexer behaviour differs, and
  therefore generated string constants differ).
This component allows to generate .mpy files (pre compiled bytecode)
which can be executed within any MicroPython runtime/VM.
@dpgeorge dpgeorge merged commit ac23662 into micropython:master Feb 25, 2016
@dpgeorge dpgeorge deleted the mpycross branch March 8, 2016 16:00
tannewt added a commit to tannewt/circuitpython that referenced this pull request May 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants