31–40 of 85 posts
If I were him, I'd have used this as an excuse to play with NativeClient.
--
The original paper on SFI was by Robert Wahbe and colleagues: https://cs155.stanford.edu/papers/sfi.pdf.
Google's NativeClient is a modern take on SFI for x86: https://static.googleusercontent.com/media/research.google.c....
WASM advocates keep rediscovering the benefits from bytecodes as portable execution format, while presenting them as something great made possible only by WASM. Reading a bit of mainframe history would do some good it seems.
While I do agree WASM makes a lot of sense for the Web, I personally am having doubts regarding treating WASM as a general abstractions for native code as used in the post. For this case, it might suit the job better to have a bytecode that resembles more of underlying machine architecture, rather than a still highly abstracted model like WASM. Please don't get me wrong, I do agree WASM is already one step ahead of,…
And yet, it will probably be used for that and become popular. Tech doesn't need to be perfect, the best, or even very good to win. They need to have a killer feature and a low cost of adoption. Wasm seems on the right tracker for that.
This is a powerful statement actually. Could be applied to any tech startup product.
Earlier quoted context omitted.
No, LLVM IR is machine specific. Any "native" language is since the ABI of a struct will depend e.g. on the size of pointers for that platform. E.g. Consider in C int foo[sizeof(void*)];
Open source LLVM IR is machine specific, it doesn't have to be, as proven by watchOS bitcode, or PNaCL.
Earlier quoted context omitted.
Besides, doesn't LLVM already have an IR which servers as one such higher-level abstraction?
Google created pretty much this, called it PNaCl and shipped it in Chrome. It now has been retired in favor of WASM.
Earlier quoted context omitted.
It sounds like you're bringing up a register-based vs stack-based VM argument, and claiming that register-based VMs have better performance because their model is closer to the hardware. My understanding is that this intuition is usually untrue, because a JIT benefits from the stack-based code preserving code flow and thus allowing more efficient code generation.
No I'm not talking about register-based vs stack-based VM, that's a totally different topic. I'm just saying WASM is still quite distant from real hardware, making it a non-trivial task to performantly run the code. In fact if you look at the asm.js, which is the original inspiration of WASM, it is a much closer mode to real hardware. And of course JIT can make WASM fast but if you look around, building a performant…
While I do agree WASM makes a lot of sense for the Web, I personally am having doubts regarding treating WASM as a general abstractions for native code as used in the post. For this case, it might suit the job better to have a bytecode that resembles more of underlying machine architecture, rather than a still highly abstracted model like WASM. Please don't get me wrong, I do agree WASM is already one step ahead of,…
Besides, doesn't LLVM already have an IR which servers as one such higher-level abstraction?
WASM advocates keep rediscovering the benefits from bytecodes as portable execution format, while presenting them as something great made possible only by WASM. Reading a bit of mainframe history would do some good it seems.
I don't know, I know nothing about mainframes. I do not understand if your criticism is that they are making mistakes that have already been solved half a century ago (which is a good criticism, if true) or that they are not giving proper recognition.
The new shiny thing about WASM is that it fits into the constraints of the web platform. I suspect that even the best mainframes bytcodes had at least slightly different constraints.
I would really like a discussion and a comparison of them, seriously, I would read any such article I could find as the topic is interesting. But comments like this feels a lot like a hipster hating on the mainstream.
The author has rediscovered the need for software fault isolation (SFI). Bytecodes or IRs like WASM can also provide SFI but are overkill because they provide more than just SFI. If I were him, I'd have used this as an excuse to play with NativeClient. -- The original paper on SFI was by Robert Wahbe and colleagues: https://cs155.stanford.edu/papers/sfi.pdf . Google's NativeClient is a modern take on SFI for x86: htt…
WASM advocates keep rediscovering the benefits from bytecodes as portable execution format, while presenting them as something great made possible only by WASM. Reading a bit of mainframe history would do some good it seems.
> we’ve encountered the dilemma where you want to make it easy for users to write their own application logic using the system but at the same time want to keep that logic decoupled from the implementation details of whatever platform the application is running on
A common problem with a whole range of solutions. A decade or two ago the "obvious" choice would have been Java bytecode instead. Even the little "BASIC Stamp" microcontroller system matches this description.