Making a budget Pascal compiler to WebAssembly
faizilham.github.io
faizilham.github.io
Thanks for sharing this.
First for an example of what is possible with WASM take a look at Figma, they have a custom vector graphics rendering engine built in C++ compiled to WASM and using WebGL. The performance is incredible for a web app.
WASM is going to take over much of the cloud server market as well. Initially at the “edge” and cloud functions (see CloudFlare workers). But it’s increasingly going to be the standard deployment target. Rust and C++ have first class support for it, over dynamic language such as Python will so be able to run under WASM very soon (Python is just about there).
It’s basically perfect for app plugins as it’s naturally sandboxed. More software will provide a WASM plugin architecture.
Take a look at WASI (https://wasi.dev/), they are working to standardise a system interface for outside the browser.
Finally I also think the embedded market is a possible target for it. Many of the places that currently run an embedded Java VM will potentially use a WASM system in the future.
> but elsewhere too
I noticed that there seem to be more "elsewhere" than "browser" applications of the technology. But we already have e.g. the Mono engine with a proven, standardized IL which already offers most of the WASM features planned for the "elsewhere" use case. The engine can be run with just an executable and a core library with less than 10MB on a myriad of architectures (see e.g. https://github.com/rochus-keller/Oberon/ for a lean application of it). So what is WASM expected to bring to the table for this use case we don't already have today?
> a custom vector graphics rendering engine built in C++ compiled to WASM
Might be a nice idea, but there are already vector graphics libraries with included JIT and GPU backends. So what's the core benefit of using WASM here as an intermediate layer?
> But it’s increasingly going to be the standard deployment target
Do you have evidence for this? It has a lot of powerful competition, e.g. Go or native Java.
> I also think the embedded market is a possible target for it
"Embedded" is a very broad term. The vast majority of true embedded systems will not be able to afford running a VM, or even using dynamic memory - I e.g. do all my STM32 projects still in a subset of plain C. All embedded systems suited for Linux have a broad choice of proven viable technologies, from C to Python; even Mono is a viable solution on such systems.
It's the latest iteration of Java Applets, Flash, Silverlight, PNaCL, ...
If something gets re-invented over and over again, there clearly is a niche to fill.
"Embedded" is a very broad term. The vast majority of true embedded systems will not be able to afford running a VM, or even using dynamic memory.
Note that since 2007, Blue Ray players are required to run a JVM to support the 'bonus view' feature. The number of devices beefy enough to run VMs has only grown since.
My question was about the "elsewhere" use case; I'm familiar with the original intention of WASM, and the technologies you mention are well covered by HTML5 and JS today.
> "The number of devices beefy enough to run VMs"
That's not the point. The point is that industry will rather use a cheep microcontroller still today if there is no justification for something more powerful, and these controllers cannot afford VMs or dynamic memory management. Of course there are always people running MicroPython or friends on MCUs, but this is a niche.
Browser vendors could have decided to choose the pure Javascript route (eg asm.js, SIMD.js), but for now have decided to throw their weight behind WASM instead: SIMD.js got canned in 2017, whereas SIMD support for WASM shipped in browsers last year.
Regarding your second point about embedded devices, I can easily imagine WASM being used in the class of devices targeted by Java ME[1]. I'll of course happily defer to people who actually know something about the topic: If you think there's no legitimate use case for WASM in that space, so be it.
[1] https://en.wikipedia.org/wiki/Connected_Limited_Device_Confi...
Thankfully WebAssembly + WebGL have brought them back, that is the only reason I appreciate WebAssembly (on the browser).
https://platform.uno/uno-platform-for-web-webassemby
https://leaningtech.com/cheerpx-for-flash/
Or Java applets
https://leaningtech.com/cheerpj/
Or Silverlight
Well, yeah, that is the thing. The idea and similar tech existed ever since P-Code for Pascal (and perhaps earlier) and of course the very popular - at the time at least - Java and its JVM, all of which predate Mono and IL and already had several open source implementations.
However just the tech isn't enough - in fact, if anything, the computing history shows that tech is rarely the winning factor in what gets accepted and becomes popular, it is largely social and political factors. In this case the "social" factor seems to be that this isn't just "more 'elsewhere' than 'browser' applications" but actually "'elsewhere' and 'browser' applications". The fact that browsers support WebAssembly natively (as opposed through some plugin like it was done for JVM/IL/Flash/etc - ie. similar tech) is a big social and political boost that it has. This is where the hype currently comes from.
(OS vendors can have their own little things but it doesn't matter because it will never be adopted outside the OS and will only ever be used to talk to the OS).
This changes with WASM because if languages want to run in the browser, they need to target WASM, and suddenly there's a new standard that can put as much pressure in the language implementations as the C standard. This is the second time this has happened in history and I'm quite hopeful WASM and WASI catch on since C is complete jank as a glue language (even if it's used by everyone).
It all comes down to popularity and politics.
WASM shares more ideas with CIL than the JVM, especially when we have a look at the WASM proposals in progress. CIL and Pascal P-Code in contrast to JVM support e.g. value objects which supports applications with less dynamic memory management; JVM requires a dynamic allocation for each fly speck and thus powerful compacting collectors to cope with it. In WASM the memory management strategy is up to the application.
> The fact that browsers support WebAssembly natively
I was referring to the "elsewhere" case, where WASM seems to flourish, not the browser. And the social factor is definitely important, but I'm more interested what WASM is supposed to deliver we don't already have on a technical level.
That level of difference doesn't matter. The point is that WASM is a portable and sandboxed target (like JVM) which is (or will be) faster, more secure (e.g. capability based security in WASI) and with more language support (strictly more when optional GC becomes a thing) and other differences are implementation details.
https://www.usenix.org/conference/usenixsecurity20/presentat...
"WebAssembly Troubles"
Though it is annoying that you can't find the 1.0 spec - you know, the one that actually works - in the site. You can find it[0] at W3C by clicking around the W3C links in the site, but there isn't a direct link. Also annoying that there isn't any downloadable form (the SingleFile extension on Firefox seems to work though).
WebAssembly defaults to having NO access to the hosts file system. This makes it safe to run ANYTHING inside a WebAssembly interpreter without risk of having it escape and ruin the host system.
As long as they don't get stupid and provide host file system access, I'll keep putting time into learning about it.