Comment by panic | Hacker News Reader

Comment by panic | Hacker News Reader

Parent Full thread

I'm also excited about this aspect of WebAssembly, but interoperability will hard without a well-defined ABI. There are only four types in wasm: int32, int64, float32, and float64. Anything other than that needs to be encoded somehow, either as multiple values or in memory.

For example, say you want to pass a 16-byte struct as an argument: how do you do it? Do you store the struct in memory and pass an int32 pointer to its start address? Or an int64 pointer? Maybe you encode it as two int64s? Once you've made a choice, good luck calling functions generated by a compiler that made a different one!

Another problem (in the web context) is blocking--Emscripten runs into this one. You can't suspend WebAssembly execution in the middle of calling out to an imported function. If a WebAssembly program wants to read keypresses interactively, it can't use a blocking function like read(). You have to pass the keypresses in at the outer level--or reimplement the call stack yourself like Go did (https://docs.google.com/document/d/131vjr4DH6JFnb-blm_uRdaC0...).

In general, WebAssembly code today is very tied to the JavaScript code that manages its interaction with the outside world. You can't just write a WebAssembly program that uses OpenGL. You also need to write the JavaScript that turns those calls into WebGL calls. I don't think this is a fundamental problem--we just haven't seen standards develop yet. As platforms start to define their API directly in terms of WebAssembly, without a JavaScript layer, we may see more of a "standard ABI" develop. Until then, it's hard to know what kind of APIs to target or support as an application or compiler writer.

> For example, say you want to pass a 16-byte struct as an argument: how do you do it? Do you store the struct in memory and pass an int32 pointer to its start address? Or an int64 pointer? Maybe you encode it as two int64s? Once you've made a choice, good luck calling functions generated by a compiler that made a different one!

Sounds like every architecture ever? There’s an architecture specification and then there’s an ABI. It’s common to only support some small number of sizes, x86 is a bit the odd one out these days.

Sure, but there's no standard ABI for WebAssembly yet. I'm basically just saying we need an ABI before we can target it as a platform apart from the web.

It's not really a standalone platform, though. It's a sandbox utility to contain high-speed or highly customized computation, that can be plugged into any other platform. By design, it doesn't seem intended to be limited to a single higher-level (well, higher than assembly language) ABI.

LLVM IR is interesting in that it's the opposite: it supports from i1 to i(2^23-1)

I share that view. Currently each high level language compiles to its own thing creating huge islands of code. C#, Java, Go, Rust, C etc will all compile their frameworks into the wasm files with very simple facade interfaces. The overhead will be enormous. Also the core is abstraction like memory and thread management is far from here.

It will take a decade to figure that out. Till then, wasm is good for single apps but not an ecosystem

> Currently each high level language compiles to its own thing creating huge islands of code. C#, Java, Go, Rust, C etc will all compile their frameworks into the wasm files with very simple facade interfaces.

This is more or less what SmallTalk has been doing for ages. The keyword for that is "image", in particular "single image".

And yes, it poses interoperability problems: http://www.ianbicking.org/where-smalltalk-went-wrong.html

> There are only four types in wasm: int32, int64, float32, and float64.

You can't directly address and manipulate a single byte in WASM?

You can address bytes (using instructions like i32.load8_u), but doing arithmetic with them can be awkward.

GC with structs and fields, host types, threads, etc are in the pipeline to address your concerns. While their implementation is coming along really slowly, I suppose that's better than hasty.

Yup; each embedding environment will need to spec an ABI, just like any other platform that exists. This is a possible future, not one that is 100% for sure happening.

The blocking thing has some solutions in the browser, like web workers, but that'll be fixed in time too. Emscripten can already do the OpenGL -> WebGL thing, incidentally.

Reply on news.ycombinator.com