Thanks for the idea, but do you have any concrete plans or proof of concept that implements this? There is already some working code using Emscripten: #1561 and #2618 . And MicroPython does run in the browser using Unicorn: https://micropython.org/unicorn

Unicorn is very much not equivalent. It's an alright toy and for learning, but it's not something you'd use to make serious front-end code.

The emscripten port is a great start. But what is really needed is inline-assembler support. Once that exists, it's a lot easier to implement a stdlib.

So what would be involved in getting the inline assembler working on a new architecture? Presuming that the emscripten build can be modified to build to webassembly instead of asm.js, which it should.

@traverseda I'm still not sure what your aim is / needs are. If you want a fast Python interpreter in the browser then an Emscripten version of MicroPython would be the best way to go. What role does webassembly play, and what do you mean by "inline assembler support" in the browser? Probably this discussion is best had at https://forum.micropython.org

Alright, let's get into a bit of background here.

Asm.js is the current default target of emscripten. It's a subset of javascript that can be run really fast, and is somewhat equivalent to an assembly target. It's composed of statements like this

function add1(x) {
    x = x|0; // x : int
    return (x+1)|0;
}

Webassemly is another emscripten target, building on the success of asmjs. Instead of the statement like the above, it uses a binary format. This means it decodes much faster, and is smaller. Where startup time is really important on the web, that decoding time is important.

So let's take a look at a bit of assembly, written in their text format, for calling a javascript function.

simple.wasm
(module
  (func $i (import "imports" "i") (param i32))
  (func (export "e")
    i32.const 42
    call $i))

What I mean by "inline-assembly-support" is pretty much the same thing as is meant here.

If you've got a spare half-hour, you might appreciate the birth and death of javascript talk. I'll get an account on the forum.

@traverseda : Love the name of the talk and the site, but what do you want and wait for? Are you waiting for the proverbial "patches welcome"? Here it is: patches welcome. Are you waiting for something else? Keep waiting, but you may find that the forum mentioned above is a more comfortable place for waiting, simply because this is solely a bug tracker for the project.

I am not prepared to implement this, at least not without a fair amount of support. What I would have liked is to have seen that some people with knowledge of the project were interested in it.

Do you see where I said

So what would be involved in getting the inline assembler working on a new architecture?

That was one of the questions I'd need answered before I thought about implementing these features.

What I wanted from this ticket? Well I wanted to gauge whether it was something the community was interested in, and what options were available. If there was someone competent, who seemed interested, I would have discussed getting some crowd-funding, possibly building a UI-toolkit demo on top of brython. I think there are a lot of developers who'd pitch in some money for a viable python-on-browser option.

If the community seemed friendly, and willing to discuss it, I would have worked towards implementing it.

I initially discussed this in IRC.

I think the webassembly thing, and doing "inline web assembler", is a bit of a red herring. As you say "a viable Python-on-browser option" would be interesting to lots of people. But they key to that is getting a properly working Emscripten port of MicroPython, with some infrastructure and docs on how to use it, some example uses of web pages written in MicroPython, and starting a community around the use of it. Once that is done one can move on to optimising the thing, perhaps supporting Webassembly as a target for @micropython.native code generation. I don't think actual inline web-assembly (eg @micropython.asm_web) would be that useful because no one wants to write in webassembly directly, and there is a much easier option to write fast code if it's needed: just write in Javascript and provide bindings to interface this JS code with uPy code (this is how the C modules are written for fast things like the socket module).

Most of the people in the MicroPython community (including the main developers) are interested in microcontroller and embedded systems as targets, not the web, so that's why an Emscripten port is low priority. But that doesn't mean it's not interesting to target the web and by all means @traverseda, try to rally a few interested people around this idea and get something moving. I'd use the existing Emscripten code at #1561 and #2618 as a starting point.

