Leaning Technologies
medium.com/leaningtech · Company blog · on HN since 2018
Leaning Technologies' engineering team writes about CheerpX, CheerpJ and compiling Java, C++ and Flash to WebAssembly and JavaScript.
What HN saysHN commenters cite it for explaining Wasm's structured control flow problem and the Stackifier algorithm as an alternative to Relooper, though one asks if it explains the problem well.
23HN people shared it
13linked it in comments
37stories submitted
220story points
2 years agolast shared
2018people per year2026
Most-shared posts
- 1Solving the structured control flow problem once and for all6 people · 12 points · first shared 2019 · 1 comments on HN
- 2Running Flash in WebAssembly using CheerpX: an update4 people · 12 points · first shared 2020 · discussion on HN
- 3Preserving Flash with WebAssembly the right way: without re-implementing it3 people · 28 points · first shared 2019 · 1 comments on HN
- 4CheerpX: Using WebAssembly to run any programming language in the browser3 people · 14 points · first shared 2021 · 1 comments on HN
- 5A JavaScript Optimizing Compiler3 people · 10 points · first shared 2021 · 1 comments on HN
- 6CheerpX for Flash now generally available3 people · 3 points · first shared 2020 · discussion on HN
- 7Extreme WebAssembly 1: pushing browsers to their absolute limits2 people · 16 points · first shared 2020 · 1 comments on HN
- 8CheerpJ 2.0: Run Any Java in the Browser by Compiling to JavaScript and Wasm2 people · 11 points · first shared 2020 · discussion on HN
- 9Show HN: Porting a C++ Multiplayer Game to the Web with Cheerp, WebRTC, Firebase2 people · 8 points · first shared 2019 · 1 comments on HN
- 10PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM2 people · 2 points · first shared 2022 · discussion on HN
- 11WebVM: Server-less x86 virtual machines in the browser1 people · 12 points · first shared 2022 · 2 comments on HN
- 12Show HN: CheerpJ 1.3 – Compile any Java application to JS/HTML51 people · 10 points · first shared 2018 · discussion on HN
- 13CheerpJ 2.1 released – Java bytecode to WebAssembly and JavaScript1 people · 9 points · first shared 2020 · discussion on HN
- 14Adding anyref support in a C++ to WebAssembly compiler1 people · 9 points · first shared 2020 · discussion on HN
- 15Extreme WebAssembly 2: the sad state of WebAssembly tail calls1 people · 8 points · first shared 2020 · discussion on HN
What HN people wrote when they linked it
mananaysiempre · 2024-10-07
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-pro…
g3 · 2022-11-01
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-…
yuri91 · 2022-05-24
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-pro…
shadowofneptune · 2022-04-20
I had some trouble understanding the problem, since I've never had to translate a program that relies on goto into a purely structured one. Does this article cover it well? https://medium.com/leaningtech/solving-the-structured-control-flow-pro…
JoelJacobson · 2022-02-02
https://github.com/immunant/c2rust:
> We rely on Emscripten's Relooper algorithm to translate arbitrary C control flows.
Article on why Relooper isn't good enough and the superior Stackifier algorithm, which they probably should be using instead:
https://medium.com/leaningtech/solving-the-structured-control-flow-pro…
apignotti · 2021-11-22
Any disk block which is used or modified is stored locally into an IndexedDB instance. You can find more info in the accompanying blog post: https://medium.com/leaningtech/cheerpx-using-webassembly-to-run-any-pr… ("Data Storage" section)
q3k · 2020-11-29
> 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-availab…
askjdlkasdjsd · 2020-06-16
Welcome news!
This guy is trying to emulate x86 in the browser and run the actual Flash player within that:
https://medium.com/leaningtech/running-flash-in-webassembly-using-chee…
jakogut · 2020-06-15
Not necessarily, WebAssembly is a potential viable host for implementing/emulating Flash. See here: https://medium.com/leaningtech/preserving-flash-content-with-webassemb…
triangleman · 2020-06-15
This guy is trying to emulate x86 in the browser and run the actual Flash player within that:
https://medium.com/leaningtech/running-flash-in-webassembly-using-chee…
core-questions · 2020-05-25
> We really need a better medium than the current WWW for this kind of archival, because the researchers are going to retire or die, and then they will probably stop updating their pages, which will then apparently become inaccessible with modern browsers.
I predict at some point we'll end up with a project that does Flash-on-WASM to keep Flash usable.
https://medium.com/leaningtech/preserving-flash-content-with-webassemb…
pjmlp · 2020-03-12
Nah, CheerpX is also an option.
https://medium.com/leaningtech/running-flash-in-webassembly-using-chee…
eatonphil · 2021-11-22
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-pr…
[1] https://datastation.multiprocess.io/blog/2021-06-16-languages-you-can-…
[2] https://github.com/fiugd/plugins/tree/main/.templates
[3] https://github.com/viebel/klipse