Hi @LeaNumworks, nice work with your simulator!

MicroPython assumes the stack is descending, which is not the case on emscripten.
We had trouble with garbage collection as explained in emscripten’s portability guidelines.

Myself and a colleague have also lately been working on an Emscripten port and came across these two issues as well. The first is easy to fix and we can provide a compile-time option in uPy to select the stack direction.

We could not fix the second issue yet, with the GC. We have a build of uPy that runs under node (eg node micropython.js <script.py>) and running this on the uPy test-suite leads to a fair few failures which are due to the GC not being able to trace root pointers. Even compiling with -O0 does not fix the issue. What was your approach to dealing with this problem?

Would you be interested in some PRs to get a working Emscripten build?

I'm definitely interested in having an Emscripten port, but the GC issue is a real show stopper at this point.

I agree that having a working GC is a priority.

We only really did three things:

• Fix the stack direction
• Get the root pointers in gc_collect using setjmp
• Compile uPy with -O0

We did not run the uPY test-suite on our port so we may indeed be missing something. That being said, it does a great job for our use-case and the few scripts we tried this on did not seem to be leaking memory.

@LeaNumworks Would you mind sharing your branch?

In case fixing the garbage collector properly is a huge headache, how about having a naive implementation of https://github.com/micropython/micropython/blob/master/py/gc.c for Emscripten port for now and migrating to WebAssembly/design#1079 in the future when it's ready?

@LeaNumworks Oh, I guess it's https://github.com/numworks/epsilon/tree/master/python nvm

Nice!

I had put a bounty on #888 (comment) to get something like this done. Not that $100 USD could possibly cover the costs, but is more about an incentive to get it rolling.

Thanks very much for your effort.

@LeaNumworks I'm trying to run uPy test suite with https://github.com/numworks/epsilon/tree/master/python , but looking at port/ , it looks like it has other dependencies like Ion. Is there an easy way to just run on desktop? I was thinking maybe I should use the default port/unix instead but I'm not that familiar with Micropython porting layer. Thanks.

nvm I took some time to read the source code and have a better understanding of the structure now. I'll ask if I have any further question thanks!

You can try @LeaNumworks 's stand-alone micropython here https://kkimdev.github.io/epsilon/index.html

repo: https://github.com/kkimdev/epsilon
I just stripped off non-micropython dependencies from https://github.com/numworks/epsilon/tree/master/python , it didn't require much work actually.

181 KB download / 665 KB unpacked !

This is nice!

A port to javascript was added in 7d675f3

@LeaNumworks I am currently working on running MicroPython for the micro:bit with emscripten and emterpretify. I have applied your GC fixes, i.e. the descending stack, using setjmp, and I know that optimisations are not applied. Despite this, the GC still sweeps what it shouldn't, specifically, the local code_state pointer in fun_bc_call appears to not be stored in the stack but stored somewhere in emterpreter's local javascript heaps.

Am I right in thinking that you also use emterpretify?
If so, is there any reason you can think of that this might happen for me but not for the Numworks simulator?
i.e. How do you handle emterpretify storing pointers in heaps?
Is that the same issue you are trying to prevent with -O0?

@geowor01 you may want to test with #4723 to see if it helps your case

Thanks @dpgeorge! That does appear to fix the problem.

This issue can probably be closed now? The JavaScript port mentioned above has been renamed to WebAssembly, and should be generally functional. Any problems with it should probably be handled in specific issues?

Appears resolved.