The first point is news to me, but I suppose you can build anything you want in an open ISA too. It looks like each object is like a shared object with an import and export table that connects things together, so the host would have to have a "modern" variant of a dynamic loader. It sounds like it would be painful to support that without an established way of doing it, that is standardized. So, guess I agree.
https://github.com/fwsGonzo/rvscript
I have done that here. Example:
APICALL(api_math_smoothstep)
{
auto [edge0, edge1, x] = machine.sysargs <float, float, float> ();
x = std::clamp((x - edge0) / (edge1 - edge0), 0.0f, 1.0f);
machine.cpu.registers().getfl(10).set_float(x * x * (3 - 2 * x));
return 0;
}
Good choice on using var-arg-templates for passing arguments between env and host, i think moving over all scripting bindings to va-templatized bindings is the only sane option for the future (boy have i spent time fighting binding bugs in my days)
https://scholar.google.com/scholar?cluster=14979605902538775...
tl;dr security introduces a lot of design constraints that RISC V doesn't have.
section 2.3 on structured control flow:
WebAssembly represents control flow differently from most stack machines. It does not offer simple jumps but instead provides structured control flow constructs more akin to a programming language. This ensures by construction that control flow cannot form irreducible loops, contain branches to blocks with misaligned stack heights, or branch into the middle of a multi-byte instruction. These properties allow WebAssembly code to be validated in a single pass, compiled in a single pass, or even transformed to an SSA-form intermediate form in a single pass.
Also, wasm is a "Harvard architecture" rather than von Neumann (separate address space for code and data), also for security reasons:
section 2.2:
Linear memory is disjoint from code space, the execution stack, and the engine’s data structures; therefore compiled programs cannot corrupt their execution environment, jump to arbitrary locations, or perform other undefined behavior. At worst, a buggy or exploited WebAssembly program can make a mess of the data in its own memory.
However, wasm also leaves some things to be desired security wise. Buffer overflows in C are still buffer overflows once you compile to wasm, and can be chained in to JS exploits.
https://old.reddit.com/r/ProgrammingLanguages/comments/icb9v...
If you try to use RISC V in the same contexts, you'll have the same problems. If you have an additional layer of process sandboxing, then those could be mitigated. But then RISC V is not a wasm replacement.
Although maybe wasm is hopeless for C code, so you need more sandboxing anyway, so then it's on par with RISC V... interesting question.
You can send anything down the wire to the wasm env provided
1. It can instantiate wasm itself
2. Your (whatever) to wasm compiler is small enough and outweighs the downsides of on device compilation (to wasm)
- wasm has modules, "imports", and "exports" for I/O and host communication. The glue is one of the harder parts of the problem.
- wasm bytecode is sandboxable with a simple MMU mapping. That's one reason it has structured control flow rather than goto. (And this is why you need a special algorithm to compile C gotos to wasm.) RISC V certainly doesn't limit itself like that.
So I think this idea is glossing over a lot of details... not all ISAs are equal, especially ones meant to be transmitted over the network!