[repsilat]

Kinda annoying, but not surprising. VMs and bytecode formats make simplifying assumptions based on the languages they expect to be hosted on top of them, and that usually means "Something with control flow like C."

Creative uses of computed jumps, messing with the stack, dynamic codegen, all sorts of weird things your new language might do to efficiently implement some new control or data structure aren't likely to be possible.

At least in the short term nobody is going to be too upset. Today if something needs to wring all the power available from your CPU it isn't reasonable to put it on the web. That will continue to be true. WASM is the wise 80% solution, not a toy for ASM hackers and people messing around with weird prototype programming languages.

[ajross]

The reason behind the limited branching instructions in wasm is validation, not compatibility with C. C compilers on real architectures emit all sorts of crazy indirection mechanisms.

[repsilat]

Right -- the control flow allowed is basically the simplest thing that will allow you to make a C-like language in a relatively efficient way. It isn't aimed at any particular compiler, it's aimed at supporting some semantics.

Providing additional flexibility on top of those semantics is "expensive" in terms of implementor-time and effort to get safety, portability and future-proofing. There's no promise that the fun extensions they might want today go "in the right direction", and the cost of going down a bad path is high for standards.

[xuejie]

Curious if we're gonna have a complete redesigned virtual machine without considering C-like conventions, how do you think we should do that?

I've heard about alternative CPU architectures in the Lisp machine days that never gone popular, and just wonder if there're such things in the modern era.

[repsilat]

Mostly I'm annoyed because I wanted to try out a bunch of x86 assembly tricks to implement coroutines, and I wanted to try making a language that would spit out and execute its own machine code to do C++ templates at runtime. Those sorts of things get harder when they don't fit the programming model of the people who designed the language/VM.

Of course, portability and safety are going to be problematic there, and those can't be compromised on for a project like WASM. And even if I can't get the power I want out of the base programming model, I can approximate it more slowly in other ways. Turing completeness and all that.

I'm not familiar enough with how CPUs are laid out to know whether a hypothetical instruction set or programming model is supportable in silicon and I haven't read or thought much about it either. In any case I think that would be pretty far outside the scope of what WASM is trying to do.