3 ms·

While it's an interesting (and effective) approach to learn something, what is the point of learning WebAssembly? After all, I thought that WASM was supposed to

While it's an interesting (and effective) approach to learn something, what is the point of learning WebAssembly? After all, I thought that WASM was supposed to be something like "LLVM for web", a low-level IR for webdev languages to target and for browsers to execute efficiently, and not something that you'd write manually. Or am I wrong?

hoten 3y ago
Some reasons to understand the textual representation, besides curiousity: You are embedding a WASM engine and want to better grok how the import or exporting works. You are writing a compiler that targets WASM.
emnudge 3y ago
Author here! My initial motivation to learn WASM (as someone from a primarily web background) was that I had a pretty poor understanding of WASM in general and so I had a lot of difficulty working with WASM builds in just about any capacity other than a heavy JS wrapper. There are aspects to how WASM works that are quite different from other kinds of assembly formats that make learning the basics pretty important. e.g. how memory is requested, provided, grown. How functions are received and exported. Capabilities of tables. A lot of this might be abstracted by massive wrappers, but you're losing a lot in perf and debugability when using them.
- wanderlust123 3y ago
  Thanks for putting this together, I too learn best by doing, and this looks very helpful!
deleted 3y ago
[deleted]
chrisco255 3y ago
Sometimes you may need to debug the actual wasm code or understand what the compiler is outputting. Depending on the flags you set during compilation, you may want to optimize for size of binary or for performance. You may also want to compare the wasm produced by two different languages or different versions of the language compiler. Maybe you want to verify what libraries are actually getting bundled with your wasm.
- thamer 3y ago
  Understanding what the compiler outputs is also essential to debug the inevitable issues that come up when porting an existing program to WASM. Since it's a different platform with significant limitations, it's important to know how to replace some core APIs and capabilities and how to interface with these alternatives. By limitations I mean things that a POSIX program would expect that aren't generally available from WASM, like network programming, file system access, processes and threads, pipes and signals. Emscripten and WASI help to some extent, but the replacement APIs are rarely fully compatible.
ReleaseCandidat 3y ago
Actually it is quite high level (with the GC extension even "higher" than C), not comparable to "real" assembler. It has types. It isn't fun writing WAT, but for small stuff it's perfectly doable. That's a record with 3 fields, its constructor and getters using the GC extension: ;; A `struct` with 3 fields, all immutable. (type $testStruct (struct (field $first i64) (field $foo f32) (field $baz f64))) ;; Constructor. `ref` is a reference (func $mkTestStruct (param $a i64) (param $b f32) (param $c f64) (result (ref $testStruct)) (struct.new $testStruct (local.get $a) (local.get $b) (local.get $c))) (export "mkTestStruct" (func $mkTestStruct)) ;; Getter function for the three fields: (func $getTestStruct1 (param $rs (ref $testStruct)) (result i64) (struct.get $testStruct 0 (local.get $rs))) (export "getTestStruct1" (func $getTestStruct1)) (func $getTestStruct2 (param $rs (ref $testStruct)) (result f32) (struct.get $testStruct 1 (local.get $rs))) (export "getTestStruct2" (func $getTestStruct2)) (func $getTestStruct3 (param $rs (ref $testStruct)) (result f64) (struct.get $testStruct 2 (local.get $rs))) (export "getTestStruct3" (func $getTestStruct3))
__s 3y ago
For awhile I was using a raw wasm program for a game engine's random number generator. Stored all the state in global variables, so no heap necessary Eventually I moved the whole game engine into wasm & at that point it all got ported to Rust https://github.com/serprex/openEtG/blob/8b7069cc52ec8db3406a69c8b6ac38a955b8dd16/src/rng.wat https://github.com/serprex/openEtG/blob/8b7069cc52ec8db3406a...

hoten 3y ago

Some reasons to understand the textual representation, besides curiousity: You are embedding a WASM engine and want to better grok how the import or exporting works. You are writing a compiler that targets WASM.

emnudge 3y ago

Author here! My initial motivation to learn WASM (as someone from a primarily web background) was that I had a pretty poor understanding of WASM in general and so I had a lot of difficulty working with WASM builds in just about any capacity other than a heavy JS wrapper. There are aspects to how WASM works that are quite different from other kinds of assembly formats that make learning the basics pretty important. e.g. how memory is requested, provided, grown. How functions are received and exported. Capabilities of tables. A lot of this might be abstracted by massive wrappers, but you're losing a lot in perf and debugability when using them.

wanderlust123 3y ago
Thanks for putting this together, I too learn best by doing, and this looks very helpful!

deleted 3y ago

[deleted]

chrisco255 3y ago

Sometimes you may need to debug the actual wasm code or understand what the compiler is outputting. Depending on the flags you set during compilation, you may want to optimize for size of binary or for performance. You may also want to compare the wasm produced by two different languages or different versions of the language compiler. Maybe you want to verify what libraries are actually getting bundled with your wasm.

thamer 3y ago
Understanding what the compiler outputs is also essential to debug the inevitable issues that come up when porting an existing program to WASM. Since it's a different platform with significant limitations, it's important to know how to replace some core APIs and capabilities and how to interface with these alternatives. By limitations I mean things that a POSIX program would expect that aren't generally available from WASM, like network programming, file system access, processes and threads, pipes and signals. Emscripten and WASI help to some extent, but the replacement APIs are rarely fully compatible.

ReleaseCandidat 3y ago

Actually it is quite high level (with the GC extension even "higher" than C), not comparable to "real" assembler. It has types. It isn't fun writing WAT, but for small stuff it's perfectly doable. That's a record with 3 fields, its constructor and getters using the GC extension: ;; A `struct` with 3 fields, all immutable. (type $testStruct (struct (field $first i64) (field $foo f32) (field $baz f64))) ;; Constructor. `ref` is a reference (func $mkTestStruct (param $a i64) (param $b f32) (param $c f64) (result (ref $testStruct)) (struct.new $testStruct (local.get $a) (local.get $b) (local.get $c))) (export "mkTestStruct" (func $mkTestStruct)) ;; Getter function for the three fields: (func $getTestStruct1 (param $rs (ref $testStruct)) (result i64) (struct.get $testStruct 0 (local.get $rs))) (export "getTestStruct1" (func $getTestStruct1)) (func $getTestStruct2 (param $rs (ref $testStruct)) (result f32) (struct.get $testStruct 1 (local.get $rs))) (export "getTestStruct2" (func $getTestStruct2)) (func $getTestStruct3 (param $rs (ref $testStruct)) (result f64) (struct.get $testStruct 2 (local.get $rs))) (export "getTestStruct3" (func $getTestStruct3))

__s 3y ago

For awhile I was using a raw wasm program for a game engine's random number generator. Stored all the state in global variables, so no heap necessary Eventually I moved the whole game engine into wasm & at that point it all got ported to Rust https://github.com/serprex/openEtG/blob/8b7069cc52ec8db3406a69c8b6ac38a955b8dd16/src/rng.wat https://github.com/serprex/openEtG/blob/8b7069cc52ec8db3406a...