It sounded good until this part. Would have been nice if it were written in the subset of C that it supports, so it could compile the compiler to Wasm.
In the comparison with Emscripten using wasm-decompile [1], the author appears to have forgotten to turn on optimization. Yes, if you run emcc with no -O option then you will get extremely bad generated code quality, similar to most C compilers. Add -O and you get nice and tight code similar to what c4wa outputs.
I think, the author's goal was to produce wasm-code that had the same structure as the original C. Thus it makes sense to turn off the advanced optimizations.
> It's really, really difficult to recognize out original logic here. Among other things, whereas our original C code only has 2 local variables, this version has 29, not counting module-level globals.
Isnt that quite common now with machine generated code. Look at nim clientside js, I dear any js dev to try to navigate that.
The point is should we just trust the machine generated as it is and hope that the compiler/bundler just did a correct job, or just write clean and simple code
Personally, although I do use wasi-sdk (clang) and the wasm32-unknown-wasi triple, the result can be basically free-standing, depending on what flags you use.
As a sibling post said, optimization matters, and using wasm-ctor-eval and wasm-opt also helps. But it's useful to keep full C semantics.
> Personally, although I do use wasi-sdk (clang) and the wasm32-unknown-wasi triple, the result can be basically free-standing, depending on what flags you use.
This is what I've been doing for my little non-WASI runtime. For my minimal programs I find only a few wasi exports are required, which don't appear to actually be used and I just stub them out. Would love to figure out how to get rid of the code depending on them entirely but it's lower priority.
Thanks. This is awesome. For the emulator I wrote my own 200 line libc implementation with a five line malloc routine [0]. Nice to see another implementation, which does a little bit more.
That emulator is awesome. Especially cool about the easter egg.
I've seen a few of these WASM emulators and fantasy consoles, but they all seem to be focused on games. Are you aware of any that are designed to run normal GUI apps?
This is actually pretty compelling to me. I think the more support for freestanding wasm modules the better.
I'm working on a custom wasm app runtime and I don't want to have to implement the entire API surface of Emscripten or WASI. The new component model is even more complex. I wish there was more tooling available for using C/Rust stdlib functions for things like reading files or opening a socket, but being able to define your own API to handle the actually operations in the host/module interface.
one wierd connection i realised later now,
> volatile in c was for blocking reorders, forcing real mem reads, esp mmio or sync operations. wasm runs singlethreaded, no fences unless you go atomic. so compiler keeps volatile loads yeah, but wasm runtime ain't bound to order. it runs but doesn't mean anything. semantics gone. still compiles
> c4wa needs Java 11 or above
It sounded good until this part. Would have been nice if it were written in the subset of C that it supports, so it could compile the compiler to Wasm.
In the comparison with Emscripten using wasm-decompile [1], the author appears to have forgotten to turn on optimization. Yes, if you run emcc with no -O option then you will get extremely bad generated code quality, similar to most C compilers. Add -O and you get nice and tight code similar to what c4wa outputs.
[1] https://github.com/kign/c4wa/blob/master/etc/doc/comparison....
I think, the author's goal was to produce wasm-code that had the same structure as the original C. Thus it makes sense to turn off the advanced optimizations.
> It's really, really difficult to recognize out original logic here. Among other things, whereas our original C code only has 2 local variables, this version has 29, not counting module-level globals.
Isnt that quite common now with machine generated code. Look at nim clientside js, I dear any js dev to try to navigate that.
The point is should we just trust the machine generated as it is and hope that the compiler/bundler just did a correct job, or just write clean and simple code
clang can compile into wasm pretty well via the
--target=wasm32
option. It creates small binaries. My 16-Bit x86 emulator with BIOS and DOS emulation is under 100kB [0].
[0] https://github.com/s-macke/FSHistory
And if you need parts of libc, you can use something like the below, for something more minimal than musl: https://github.com/Photosounder/MinQND-libc
Personally, although I do use wasi-sdk (clang) and the wasm32-unknown-wasi triple, the result can be basically free-standing, depending on what flags you use.
As a sibling post said, optimization matters, and using wasm-ctor-eval and wasm-opt also helps. But it's useful to keep full C semantics.
> Personally, although I do use wasi-sdk (clang) and the wasm32-unknown-wasi triple, the result can be basically free-standing, depending on what flags you use.
This is what I've been doing for my little non-WASI runtime. For my minimal programs I find only a few wasi exports are required, which don't appear to actually be used and I just stub them out. Would love to figure out how to get rid of the code depending on them entirely but it's lower priority.
Thanks. This is awesome. For the emulator I wrote my own 200 line libc implementation with a five line malloc routine [0]. Nice to see another implementation, which does a little bit more.
[0] https://github.com/s-macke/FSHistory/tree/master/src/wasm_li...
That emulator is awesome. Especially cool about the easter egg.
I've seen a few of these WASM emulators and fantasy consoles, but they all seem to be focused on games. Are you aware of any that are designed to run normal GUI apps?
Last commit on Jan 29, 2022
> here are some of the most commonly used features of C language NOT supported by c4wa. > [...] Almost all new features introduced in C99
At least, it doesn't require K&R syntax for functions!
Zig can also compile to free standing wasm
any example? I search wasm without js.
I noticed this question yesterday, which includes the changed build options for freestanding.
https://ziggit.dev/t/wasm-index-out-of-bounds-only-in-debug-...
This is actually pretty compelling to me. I think the more support for freestanding wasm modules the better.
I'm working on a custom wasm app runtime and I don't want to have to implement the entire API surface of Emscripten or WASI. The new component model is even more complex. I wish there was more tooling available for using C/Rust stdlib functions for things like reading files or opening a socket, but being able to define your own API to handle the actually operations in the host/module interface.
one wierd connection i realised later now, > volatile in c was for blocking reorders, forcing real mem reads, esp mmio or sync operations. wasm runs singlethreaded, no fences unless you go atomic. so compiler keeps volatile loads yeah, but wasm runtime ain't bound to order. it runs but doesn't mean anything. semantics gone. still compiles