Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WASM 3.0 Completed

webassembly.org

Post reply on HN
Print view View original

191–200 of 520 posts

Re: WASM 3.0 Completed

#191

Post by magicalhippo »

baq wrote: post #125
jsheard wrote: post #104

Earlier quoted context omitted.

The comedy option would be to use the new multi-memory feature to juggle a bunch of 32bit memories instead of a 64bit one, at the cost of your sanity.

didn't we call it 'segmented memory' back in DOS days...?

It was glorious I tell you.

Especially how you could increase the segment value by one or the offset by 16 and you would address the same memory location. Think of the possibilities!

And if you wanted more than 1MB you could just switch memory banks[1] to get access to a different part of memory. Later there was a newfangled alternative[2] where you called some interrupt to swap things around but it wasn't as cool. Though it did allow access to more memory so there was that.

Then virtual mode came along and it's all been downhill from there.

[1]: https://en.wikipedia.org/wiki/Expanded_memory

[2]: https://hackaday.com/2025/05/15/remembering-more-memory-xms-...

Re: WASM 3.0 Completed

#192

Post by cedws »

vinkelhake wrote: post #187
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?

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.

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.

Re: WASM 3.0 Completed

#193

Post by evmar »

jsheard wrote: post #104
renehsz wrote: post #97

Earlier quoted context omitted.

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.

The comedy option would be to use the new multi-memory feature to juggle a bunch of 32bit memories instead of a 64bit one, at the cost of your sanity.

It looks like memories have to be declared up front, and the memcpy instruction takes the memories to copy between as numeric literals. So I guess you can't use it to allocate dynamic buffers. But maybe you could decide memory 0 = heap and memory 1 = pixel data or something like that?

Re: WASM 3.0 Completed

#194

Post by afiori »

gspr wrote: post #100
flohofwoe wrote: post #63

Earlier quoted context omitted.

That old thing again ;) Direct DOM access doesn't make any sense as a WASM feature. It would be at best a web-browser feature which browser vendors need to implement outside of WASM (by defining a standardized C-API which maps to the DOM JS API and exposing that C API directly to WASM via the function import table - but that idea is exactly as horrible in practice as it sounds in theory). If you need to manipulate th…

> If you need to manipulate the DOM - just do that in JS, calling from WASM into JS is cheap, and JS is surprisingly fast too. From the point of view of someone who doesn't do web development at all, and to whom JS seems entirely cryptic: This argument is weird. Why is this specific (seemingly extremely useful!) "web thing" guarded by a specific language? Why would something with the generality and wide scope of WASM…

The practical argument is that while initially the DOM API was developed to be language agnostic with more of an eye to Java/C++ than JavaScript since a while ago this is no longer the case and many web APIs use JavaScript data types and interfaces (eg async iterators) that do not map well to wasm

The good news is that you can use very minimal glue code with just a few functions to do most JavaScript operations

Re: WASM 3.0 Completed

#195

Post by jcul »

flohofwoe wrote: post #132
gspr wrote: post #100

Earlier quoted context omitted.

> If you need to manipulate the DOM - just do that in JS, calling from WASM into JS is cheap, and JS is surprisingly fast too. From the point of view of someone who doesn't do web development at all, and to whom JS seems entirely cryptic: This argument is weird. Why is this specific (seemingly extremely useful!) "web thing" guarded by a specific language? Why would something with the generality and wide scope of WASM…

Think of it as traditional FFI (foreign function interface) situation. Many important libraries have been written in C and only come with a C API. To use those libraries in non-C languages (such as Java) you need a mechanism to call from Java into C APIs, and most non-C language have that feature (e.g. for Java this was called JNI but has now been replaced by this: https://docs.oracle.com/en/java/javase/21/core/forei…

Wow, I've used JNI many times, but many years ago. It is a bit painful. Cool to see it's been replaced by FFM, didn't know that existed.

Re: WASM 3.0 Completed

#196

Post by mananaysiempre »

munificent wrote: post #157
baq wrote: post #125

Earlier quoted context omitted.

didn't we call it 'segmented memory' back in DOS days...?

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

Re: WASM 3.0 Completed

#197

Post by afiori »

flohofwoe wrote: post #161
gspr wrote: post #141

Earlier quoted context omitted.

Sure, but if someone came at the C-centric ecosystem today and said "let's do the work to make it so that any language can play in this world", then surely "just FFI through C" would be considered rather underwhelming?

Well that's what the WASM Component Model set out to solve, some sort of next-gen FFI standard that goes beyond C APIs: https://component-model.bytecodealliance.org/ In my opinion it's an overengineered boondoggle, since "C APIs ought to be good enough for anything", but maybe something useful will eventually come out of it, so far it looks like it mostly replaces the idea of C-APIs as lingua-franca with "a random co…

While it can function as an FFI (it is indeed the basis of WASI) the component model is more about composability and interfaces

Re: WASM 3.0 Completed

#198

Post by sehugg »

TrueDuality wrote: post #181
renehsz wrote: post #97

Earlier quoted context omitted.

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.

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.

Re: WASM 3.0 Completed

#199

Post by pverheggen »

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?

Probably never. There's a pretty good recent thread on this topic:

https://news.ycombinator.com/item?id=44775801

Re: WASM 3.0 Completed

#200

Post by [deleted] »

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.

[deleted]
Post reply on HN