I think "starting a community around the use of it" is going to be very difficult without a viable interpreter. It's one of those chicken-and-egg problems, you can't get any kind of business support for building anything without it being viable. Micropython, with the right marketing, would probably kickstart that community. Building a UI library? Well maybe.

My thoughts behind micropython.asm_web support is that it would mostly be used for writing interfaces to webassembly functionality, instead of writing it in C. Does that seem reasonable?

I think "starting a community around the use of it" is going to be very difficult without a viable interpreter.

So step 1 would be to get the Emscripten port fully working. Emscripten supports setjmp/longjmp so it's not impossible to do.

My thoughts behind micropython.asm_web support is that it would mostly be used for writing interfaces to webassembly functionality, instead of writing it in C. Does that seem reasonable?

It seems to me that you'd want to write Javascript to interface to the DOM functionality, and similarly use Javascript to write bindings from MicroPython to any webassembly functionality that you need. I think webassembly is a topic that would come up much later on, after all the other pieces are worked out.

FYI, I'm planning on having a look at doing the Emscripten/WebAssembly port at some point in time over the next month as part of work (Grok Learning).

@traverseda : Do you have a forum thread for this? Can you link it from here?

@timdawborn are you able to share any more about your plans? We (microbit-foundation) are still really interested in the idea of using MicroPython in the browser (for example in the python.microbit.org editor) for both simulation and testing of users's scripts, custom modules, and maybe even some testing of drivers. Do you plan to pickup where @matthewelse left off on #2618 or take a different path?

@timdawborn I can see what you guys are doing at Grok learning. combining Google's Blockly visual programming editor that produces Python and MicroPython in the browser. that's cool. I love Ed tech startups.
any updates?

Sorry for the lack of response. I've been pulled off working on this for the moment, but plan to get back to it later in the year; hopefully late this month.

I made a start at doing the Emscripten/WebAssembly port a couple of weeks ago and got it to a point where I could run basic things, but still crashed occasionally. It wasn't too difficult to get to that point. The fork is currently sitting in my personal namespace but will be moved into the Grok Learning namespace once I start working on it again later on. Sorry I can't give more of an update right at the moment...

@jaustin to give a bit more context, we were planning on doing this Emscripten/WebAssembly port for the purposes of a self-hosting Python interpreter in the browser that's not doing either transpiling to JavaScript or taking the Batavia approach.

@wesamco we currently use Micropython for our micro:bit courses, but this Emscripten/WebAssembly port was for another purpose. We were planning on getting the port going with a number of the standard Python libraries and add a DOM API Python library to facilitate game development (in the context of education, not real world games and the performance needed there) in Python in the browser. Currently, we have a whole lot of kids around the world learning Python but are unable to use it to write apps that are accessible on the web as the language of the web is JavaScript. Having such a self-hosted, efficient implementation of Python combined with a decent enough Python DOM API (which then other libraries could build on top of, of course), would hopefully allow all of these kids who have learnt Python to keep extending on what they've learnt by being able to write apps to share with one another online. There's also a non-zero possibility we can get some funding for such an open source project if it takes off.

@timdawborn any updates on this?

I had a quick try at compiling MicroPython with Emscripten this morning and it seemed very doable. And I have enough experience using Emscripten that I'm fairly sure I could put together a module for accessing the DOM from inside MicroPython. But I'd rather not replicate someone else's work.

Sorry, no. I got taken off this project for the moment as other fires needed fighting.

Is the work you've already done on this accessible somewhere?

@talljosh there's currently an open PR to get uPy working under Node via Emscripten: #3575 . Maybe you can try that out and give some feedback on it?

@dpgeorge Thanks for the pointer! There are so many threads and pull requests tangentially related to this that I didn't know which one to look at.

There are so many threads and pull requests tangentially related to this that I didn't know which one to look at.

Yes there are a few separate discussions and PRs, because there are different ideas how to do a Javascript port and different uses for it. #3575 is a complete working port to JS and it would be good if it could be the basis for further work, to concentrate the efforts and discussion on it.

