TODO: Decide if we really need separate bytecode for creating functions
with default arguments - we would need same for closures, then there're
keywords arguments too. Having all combinations is a small exponential
explosion, likely we need just 2 cases - simplest (no defaults, no kw),
and full - defaults & kw.
__bool__() and __len__() are just the same as __neg__() or __invert__(),
and require efficient dispatching implementation (not requiring search/lookup).
type->unary_op() is just the right choice for this short of adding
standalone virtual method(s) to already big mp_obj_type_t structure.
We still have FAST_[0,1,2] byte codes, but they now just access the
fastn array (before they had special local variables). It's now
simpler, a bit faster, and uses a bit less stack space (on STM at least,
which is most important).
The only reason now to keep FAST_[0,1,2] byte codes is for compressed
byte code size.
LOAD_METHOD bug was: emitbc did not correctly calculate the amount of
stack usage for a LOAD_METHOD operation.
small int bug was: int was being used to pass small ints, when it should
have been machine_int_t.
Damien George
Paul Sokolovsky
xbe
Markus Siemens