WASM 3.0 Completed • Hacker News Board

Re: WASM 3.0 Completed

#221

Post by nasso_dev » Wed, Sep 17, 2025, 10:28 PM UTC

colordrops wrote: post #202

vinkelhake wrote: post #187

Earlier quoted context omitted.

You can write a WASM program today that touches the DOM, it just needs to go through the regular JS APIs. While there were some discussions early on about making custom APIs for WASM to access, that has long since been dropped - there are just too many downsides.

Isn't going through the JS APIs slow?

used to be, in the early days, but nowadays runtimes optimized the function call overhead between WASM and JS to near zero

https://hacks.mozilla.org/2018/10/calls-between-javascript-a...

Re: WASM 3.0 Completed

#222

Post by cfallin » Wed, Sep 17, 2025, 10:30 PM UTC

re wrote: post #75

I haven't really been following WASM development in the last year and didn't realize that WASM had moved to a versioned release model. I've been aware of the various features in development[1] and had thought many of the newer features were going to remain optional but I guess now that implementations are expected to support all the features to be able to claim compatibility with e.g. "WASM 3.0"? It'll be interesting…

> It'll be interesting to see what the second non-browser-based WASM runtime to fully support 3.0 will be (I'm guessing wasmtime will be first; ...)

Wasmtime already supports every major feature in the Wasm 3.0 release, I believe. Of the big ones: garbage collection was implemented by my colleague Nick Fitzgerald a few years ago; tail calls by Jamey Sharp and Trevor Elliott last year (with full generality, any signature to any signature, no trampolines required!); and I built our exceptions support which merged last month and is about to go out in Wasmtime 37 in 3 days.

The "3.0" release of the Wasm spec is meant to show progress and provide a shorthand for a level of features, I think, but the individual proposals have been in progress for a long time so all the engine maintainers have known about them, given their feedback, and built their implementations for the most part already.

(Obligatory: I'm a core maintainer of Wasmtime and its compiler Cranelift)

Re: WASM 3.0 Completed

#223

Post by 05 » Wed, Sep 17, 2025, 10:32 PM UTC

gertop wrote: post #210

jjcm wrote: post #176

Earlier quoted context omitted.

I know you're in this for the satire, but it's less about the webapps needing the memory and more about the content - that's why I mentioned video editing webapps. For video editing, 4GiB of completely uncompressed 1080p video in memory is only 86 frames, or about 3-4 seconds of video. You can certainly optimize this, and it's rare to handle fully uncompressed video, but there are situations where you do need to buff…

> 4GiB of completely uncompressed 1080p video in memory is only 86 frames How is that data stored? Because (2^32)÷(1920×1080×4) = 518 which is still low but not 86 so I'm curious what I'm missing?

Apparently with 24 bytes per pixel instead of bits :) Although to be fair, there's HDR+ and DV, so probably 4(RGBA/YUVA) floats per pixel, which is pretty close..

Re: WASM 3.0 Completed

#224

Post by 05 » Wed, Sep 17, 2025, 10:38 PM UTC

boricj wrote: post #73

MisterTea wrote: post #57

Earlier quoted context omitted.

> 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 man…

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..

Re: WASM 3.0 Completed

#225

Post by brokencube » Wed, Sep 17, 2025, 10:39 PM UTC

gertop wrote: post #210

jjcm wrote: post #176

Earlier quoted context omitted.

I know you're in this for the satire, but it's less about the webapps needing the memory and more about the content - that's why I mentioned video editing webapps. For video editing, 4GiB of completely uncompressed 1080p video in memory is only 86 frames, or about 3-4 seconds of video. You can certainly optimize this, and it's rare to handle fully uncompressed video, but there are situations where you do need to buff…

> 4GiB of completely uncompressed 1080p video in memory is only 86 frames How is that data stored? Because (2^32)÷(1920×1080×4) = 518 which is still low but not 86 so I'm curious what I'm missing?

I would guess 3 colour channels at 16bit (i.e. 2 bytes)

(2^32)÷(1920×1080×4×3×2) = 86

Re: WASM 3.0 Completed

#226

