CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=v1.8.6 2016-09-19T02:23:31+00:00 2016-09-19T02:23:31+00:00 Damien George damien.p.george@gmail.com 2016-09-18T13:59:47+00:00 urn:sha1:a5624bf3818c573611b2b7bfc755e27de97f64e4 The 3 kinds of comprehensions are similar enough that merging their emit functions reduces code size. Decreases in code size in bytes are: bare-arm:24, minimal:96, unix(NDEBUG,x86-64):328, stmhal:80, esp8266:76. 2016-04-07T07:50:38+00:00 Damien George damien.p.george@gmail.com 2016-04-07T07:50:38+00:00 urn:sha1:ce8b4e87494a11f389de7629e82043d6fb70284e Because different emitters need to handle with-cleanup in different ways. 2016-01-27T14:27:10+00:00 Damien George damien.p.george@gmail.com 2016-01-15T15:20:43+00:00 urn:sha1:8f54c08691faa3dd859852d211230fd7d9791abd Supported return types are: object, bool, int, uint. For example: @micropython.asm_thumb def foo(r0, r1) -> uint: add(r0, r0, r1) 2015-11-29T14:25:04+00:00 Damien George damien.p.george@gmail.com 2015-11-27T12:41:25+00:00 urn:sha1:5d66b427e22b6db5c73b74a6e9ba057ac5a38893 2015-08-17T11:51:26+00:00 Damien George damien.p.george@gmail.com 2015-08-14T11:24:11+00:00 urn:sha1:65dc960e3b22a8426e369607e47c19b380ce30ea 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. 2015-06-25T14:42:13+00:00 Damien George damien.p.george@gmail.com 2015-06-25T14:42:13+00:00 urn:sha1:59fba2d6ea31c134c9c0b88dc73cd25b236f167c Previous to this patch each time a bytes object was referenced a new instance (with the same data) was created. With this patch a single bytes object is created in the compiler and is loaded directly at execute time as a true constant (similar to loading bignum and float objects). This saves on allocating RAM and means that bytes objects can now be used when the memory manager is locked (eg in interrupts). The MP_BC_LOAD_CONST_BYTES bytecode was removed as part of this. Generated bytecode is slightly larger due to storing a pointer to the bytes object instead of the qstr identifier. Code size is reduced by about 60 bytes on Thumb2 architectures. 2015-04-20T13:29:31+00:00 Damien George damien.p.george@gmail.com 2015-04-20T13:29:31+00:00 urn:sha1:c8b60f013b9d624a74ad502460f2bc7d00c39644 This fixes a long standing problem that viper code generation gave terrible error messages, and actually no errors on pyboard where assertions are disabled. Now all compile-time errors are raised as proper Python exceptions, and are of type ViperTypeError. Addresses issue #940. 2015-03-26T16:52:45+00:00 Damien George damien.p.george@gmail.com 2015-03-26T16:44:14+00:00 urn:sha1:4112590a602fa11b4d9a3df3ed5c55df56c0dc62 When just the bytecode emitter is needed there is no need to have a dynamic method table for the emitter back-end, and we can instead directly call the mp_emit_bc_XXX functions. This gives a significant reduction in code size and a very slight performance boost for the compiler. This patch saves 1160 bytes code on Thumb2 and 972 bytes on x86, when native emitters are disabled. Overall savings in code over the last 3 commits are: bare-arm: 1664 bytes. minimal: 2136 bytes. stmhal: 584 bytes (it has native emitter enabled). cc3200: 1736 bytes. 2015-03-26T16:52:45+00:00 Damien George damien.p.george@gmail.com 2015-03-26T15:49:53+00:00 urn:sha1:a210c774f9cfbcde284f5b8a63442b4d6da1ae5b First pass for the compiler is computing the scope (eg if an identifier is local or not) and originally had an entire table of methods dedicated to this, most of which did nothing. With changes from previous commit, this set of methods can be removed and the methods from the bytecode emitter used instead, with very little modification -- this is what is done in this commit. This factoring has little to no impact on the speed of the compiler (tested by compiling 3763 Python scripts and timing it). This factoring reduces code size by about 270-300 bytes on Thumb2 archs, and 400 bytes on x86. 2015-03-26T16:52:45+00:00 Damien George damien.p.george@gmail.com 2015-03-26T14:42:40+00:00 urn:sha1:542bd6b4a1ead90fde42f24d01c82580f9d048de Saves around 230 bytes on Thumb2 and 750 bytes on x86.