1. 29 Sep, 2018 1 commit
    • Damien George's avatar
      py/vm: When VM raises exception put exc obj at beginning of func state. · d95947b4
      Damien George authored
      Instead of at end of state, n_state - 1.  It was originally (way back in
      v1.0) put at the end of the state because the VM didn't have a pointer to
      the start.  But now that the VM takes a mp_code_state_t pointer it does
      have a pointer to the start of the state so can put the exception object
      there.
      
      This commit saves about 30 bytes of code on all architectures, and, more
      importantly, reduces C-stack usage by a couple of words (8 bytes on Thumb2
      and 16 bytes on x86-64) for every (non-generator) call of a bytecode
      function because fun_bc_call no longer needs to remember the n_state
      variable.
      d95947b4
  2. 28 Sep, 2018 5 commits
    • Damien George's avatar
      py/objtype: Support full object model for get/set/delitem special meths. · dd288904
      Damien George authored
      This makes these special methods have the same calling behaviour as other
      methods in a class instance (mp_convert_member_lookup() is already called
      by mp_obj_class_lookup()).
      dd288904
    • Damien George's avatar
      py/objtype: Remove TODO about storing attributes to classes. · 2eb01701
      Damien George authored
      This behaviour is tested in basics/class_store.py and follows CPython.
      2eb01701
    • Damien George's avatar
      py/runtime: Remove nlr protection when calling __next__ in mp_resume. · 2c7a3061
      Damien George authored
      And remove related comment about needing such protection when calling send.
      
      Reasoning for removal is as follows:
      - mp_resume is only called by the VM in YIELD_FROM opcode
      - if send_value != MP_OBJ_NULL then throw_value == MP_OBJ_NULL
      - so if __next__ or send are called then throw_value == MP_OBJ_NULL
      - if __next__ or send raise an exception without nlr protection then the
        exception will be handled by the global exception handler of the VM
      - this handler already has code to handle exceptions raised in YIELD_FROM,
        including correct handling of StopIteration
      - this handler doesn't handle the case of injection of GeneratorExit, but
        this won't be needed because throw_value == MP_OBJ_NULL
      
      Note that it's already possible for mp_resume() to raise an exception
      (including StopIteration) from the unprotected call to type->iternext(), so
      that's why the VM already has code to handle the case of exceptions coming
      out of mp_resume().
      
      This commit reduces code size by a bit, and significantly reduces C stack
      usage when using yield-from, from 88 bytes down to 40 for Thumb2, and 152
      down to 72 bytes for x86-64 (better than half).  (Note that gcc doesn't
      seem to tail-call optimise the call from mp_resume() to mp_obj_gen_resume()
      so this saving in C stack usage helps all uses of yield-from.)
      2c7a3061
    • Damien George's avatar
      py/vm: Fix case of throwing GeneratorExit type into yield-from. · 0c9d4523
      Damien George authored
      mp_make_raise_obj must be used to convert a possible exception type to an
      instance object, otherwise the VM may raise a non-exception object.
      
      An existing test is adjusted to test this case, with the original test
      already moved to generator_throw.py.
      0c9d4523
    • Damien George's avatar
  3. 27 Sep, 2018 17 commits
  4. 26 Sep, 2018 9 commits
  5. 24 Sep, 2018 7 commits
  6. 21 Sep, 2018 1 commit