I would try it out, if it would be possible to just type web assembly by hand. Then I would just open an html file or a jsfiddle and play with it.
But as I understand it, it needs a toolchain?
But as I understand it, it needs a toolchain?
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.
The popcnt example is nice.
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.
You can see an examples in Rust including the readable Wat output here:
It's funny, I'm the exact opposite. I don't like cloud apps. One day they're there, next day half their features are removed, next day they're gone. And I can't hack them to make them better fits for me when they keep changing. I want the code to run on my machine so I can do anything I want to it and have a stable environment I can rely on.
I don't put anything I care for on machines I don't own. I own many machines in the cloud. They are beautiful. Because they are all the same. They are virtual. They are cheap. I can create them with a click. There are so many vendors. If one of them would go away, it would not tamper with my ability to create new machines.
I was talking about web apps, but w.r.t. VMs... sure, at the price of your pocket though? I can run my home computer all I want and not pay for anything except the electricity and internet.
> They are virtual. They are cheap. I can create them with a click.
If they are virtual, you don't own them. You own an 'I promise really really hard' of some vendor at best.
None of which has anything at all to do with installing a fucking tool chain.
BTW you DON'T need WA if you don't have performance issues with your current web application.
As for performance: I do a lot of machine learning in the browser. So performance is something that I am interested in.
Almost everywhere you look in front-end web today you see a toolchain that includes the node runtime, babel or typescript as a compiler, and some kind of bundler/linker such as webpack or browserify that throws in minification/mangling in as a freebie. That doesn't even cover CSS.
JS/CSS is already a compile target with a build artifact often barely resemble the original source code. WASM is just another compile target that opens up the web as a platform for other languages.
Compiler IR's like WASM or LLVM IR are very laborious to type, they're intended to be produced and consumed by compilers.
You need to write very verbose code with all the type declarations, which aren't automatically propagaged, ie. `(func $foo (param $0 i32) (result i32) ...)` and `(i32.add ...)`. There's very little point in writing code like this by hand, apart from testing and debugging the compiler producing or consuming this code.
It doesn't make much sense to have this "in the cloud" outside of toy tools like this. In any kind of actual work scenario, you'd be running a compiler producing WASM on your development machine and deliver the WASM binaries over HTTP to the client machine. The whole point is to have near-native performance while reducing the compile time on the client side.
But if you want to tinker with it, knock yourself out. Here's the tool:
[0] https://cdn.rawgit.com/WebAssembly/wabt/fb986fbd/demo/wat2wa...
I think there's at least some value in these "toy tools". Would being able to tinker with WASM not help development of compilers? I place a very high value on understanding as far down the stack as you can, I don't think ignorance of every abstraction layer below the one you're working on is a very noble goal to strive for.
There are tools, even web based ones, that allow you to tinker with WASM, compile C, C++ or Rust code to WASM, print out the WAT representation, turn WAT into WASM, run the WASM blobs through JS, etc.
These tools are probably very useful for the guys developing WASM frontends and backends. E.g. sharing a piece of WASM code with other developers.
Should the average developer use them? Not really. Maybe spend an hour poking at things to get the general idea of how it works. You really don't need to understand the details of LLVM IR, SPIR-V, WASM or GCC's GIMPLE in order to use those compilers.
Is it a good idea to understand what and how are intermediate representations used in compilers but actually writing that by hand is not necessary or productive.
Sounds like a strange duality of criteria to me.
But don't we already have a universal byte code with JVM bytecode?
Why did the wheel need to be reinvented here? Are there fundamental issues with JVM bytecode that make it impossible/impractical to have c++/rust/LLVM compile to it?
This isn't a troll question. I'm curious what are the fundamental underlying technical issues that made WebAssembly necessary
(please be nice... c++ developer here.. so I'm really clueless about web stuff. I don't even use the JVM)
Also the reason why the only major revision to the MSIL bytecodes was the support for generics.
> Are there fundamental issues with JVM bytecode that make it impossible/impractical to have c++/rust/LLVM compile to it?
Lack of pointers. Lack of true structs. Different memory model. Enforced class/object model.
WebAssembly has a memory model which is very close to a generic CPU.
My understanding of what made WASM necessary -
You don't want a GC? You don't get a GC.
You want full control over your memory layout? You get a raw growable slab of memory with raw pointers.