[jfmc]

What about pointer size? Is still only 32-bits? It is impossible to write some C programs when you do not know the size of your data and pointers.

I'm asking that because despite all the hype, wasm binaries are still 32-bit (at least in browsers), while 32-bit OS are being deprecated. 64-bit pointers are really good for some applications, with no performance degradation at all.

Does Wasm 2.0 support branch instructions needed for irreducible control flows? (without the relooper hack)

[jsheard]

> 64-bit pointers are really good for some applications, with no performance degradation at all.

That probably won't be the case with wasm64 unfortunately. A hidden advantage of wasm using a 32 bit address space while primarily targeting 64 bit platforms is that runtimes can get free implicit bounds checking by carving out a 4GB block of virtual memory for each wasm instance, so out-of-bounds accesses are trapped by the hardware.

That trick won't work for wasm64, so runtimes will have to go back to inserting explicit bounds checks at every memory access, and it'll be a tradeoff where in exchange for being able to access more memory everything will run a bit slower.

[legulere]

Having 32 bit pointers in WASM does not mean that the JIT emits 32 bit code. 64 bit pointers always are a performance degradation, as they use up more space, it can just be negligible. 64 bit x86 most of the time being faster has nothing to do with pointer width but with more with having more registers, a better calling convention and a minimum of SSE2. This is also the reason why the x32 ABI is faster than regular x86-64.

The only advantage of 64 bit pointers is that you can have a bigger address space than 4GB.

[astrange]

That’s not the only advantage, you can also store extra data in them which is extremely useful for performance (tagged objects) and security (PAC).

Although an abstract machine could have metadata with each pointer that isn’t part of the official bit size, I suppose.

[shadowofneptune]

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

[jfmc]

The requirement for structured programs dates back from the asm.js hack. Both relooper and stackifier are still workarounds. CPUs do not require structure programs at all. Unless there is a really good reason this still looks a hack driven by limitations of the underlying code generation. I understand that some compilation passes are easier/cheaper with structured control. But then... why are not LLVM and GCC enforcing them as well (at least their roadmaps)?

[astrange]

It’s for security reasons and enabling static code analysis, there’s no particular need to make compilation “easier”.

PNaCL also had a lot of limitations though I don’t remember what they actually were.

[faichai]

Not yet, a note on the Memory instructions [1] still says: “Future version of WebAssembly might provide memory instructions with 64 bit address ranges.”

[1] https://www.w3.org/TR/wasm-core-2/syntax/instructions.html#m...

[jfmc]

https://webassembly.org/roadmap/

I fear they will run out of gas before the interesting features there are completed...

[emteycz]

They haven't for 5 years, why would they now? The work is just getting interesting...

[jfmc]

Perhaps... but 5 years without progress in some areas is an eternity. Rust in Firefox was super interesting and they run out of funding. It is really hard to explain to a client: "your application would work on WASM, on a browser, with no installation, but it will not scale in time and memory, and there is not a clear roadmap of then things will improve (despite OS and compiler guys know how to fix those things)".

[emteycz]

There's a lot of progress over the past 5 years, every month there's something new and exciting.

But it's not yet ready for mass adoption, yeah.