And as a note, with this changes, uPy self-hosts unix versions of mandel.py and conwaylife.py (which was the motivation for starting to look into these changes).

It is neat. Still need to implement __bool__ for custom defined classes writting in Python.

Don't know what you mean by self hosts... mandel.py and conwaylife.py always worked with unix/micropython.

It is neat. Still need to implement bool for custom defined classes writting in Python.

Yes, as bunch of other methods - __str__, __repr__, etc. All these would follow same pattern as binary_ops you implemented - to use a "trampoline" code which will translate virtual method call into look up by name. Oh, there's __del__ too ;-). You don't think that stm would need support for such finalization? (My wild guess based on lack of such virtual method so far.)

Don't know what you mean by self hosts... mandel.py and conwaylife.py always worked with unix/micropython.

Not for me. It didn't work when I submitted patch for them (and lot of list stuff was missing then), and this time it failed on some ops for long ints, in particular, in true check (I was a bit surprised that rnd() implementation pushes numbers into long int, but that's it).

Probably need __del__. But with a GC, it would need to be explicitly called.

Examples all work for me on my 32 bit machine, and 64 bits. Do they work for you now?

Do they work for you now?

Yes, both mandel and conwaylife work for me. I tried to time conwaylife with uPy and CPy3.3, and uPy with just by a slightest edge. But that's not informative, because most time is spent in screen output. We'll need to think about better benchmark.

Probably need del.

FFI module shows that already need ;-).

But with a GC, it would need to be explicitly called.

What about calling it at sweep stage? (Yes, sure, that makes GC all suddenly much slow, so as an option; also, intuitively, one could try to "optimize" GC implementation by splitting 2-bit flags into two 1-bit vectors (or interleaving words); unclear how much that will actually improve).

We'll need to think about better benchmark.

I just found that -O3 was not being applied to vm.c or gc.c. It now is, and uPy should be 20% faster than it has been for the last week.

What about calling it at sweep stage?

Don't think that's possible. The GC heap can contain non-uPy objects and you can't tell what's an object and what's not... Would need to split it into 2 heaps to support sweep calling del.

The GC heap can contain non-uPy objects and you can't tell what's an object and what's not...

Ah right...

Would need to split it into 2 heaps

Or force type header on all allocations to make it precise, or have impl without conservative guarantees, which may segfault once in a while ;-).

Actually, a type header, 1 bit, would be a nice addition. 2 types: either data, or a uPy object with a mp_obj_base_t as the first word, which can point to a deconstructor.