Live data from Hacker News

WASM as a Platform for Abstraction

adventures.michaelfbryan.com

81–85 of 85 posts

Re: WASM as a Platform for Abstraction

#81
post #80
post #51

Earlier quoted context omitted.

Doesn't ARM code emulated on x86 (and vice versa) perform even worse than WebAssembly? Isn't that essentially what you would get with a lower-level "optimized compiled result of LLVM"?

Does the fact that ARM is a bad choice disproves all other choices other than WASM? I'm not sure this is a good argument here. Lower-level bytecodes are more flourishing than just ARM.

I imagine it's more difficult to translate efficiently between two different low-level instruction sets (such as ARM, MIPS, x86, PowerPC, etc.) than to translate something slightly higher-level to the various low-level target instruction sets. Emulating ARM on x86 is usually slow (see the Android emulator) as is the reverse (see Windows 10 on ARM) and PowerPC on x86 (Apple's Rosetta) didn't seem particularly fast either.

Do you have an example in mind of a lower-level instruction set that can be efficiently translated to different real-world ISAs?

Re: WASM as a Platform for Abstraction

#82
post #24

Earlier quoted context omitted.

Apple kind of disagrees with watchOS bitcode.

"not designed for that use case" != "isn't used for that use case in practice" Apple has tight control over the bitcode version and the target platforms supported by Xcode. That's not the same thing as accepting arbitrary LLVM bitcode files.

Nothing prevents LLVM project to adopt such variant, other than unwillingness to do so.

Re: WASM as a Platform for Abstraction

#83
post #23

Earlier quoted context omitted.

Open source LLVM IR is machine specific, it doesn't have to be, as proven by watchOS bitcode, or PNaCL.

> it doesn't have to be, as proven by watchOS bitcode, or PNaCL. Both of those have fixed 32-bit pointer sizes and are little-endian. When you compile for watchOS bitcode or PNaCL you just target a single virtual machine & "system" ABI. LLVM IR or any related techniques won't ever allow you to produce a 32 / 64 bit or ARM / x86 app that is able to leverage the whole feature set of the platform from the same bitcode.

Yet watchOS migrated from 32 bit to 64 bit.

It is possible, LLVM project just needs to actually want to support such use cases in a portable way.

Re: WASM as a Platform for Abstraction

#84
post #83

Earlier quoted context omitted.

> it doesn't have to be, as proven by watchOS bitcode, or PNaCL. Both of those have fixed 32-bit pointer sizes and are little-endian. When you compile for watchOS bitcode or PNaCL you just target a single virtual machine & "system" ABI. LLVM IR or any related techniques won't ever allow you to produce a 32 / 64 bit or ARM / x86 app that is able to leverage the whole feature set of the platform from the same bitcode.

Yet watchOS migrated from 32 bit to 64 bit. It is possible, LLVM project just needs to actually want to support such use cases in a portable way.

> Yet watchOS migrated from 32 bit to 64 bit.

that is what they said in the press release but in practice they migrated from "classical" 32bit ARM to ILP-32 (akin to the x32 ABI on linux) so the size of pointers, etc etc does not change from 32-bit. You get more registers & stuff like that which is nice, but that is not moving to 64 bit, just having nicer 32 bit execution on 64 bit CPUs. If you want proper aarch64 support on WatchOS you have to recompile.

Re: WASM as a Platform for Abstraction

#85
post #83

Earlier quoted context omitted.

Yet watchOS migrated from 32 bit to 64 bit. It is possible, LLVM project just needs to actually want to support such use cases in a portable way.

> Yet watchOS migrated from 32 bit to 64 bit. that is what they said in the press release but in practice they migrated from "classical" 32bit ARM to ILP-32 (akin to the x32 ABI on linux) so the size of pointers, etc etc does not change from 32-bit. You get more registers & stuff like that which is nice, but that is not moving to 64 bit, just having nicer 32 bit execution on 64 bit CPUs. If you want proper aarch64 su…

Fair enough. Still nothing prevents LLVM bitcode to be fully CPU agnostic, if LLVM guys were willing to keep such variant around.
Post reply on HN