I could put together a module for accessing the DOM from inside MicroPython

WebAssembly already support importing modules. It would just be a matter of register a Python module import that use that ones, if any. Both Python and Javascript are dynamic languages and in fact the WebAssembly imports are based on CommonJS that at the same time is based on Python imports, so it should be easy and would allow access to ALL the npm packages :-D rust targeted to WebAssembly already support that... :-)

Mozilla has compiled CPython and its NumPy and Pandas C extensions into WebAssembly in pyodide. Hints of the toolchain they use are in their README:

Make sure the prerequisites for emsdk are installed. Pyodide will build a custom, patched version of emsdk, so there is no need to build it yourself prior.

Additional build prerequisites are:

• A working native compiler toolchain, enough to build CPython.
• A native Python 3.7 to run the build scripts.
• PyYAML
• lessc to compile less to css.
• uglifyjs to minify Javascript builds.
• ccache (optional) recommended for much faster rebuilds.

@akaihola afaik pyodide does not have REPL

also for proper use of python in the browser, async loop must be handled at repl loop because any blocking IO will get the page killed.
so:
user exposed time functions must be rewritten to work with await instead, socket and file fetching from remote servers too.

from what i've got a few hours ago, micropython runs fine with wasm, if enough people want repl i'm ok to dig in and complete the bounty https://www.bountysource.com/issues/5037165-emscripten

cpython POC:
http://pmpp.pagesperso-orange.fr/python_em.html?https://wyz.fr/paste/27M/raw

A port of MicroPython to javascript was added in 7d675f3

@traverseda and an experimental WASM target is available here https://github.com/pmp-p/micropython-ports-wasm ( requires a checkout of micropython git first )

@traverseda there's also a possible WASI target based on no-nlr branch.

done : https://pmp-p.github.io/wasi/wapy.html
discuss: https://gitter.im/Wasm-Python/wapy#

Just wondering where this stands at the moment.

We have a use-case where we need to run Python from machine-agnostic binaries. This would be an implementation that uses the standard WASI API instead of Emscripten (which can only run in a browser). The idea being that you ship your Python code to run on anything anywhere with a WASI runtime.

There is some traction to do this in CPython now (Pyodide is Emscripten but now they and CPython are looking at WASI), but I think it makes more sense to have a portable, bundled MicroPython than CPython. It is by nature much more lightweight and portable.

Emscripten (which can only run in a browser).

no it can run outside browser too, the libc is just more complex and require Node.js, but wasix project is bridging the gap for wasi. so ultimately there will be few differences on the non-browser specifics parts.

We are specifically looking at WASI because it is much more aimed at non-browser use and more intuitive interface layers for non-browser use without as much hassle. We are attempting to run on everything from ARM M4 to mips to arm64 to x86. We are using WAMR.

@DaAwesomeP then please be very welcome on the gitter link above or official webassembly/python discord,

WaPy is a no-nlr branch stackless spinoff of micropython that was made for wasi. It actually run well on wasm3 and arm soc (32/64). it can also support single thread soft interrupt with sched_yield ( see https://github.com/pmp-p/wasmx ) which is probably faster than wasm stack switching proposal and 64bits timer return values.

upstream was offered and declined at the transition beetween emsdk/wasm -> wasi . History probably repeats itself ( stackless and CPython ) and i don't know of any actual python implementation that offers soft realtime, green threads and transpiling module to C ( like mypyc can do )

WebAssembly is generally supported now for several releases. So this issue can probably be closed, or converted to a discussion.

Yes, let's close this issue. Final comments:

• The revamped webassembly port now includes JavaScript proxying and full access to the DOM and everything on the JavaScript side. And it's been integrated into pyscript to build web apps on the client side in (Micro)Python.
• It still doesn't support "inline asm" or native WASM emitter, but that could potentially come in the future.
• As far as targetting WASI, see Exprimental WASI support for ports/unix #13676.