1. 27 Sep, 2016 1 commit
    • Damien George's avatar
      py: Only store the exception instance on Py stack in bytecode try block. · f040685b
      Damien George authored
      When an exception is raised and is to be handled by the VM, it is stored
      on the Python value stack so the bytecode can access it.  CPython stores
      3 objects on the stack for each exception: exc type, exc instance and
      traceback.  uPy followed this approach, but it turns out not to be
      necessary.  Instead, it is enough to store just the exception instance on
      the Python value stack.  The only place where the 3 values are needed
      explicitly is for the __exit__ handler of a with-statement context, but
      for these cases the 3 values can be extracted from the single exception
      This patch removes the need to store 3 values on the stack, and instead
      just stores the exception instance.
      Code size is reduced by about 50-100 bytes, the compiler and VM are
      slightly simpler, generate bytecode is smaller (by 2 bytes for each try
      block), and the Python value stack is reduced in size for functions that
      handle exceptions.
  2. 19 Sep, 2016 1 commit
  3. 26 Aug, 2016 1 commit
  4. 20 May, 2016 1 commit
  5. 13 Apr, 2016 2 commits
  6. 07 Apr, 2016 2 commits
  7. 16 Mar, 2016 1 commit
  8. 25 Feb, 2016 1 commit
    • Damien George's avatar
      py: Add MICROPY_DYNAMIC_COMPILER option to config compiler at runtime. · ea235204
      Damien George authored
      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).
  9. 27 Jan, 2016 1 commit
  10. 07 Jan, 2016 1 commit
    • Damien George's avatar
      py/parse: Optimise away parse node that's just parenthesis around expr. · 93b37262
      Damien George authored
      Before this patch, (x+y)*z would be parsed to a tree that contained a
      redundant identity parse node corresponding to the parenthesis.  With
      this patch such nodes are optimised away, which reduces memory
      requirements for expressions with parenthesis, and simplifies the
      compiler because it doesn't need to handle this identity case.
      A parenthesis parse node is still needed for tuples.
  11. 18 Dec, 2015 2 commits
  12. 17 Dec, 2015 1 commit
  13. 12 Dec, 2015 1 commit
  14. 08 Dec, 2015 1 commit
  15. 29 Nov, 2015 2 commits
  16. 23 Nov, 2015 1 commit
  17. 20 Nov, 2015 1 commit
  18. 17 Nov, 2015 2 commits
  19. 13 Nov, 2015 1 commit
  20. 14 Oct, 2015 1 commit
  21. 12 Oct, 2015 1 commit
    • Damien George's avatar
      py: Move constant folding from compiler to parser. · 64f2b213
      Damien George authored
      It makes much more sense to do constant folding in the parser while the
      parse tree is being built.  This eliminates the need to create parse
      nodes that will just be folded away.  The code is slightly simpler and a
      bit smaller as well.
      Constant folding now has a configuration option,
      MICROPY_COMP_CONST_FOLDING, which is enabled by default.
  22. 08 Oct, 2015 2 commits
  23. 03 Oct, 2015 1 commit
  24. 01 Oct, 2015 2 commits
  25. 24 Sep, 2015 1 commit
  26. 23 Sep, 2015 2 commits
  27. 07 Sep, 2015 1 commit
  28. 04 Sep, 2015 1 commit
  29. 17 Aug, 2015 2 commits
    • Damien George's avatar
    • Damien George's avatar
      unix-cpy: Remove unix-cpy. It's no longer needed. · 65dc960e
      Damien George authored
      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.
  30. 29 Jul, 2015 1 commit
    • Damien George's avatar
      py/compile: Give more precise line number for compile errors. · cfc4c338
      Damien George authored
      Previous to this patch there were some cases where line numbers for
      errors were 0 (unknown).  Now the compiler attempts to give a better
      line number where possible, in some cases giving the line number of the
      closest statement, and other cases the line number of the inner-most
      scope of the error (eg the line number of the start of the function).
      This helps to give good (and sometimes exact) line numbers for
      ViperTypeError exceptions.
      This patch also makes sure that the first compile error (eg SyntaxError)
      that is encountered is reported (previously it was the last one that was
  31. 27 Jul, 2015 1 commit