CircuitPython - a Python implementation for teaching coding with microcontrollers https://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=0.8.4 2016-12-09T10:23:17+00:00 2016-12-09T10:23:17+00:00 Damien George damien.p.george@gmail.com 2016-12-09T10:23:17+00:00 urn:sha1:e920bab9768f71c7e22fcfc5af3e1c40f2db8eeb This patch moves some common code from the individual inline assemblers to the compiler, the code that calls the emit-glue to assign the machine code to the functions scope. 2016-12-09T09:54:54+00:00 Damien George damien.p.george@gmail.com 2016-12-09T09:54:54+00:00 urn:sha1:dd53b12193dca4800ab207170fcc883142dd0f22 These are generic methods that don't depend on the architecture and so can be handled directly by the compiler. 2016-12-09T06:07:38+00:00 Damien George damien.p.george@gmail.com 2016-12-09T06:03:33+00:00 urn:sha1:f76b1bfa9f59fcfa03837c6934ad51d2db3ff4a3 This patch adds the MICROPY_EMIT_INLINE_XTENSA option, which, when enabled, allows the @micropython.asm_xtensa decorator to be used. The following opcodes are currently supported (ax is a register, a0-a15): ret_n() callx0(ax) j(label) jx(ax) beqz(ax, label) bnez(ax, label) mov(ax, ay) movi(ax, imm) # imm can be full 32-bit, uses l32r if needed and_(ax, ay, az) or_(ax, ay, az) xor(ax, ay, az) add(ax, ay, az) sub(ax, ay, az) mull(ax, ay, az) l8ui(ax, ay, imm) l16ui(ax, ay, imm) l32i(ax, ay, imm) s8i(ax, ay, imm) s16i(ax, ay, imm) s32i(ax, ay, imm) l16si(ax, ay, imm) addi(ax, ay, imm) ball(ax, ay, label) bany(ax, ay, label) bbc(ax, ay, label) bbs(ax, ay, label) beq(ax, ay, label) bge(ax, ay, label) bgeu(ax, ay, label) blt(ax, ay, label) bnall(ax, ay, label) bne(ax, ay, label) bnone(ax, ay, label) Upon entry to the assembly function the registers a0, a12, a13, a14 are pushed to the stack and the stack pointer (a1) decreased by 16. Upon exit, these registers and the stack pointer are restored, and ret.n is executed to return to the caller (caller address is in a0). Note that the ABI for the Xtensa emitters is non-windowing. 2016-12-09T05:51:49+00:00 Damien George damien.p.george@gmail.com 2016-12-09T05:39:39+00:00 urn:sha1:8e5aced1fd4845b23b203d8d15f9b34b6b022ceb The config option MICROPY_EMIT_XTENSA can now be enabled to target the Xtensa architecture with @micropython.native and @micropython.viper decorators. 2016-12-09T02:28:25+00:00 Damien George damien.p.george@gmail.com 2016-12-09T02:28:25+00:00 urn:sha1:c2713592bc5dd2c9bcd9c306ec8c907c0125c8f7 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.