It's good, but a few issues:

- RISC-V is a large family of ISAs, though Unix platform targets a much narrower definition, the RV64GC. The "Feature table" lists FP and SIMD as "in extension" but doesn't do the same for Memory layout and protection. It's seems inconceivable to me that you would use paging in a WASM-replacement context. Same for instruction length, two-byte instruction depends on the "C" extension.

- There is nothing that prevents RISC-V in the browser from denying the ability to generate code on the fly. Just like, say iOS, it could run in a "W^X" model, that is, writable memory cannot be executed from.

- atomics, again, are part of an extension, the "A" extension. They do not have to be included, and do not make sense IMO in a single-threaded WASM replacement context.

All that said, WASM is well designed. The structured control flow is a bit painful for some producers and the lack of tail recursion elimination is criminal, but running running/JITting RISC-V in the browser would almost certainly add more overhead.

Very interesting, and thanks.

> the running code is not even provided with a way to access itself.

You can do the same thing with some ELF post-processing. I have done this, and used it over several months now. It works just fine, even though there is nothing in the RISC-V standard that explicitly says this must be true.

I asked the GCC people and they consider it a bug if there's any data in the text-segment. So, at leas there is that. Maybe we can call it optional support? :)

I wonder which leads to a faster emulated machine?

Assuming the same implementation effort & skill: WASM, hands down (disclaimer: I have significant RISC-V experience and am an stout advocate, but RISC-V is a poor replacement for WASM).

ADD: a few of the reasons:

- When JITing RISC-V you cannot tell which are the last use of registers without a very expensive whole-graph analysis. Without that, you will have to generate more code than necessary.

- WASM's representation is very close to what you want in the compiler. In particular, you can directly tell all incoming control-flow edges, which makes analysis much more precise, gives optimization opportunities you would otherwise miss. Recreating this information from a binary is either impossible (due to computed branches) or expensive both in terms of analysis and the guards you have to generate to protect your assumptions.

Your comment made me idly wonder if there's a way to make an ISA which lends itself both to fast (even for low-gate implementations) hardware, and to fast JIT-ing.

I suspect these are conflicting goals but an interesting question. My idle pondering are on ISAs that minimize the challenges in wide superscalar OoOE.