Never been using C, I guess-coded my way to this little program:

    int pow(a)
    {
     for (int i=0;i<10;i++) a=a*2+1;
     return a;
    }

    int main()
    {
     return pow(1);
    }

    (module
      (table 0 anyfunc)
      (memory $0 1)
      (export "memory" (memory $0))
      (export "pow" (func $pow))
      (export "main" (func $main))
      (func $pow (param $0 i32) (result i32)
        (i32.or
          (i32.shl
            (get_local $0)
            (i32.const 10)
          )
          (i32.const 1023)
        )
      )
      (func $main (result i32)
        (i32.const 2047)
      )
    )

Then again, I could just be feeding a troll right now, I really can't tell.

Anyone can implement one and ship it with the statically compiled WASM code, it is no different than targeting an actual machine code, unless we are speaking of CPUs like Intel iAPX 432.

The only issue is having a little bigger download, which is irrelevant in the age where web pages to display static text are bigger than the whole Quake installation.

As for the bigger download, I'm hoping we'll be able to load libraries dynamically through WASM so you can cache things like the C runtime separately

The idea of caching runtimes looks good, but we need some kind of versioning, otherwise it will be yet another WASM.so hell.

Maybe tying them to the origin would be a possible solution.

0,97,115,109,1,0,0,0,1,138,128,128,128,0,2,96,1,127,1,127,96,0,1,127,3,131, .... 2047

You can edit this as you see fit, or even write it by hand if you want. What's wrong with it? It's the same with native programs. You get your executable, open it in the hex editor, do your thing and run the program, done.

I'm not being entirely serious, but that's because you seem to conflate the tooling's features with the WA, or you simply don't understand what assembly really is. As a "child of the web" it's not strange, but you should at least accept your own lack of knowledge and understanding.

In short: there are two programs involved in the WasmFiddle: a compiler and an assembler. You're saying you want to play with assembler - fair enough, you can do this. That you have to write a disasm for this or learn the opcodes by heart, doesn't mean it's impossible. The thing is, no one other than you cares (it's a lie - there are people with a justified, practical interest in this, but it's almost certain you're not one of them) because it's hard and the compiler is going to make a better job at it than you anyway.

In other words, you're saying you don't like WebAssembly because it's an assembler. It's not a problem with WA, but with your expectations.

EDIT: shortened assembly output to make the rest of the post readable.

As someone who at one point in his life had a lot of fun writing Z80 for his TI-83+, I do wonder how bit a "market" for a WASM environment oriented towards human editing of the assembly might be. It's probably being built anyway, for the compiler writers. The question is if it might "break out" to other enthusiasts.

It's easy to forget that before higher level languages, assembly was the norm. Assembly at the time was more "human-friendly" to program in too; if you're comfy with C and pointers, going a bit lower really isn't that scary. It's just that the decades of x86 extensions have created hugely complicated beasts that few sane people would dare touch. However, the forty or so z80 opcodes are quick to memorise. I've heard that ARM and 68k is "fun" to work with too (for a certain type of programmer, obviously).

Anyway, the s-expression form of WASM feels like a throwback to the more human friendly CPU days, presumably also because it has to be so platform-independent (and because SIMD isn't in yet). I'm sure there will be enthusiasts playing with it.

The popcnt example is nice.