-
-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
Conversation
Any comments on this? In particular, is |
I like the name :-) On Thu, Feb 18, 2016 at 3:18 PM, Damien George notifications@github.com
|
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. |
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 :) |
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. |
Maybe |
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. |
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). |
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, |
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 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. |
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.
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:
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!