WASM as a Platform for Abstraction
adventures.michaelfbryan.com
WASM as a Platform for Abstraction
1–10 of 85 posts
Re: WASM as a Platform for Abstraction
#2While 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, say, JavaScript, but we can do better than that.
The problem with WASM here, is that it really is a bloated model like JVM in its early days, huge amount of work is needed to make it closer to native speed, which is contradictory to the original slogan. What's more, people are still planning to add tons of new features to it: https://webassembly.org/docs/future-features/. Before you tell me those are opt-in features, the question I want to raise is: for an abstraction of general platform, you would definitely want to have a widely accepted standard so people know what features will be expected, one example is that people know SSE will be available for 64-bit x86 code.
With all those opt-in features, I doubt if we can have a proper layer that adapts well to different implementations with different supported features. We might end up with the situation like Rust, where you can claim a secondary compiler could exist, but in practice people are all using the same compiler/implementation.
Re: WASM as a Platform for Abstraction
#3While 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?
Re: WASM as a Platform for Abstraction
#4While 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?
I'm pretty sure it is not stable and not designed for such a use case.
Re: WASM as a Platform for Abstraction
#5While 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.
Re: WASM as a Platform for Abstraction
#6While 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?
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*)];
Re: WASM as a Platform for Abstraction
#7Lots of wasm questions:
In what sense can a wasm program "crash?" What sort of backtraces are available in that event? How's the debugging story?
Is there a fast wasm runtime available for non-JIT platforms? Is there big-endian support (still hanging on)?
Re: WASM as a Platform for Abstraction
#8While 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.
I totally agree that it's not the best tech always wins, that's why I'm pointing it out, I really wish that 5 years from now, we can rely on something that makes sense to be there, not just because something has a low cost of adoption.
Re: WASM as a Platform for Abstraction
#9While 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,…
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.
Re: WASM as a Platform for Abstraction
#10While 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,…
> The problem with WASM here, is that it really is a bloated model like JVM in its early days,
Isn't WASM (as of its MVP) quite simple VM model compared to other VMs?
I agree with your concern about the new futures though. It might introduce another hell of segmentation.