| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
There were several different spellings of MicroPython present in comments,
when there should be only one.
|
|
|
|
| |
Saves 50-100 bytes of code.
|
|
|
|
| |
Generates slightly smaller and more efficient code.
|
|
|
|
|
|
|
|
|
|
|
|
| |
MICROPY_ENABLE_COMPILER can be used to enable/disable the entire compiler,
which is useful when only loading of pre-compiled bytecode is supported.
It is enabled by default.
MICROPY_PY_BUILTINS_EVAL_EXEC controls support of eval and exec builtin
functions. By default they are only included if MICROPY_ENABLE_COMPILER
is enabled.
Disabling both options saves about 40k of code size on 32-bit x86.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unix-cpy was originally written to get semantic equivalent with CPython
without writing functional tests. When writing the initial
implementation of uPy it was a long way between lexer and functional
tests, so the half-way test was to make sure that the bytecode was
correct. The idea was that if the uPy bytecode matched CPython 1-1 then
uPy would be proper Python if the bytecodes acted correctly. And having
matching bytecode meant that it was less likely to miss some deep
subtlety in the Python semantics that would require an architectural
change later on.
But that is all history and it no longer makes sense to retain the
ability to output CPython bytecode, because:
1. It outputs CPython 3.3 compatible bytecode. CPython's bytecode
changes from version to version, and seems to have changed quite a bit
in 3.5. There's no point in changing the bytecode output to match
CPython anymore.
2. uPy and CPy do different optimisations to the bytecode which makes it
harder to match.
3. The bytecode tests are not run. They were never part of Travis and
are not run locally anymore.
4. The EMIT_CPYTHON option needs a lot of extra source code which adds
heaps of noise, especially in compile.c.
5. Now that there is an extensive test suite (which tests functionality)
there is no need to match the bytecode. Some very subtle behaviour is
tested with the test suite and passing these tests is a much better
way to stay Python-language compliant, rather than trying to match
CPy bytecode.
|
|
|
|
| |
Saves around 230 bytes on Thumb2 and 750 bytes on x86.
|
|
|
|
| |
Saves 24 bytes in bare-arm.
|
|
|
|
| |
Addresses issue #1022.
|
|
|
|
| |
Towards resolving issue #50.
|
|
|
|
|
|
| |
It defines types used by all other headers.
Fixes #691.
|
|
|
|
|
|
|
| |
Blanket wide to all .c and .h files. Some files originating from ST are
difficult to deal with (license wise) so it was left out of those.
Also merged modpyb.h, modos.h, modstm.h and modtime.h in stmhal/.
|
|\
| |
| | |
py: the entire `<unistd.h>` shouldn't be needed
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Attempt to address issue #386. unique_code_id's have been removed and
replaced with a pointer to the "raw code" information. This pointer is
stored in the actual byte code (aligned, so the GC can trace it), so
that raw code (ie byte code, native code and inline assembler) is kept
only for as long as it is needed. In memory it's now like a tree: the
outer module's byte code points directly to its children's raw code. So
when the outer code gets freed, if there are no remaining functions that
need the raw code, then the children's code gets freed as well.
This is pretty much like CPython does it, except that CPython stores
indexes in the byte code rather than machine pointers. These indices
index the per-function constant table in order to find the relevant
code.
|
|
|
|
|
| |
Needed to reinstate 2 delete opcodes, to specifically check that a local
is not deleted twice.
|
|
|
|
| |
Remove unnecessary includes. Add includes that improve portability.
|
| |
|
|
|
|
|
| |
Can now have null bytes in strings. Can define ROM qstrs per port using
qstrdefsport.h
|
|
|
|
|
|
|
|
|
|
| |
A big change. Micro Python objects are allocated as individual structs
with the first element being a pointer to the type information (which
is itself an object). This scheme follows CPython. Much more flexible,
not necessarily slower, uses same heap memory, and can allocate objects
statically.
Also change name prefix, from py_ to mp_ (mp for Micro Python).
|
| |
|
| |
|
| |
|
| |
|
|
|