Leaning Technologies

This is awesome! Thanks for providing more details (was a bit hard to notice your medium post at first) [0].

For folks here interested in doing this kind of thing (one example is for building web-available IDEs) the other way to run languages in the browser is to find implementations of the language in JavaScript like Brython for Python and there are a few Schemes that come to mind. I wrote a bit about this here [1]. Some people have taken this even further [2, 3] than I did.

And specifically both this OP post and all the links I'm talking about work differently than repl.it does because repl.it has a server where your code runs. Everything I'm talking about runs solely in your browser. Which makes compute free, with a bunch of limitations (io, basically).

[0] https://medium.com/leaningtech/cheerpx-using-webassembly-to-run-any-programming-language-in-the-browser-3306e1b68f06

[1] https://datastation.multiprocess.io/blog/2021-06-16-languages-you-can-run-in-the-browser.html

[2] https://github.com/fiugd/plugins/tree/main/.templates

[3] https://github.com/viebel/klipse

Yes, I should write about v86's internals some day. Meanwhile, the code is right here: https://github.com/copy/v86/tree/master/src/rust

It's much faster with recompilation than without, but I agree that it's slower than expected (compared to, for example, qemu-tcg).

There is still room for improvements (e.g. eflags updates, 16-bit instructions, call/ret optimisations, main loop), but part of the problem is limitations of web assembly (no mmap, only structured control flow) and browser engines (memory blow up on large generated wasm modules, related to control flow).

The webvm folks explain the control flow problem quite well, and seem to be doing a better job than v86: https://medium.com/leaningtech/extreme-webassembly-1-pushing-browsers-to-their-absolute-limits-56a393435323

The article mentions WebAssembly as having the same issue as spir-v with structured control flow, but actually in Wasm it is quite a bit better, because you are allowed to break/continue from an arbitrarily nested block.

This allows you to convert any reducible CFG without losing runtime performance, and only pay a price for irreducible ones (which are somewhat rare).

Shameless plug: I wrote an article about solving the structured control flow problem in WebAssembly -> https://medium.com/leaningtech/solving-the-structured-control-flow-problem-once-and-for-all-5123117b1ee2

> To use CheerpX for Flash, a licence is required for both CheerpX itself, and for distributing the Adobe Flash Player. This is a requirement for both self-hosted and cloud-hosted installations. In many cases, we will be able to offer both licences under the same commercial agreement. In some cases, a separate licence will need to be procured from Harman. Leaning Technologies can make the right introductions and facilitate the conversation with Harman.

https://medium.com/leaningtech/cheerpx-for-flash-now-generally-available-a20bc2a5eea6

One issue with Wasm is you essentially can't target it with a single-pass compiler, unlike just about any real machine. Wasm can only represent reducible control flow, so you have to pass your control-flow graph through some variation of the Relooper[1,2]. I don't know if upstream tcc can do that (there are apparently some forks?..).

[1] http://troubles.md/why-do-we-need-the-relooper-algorithm-again/

[2] https://medium.com/leaningtech/solving-the-structured-control-flow-problem-once-and-for-all-5123117b1ee2