CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=6.0.x 2015-08-17T11:51:26+00:00 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-05-06T15:46:21+00:00 Damien George damien.p.george@gmail.com 2015-05-06T15:46:21+00:00 urn:sha1:57ebe1b27d6ae10584d3b5f767e3cc5aa481c0b0 Also remove __debug__ from one of the bytecode tests. 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. 2015-02-28T15:04:06+00:00 Damien George damien.p.george@gmail.com 2015-02-28T15:04:06+00:00 urn:sha1:63f3832e813442dcfc88be65d78ce465b053a33b Saves 116 bytes for stmhal and 56 bytes for cc3200 port. 2015-02-08T01:57:40+00:00 Damien George damien.p.george@gmail.com 2015-02-08T01:57:40+00:00 urn:sha1:7d414a1b52d193bab2c94cf56932e1eba23ba542 Previous to this patch, a big-int, float or imag constant was interned (made into a qstr) and then parsed at runtime to create an object each time it was needed. This is wasteful in RAM and not efficient. Now, these constants are parsed straight away in the parser and turned into objects. This allows constants with large numbers of digits (so addresses issue #1103) and takes us a step closer to #722. 2015-01-28T23:43:01+00:00 Damien George damien.p.george@gmail.com 2015-01-28T23:43:01+00:00 urn:sha1:0d3cb6726ddc1bab9fdd11a0aaa259fb436da4b2 This cleans up vstr so that it's a pure "variable buffer", and the user can decide whether they need to add a terminating null byte. In most places where vstr is used, the vstr did not need to be null terminated and so this patch saves code size, a tiny bit of RAM, and makes vstr usage more efficient. When null termination is needed it must be done explicitly using vstr_null_terminate. 2015-01-16T12:24:49+00:00 Damien George damien.p.george@gmail.com 2015-01-16T12:24:49+00:00 urn:sha1:0abb5609b01c1b59d229bde8a0b3fc1df6dce060 Saves 24 bytes in bare-arm. 2015-01-13T15:55:54+00:00 Damien George damien.p.george@gmail.com 2015-01-13T15:55:54+00:00 urn:sha1:dab1385177558f1d27c03b59e443b6fa25a2cdc0 This allows to directly load a Python object to the Python stack. See issue #722 for background.