Hacker News Reader

Comment by boricj | Hacker News Reader

Does WASM still have 64 KiB pages? I get why for desktops, but there are use-cases for running WASM on microcontrollers where that's either inconvenient or outright impossible.

The one in particular I have in mind would be to put WASM on graphical calculators, in order to have a more secure alternative to the ASM programs (it's possible nowadays to write in higher-level languages, but the term stuck) that could work across manufacturers. Mid-range has RAM on the order of 256 KiB, but a 32-bit core clocked at more than 200 MHz, so there's plenty of CPU throughput but not a lot of memory to work with.

Sadly, the closest thing there is for that is MicroPython. It's good for what it does, but its performance and capabilities are nowhere near native.

View on HN

https://github.com/WebAssembly/custom-page-sizes is a proposal championed by my colleague to add single byte granularity to Wasm page sizes, motivated by embedded systems and many other use cases where 64kb is excessive. It is implemented in wasmtime, and a Firefox implementation is in progress.

> Allow Wasm to better target resource-constrained embedded environments, including those with less than 64 KiB memory available.

If it has less than 64 kB of memory how is it going to run a WASM runtime anyway?

And even cheap microcontrollers tend to have more than 64 kB of memory these days. Doesn't not seem remotely worth the complexity.

> If it has less than 64 kB of memory how is it going to run a WASM runtime anyway?

There is WARDuino (https://github.com/TOPLLab/WARDuino and https://dl.acm.org/doi/10.1145/3357390.3361029).

A runtime that accepts Wasm modules that use a large fraction of the functionality, there is going to be a RAM requirement in the few KiB to few tens of KiB. There seems to be a branch or fork of Wasm3 for Arduino (https://github.com/wasm3/wasm3-arduino).

If you are willing to do, e.g. Wasm -> AVR AOT compilation, then the runtime can be quite small. That basically implies that compilation does not happen on device, but at deployment time.

It's not about the whole microcontroller having less than 64kB of memory - it's that each WASM module has a minimum memory size of 64kB, regardless of how much it actually requires. Also, if you need 65kB of memory, you now have to reserve 2 pages, meaning your app now needs 128kB of memory!

We're working on WASM for embedded over at atym.io if you're interested.

> in order to have a more secure alternative to the ASM programs

What security implications are there in graphical calculators in terms of assembler language?

Exam mode, or test mode. It's something that appeared about ten years ago, to ensure that a graphical calculator isn't loaded with cheats or has certain features enabled. The technical reason is that the RESET button no longer clears all of the calculator's memory (think Flash, not RAM) and proctors like to see a flashing LED that tells them everything's fine.

It's a flawed idea and has led to an arms race, where manufacturers lock down their models and jailbreaks break them open. Even NumWorks, who originally had a calculator that was completely unprotected and used to publish all of their source code on GitHub, had to give in and introduce a proprietary kernel and code signing, in order to stop custom firmwares and applications from accessing the LED and stop countries from outlawing their calculators.

Sad state of affairs. I had no idea this was a thing.

Indeed. I got bit by the programming bug writing utility programs in TI-BASIC on my TI-83. I would've had a very different life trajectory had I not been able to do that.

Are the cases tamper proof as well? Because it's not like it's hard to open up a calculator and connect the LED somewhere else..

Why WASM and not, like, java or something?

As in, Java ME?

Unless I'm mistaken, it's been on life support for the past 15 years. It's probably more heavyweight and firmware size/Flash usage is a concern. I don't think performance would be on par with WASM and there are use-cases where that really matters (ray tracing rendering for example). I'm also not sure there are many maintained, open-source implementations for it out there. I've also heard stories that it was quite a mess in practice because it was plagued by bugs and quirks specific to phone models, despite the fact that it was supposed to be a standard.

I'd gladly be proven wrong, but I don't think Java ME has a bright future. Unless you were thinking of something else?

I wasn't thinking of a particular implementation so much as a VM in the abstract. So Java ME failed (I don't know much about it)—but I just didn't even think performance would matter much for a graphing calculator with how cheap hardware is. Those things must be almost entirely profit margin these days. Do kids even use them any more for school?

Reply on news.ycombinator.com