Post by Findecanor » Wed, Sep 17, 2025, 10:40 PM UTC

renehsz wrote: post #97

jjcm wrote: post #12

I'm definitely excited to see 64 bit as a default part of the spec. A lot of web apps have been heavily restricted by this, in particular any online video editors. We see a bunch of restrictions due to the 32 bit cap today here at Figma. One thing I'm curious though is whether mobile devices will keep their addressable per-tab memory cap the same. It's often OS defined rather than tied to the 32 bit space.

Unfortunately, Memory64 comes with a significant performance penalty because the wasm runtime has to check bounds (which wasn't necessary on 32-bit as the runtime would simply allocate the full 4GB of address space every time). But if you really need more than 4GB of memory, then sure, go ahead and use it.

Actually, runtimes often allocate 8GB of address space because WASM has a [base32 + index32] address mode where the effective address could overflow into the 33rd bit.

On x86-64, the start of the linear memory is typically put into one of the two remaining segment registers: GS or FS. Then the code can simply use an address mode such as "GS:[RAX + RCX]" without any additional instructions for addition or bounds-checking.

Re: WASM 3.0 Completed

#227

Post by saulpw » Wed, Sep 17, 2025, 10:40 PM UTC

brokencode wrote: post #215

cedws wrote: post #192

Earlier quoted context omitted.

But then you need two things instead of one. It should be made possible to build WASM-only SPAs. The north star of browser developers should be to deprecate JS runtimes the same way they did Flash.

You can use a framework that abstracts all the WASM to JS communication for DOM access. There are many such framework already. The only issue is that there’s a performance cost. Not sure how significant it is for typical applications, but it definitely exists. It’d be nice to have direct DOM access, but if the performance is not a significant problem, then I can see the rationale for not putting in the major amount o…

Which framework is the best or most commonly used?

Re: WASM 3.0 Completed

#228

Post by o11c » Wed, Sep 17, 2025, 10:40 PM UTC

mananaysiempre wrote: post #196

munificent wrote: post #157

Earlier quoted context omitted.

We call it "pointer compression" now. :)

Seriously though, I’ve been wondering for a while whether I could build a GCC for x86-64 that would have 32-bit (low 4G) pointers (and no REX prefixes) by default and full 64-bit ones with __far or something. (In this episode of Everything Old Is New Again: the Very Large Memory API[1] from Windows NT for Alpha.) [1] https://devblogs.microsoft.com/oldnewthing/20070801-00/?p=25...

A moderate fraction of the work is already done using:

https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html

Unfortunately the obvious `__attribute__((mode(...)))` errors out if anything but the standard pointer-size mode (usually SI or DI) is passed.

Or you may be able to do it based on x32, since your far pointers are likely rare enough that you can do them manually. Especially in C++. I'm pretty sure you can just call "foreign" syscalls if you do it carefully.

Re: WASM 3.0 Completed

#229

Post by rtpg » Wed, Sep 17, 2025, 10:41 PM UTC

cedws wrote: post #180

When is WASM finally going to be able to touch the DOM? It feels like that was the whole point of WASM and instead its become a monster of its own that barely has anything to do with web anymore. When can we finally kill JavaScript?

One of the things that I think make this tricky is that if you have any DOM references you now have visibility into a GCable object.

Part of the web Javascript security model is that you cannot see into garbage collection. So if you have some WASM-y pointer to a DOM element, how do you handle that?

I think with GC in properly people might come at this problem again, but pre-GC WASM this sounds pretty intractable

Re: WASM 3.0 Completed

#230

Post by jesse__ » Wed, Sep 17, 2025, 10:44 PM UTC

sehugg wrote: post #198

TrueDuality wrote: post #181

Earlier quoted context omitted.

The irony for me is that it's already slow because of the lack of native 64-bit math. I don't care about the memory space available nearly as much.

Eh? I'm pretty sure it's had 64-bit math for awhile -- i64.add, etc.

They might have meant lack of true 64bit pointers ..? IIRC the chrome wasm runtime used tagged pointers. That comes with an access cost of having to mask off the top bits. I always assumed that was the reason for the 32bit specification in v1