Had an idea of trying to "script" things for games, the idea was to use a the WASM backend of a regular C/C++ compiler to generate code that could be loaded dynamically and share structures (ignoring sandbox for this) so that testing could be done seamlessly, sadly WASM seems to be 32bit for the time being (atleast for Clang, dunno about GCC but that has other issues), also looked at Risc-V and missing export/import tables looks like it could make things far more complicated (might still try using Risc-V though since i'm thinking of generating syscall tables automatically along with Elf-loading)

Sounds awesome. I have some abstractions for making interfacing easier, but I don't have any auto-generated structures.

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;
    }

"machine" is an argument to each system call handler, so you can have multiple machines for many purposes. For example, I suspect you can use a machine as a savegame - because they are serializable.

Oh! So the emulator i was looking at was yours, it looked damn nice for just this task and i guess i know why now :D

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)

The wasm paper covers these issues, and is short and pretty readable:

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.

I think if you did RISC-V you would have to convert asm -> wasm so that you could recover the CFI information.

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)

You don't have to have the executable code in-memory for RISC-V emulation.