Instead of using unsafe Rust to optimize the interpreter loop, I would prefer to write a transpiler that compiles the source UXN binaries to local CPU binaries, which would not require making code unsafe/less readable and would permit further speed enhancements by getting rid of an interpreter loop altogether.
This is an interesting idea, but gets tricky if someone writes self-modifying code!
There are Uxn instructions which write to RAM; normally, this is used for storing data, but nothing prevents programs from editing their own code as they're running.
> but nothing prevents programs from editing their own code as they're running
On some platforms writing to memory mapped in with PROT_EXEC will trigger a page fault and the process will be killed. In other words, self modifying executables are effectively forbidden by design (the workaround is to unmap the memory, map it as PROT_WRITE, modify, unmap, map it in as PROT_EXEC, and resume execution - which is what JITs do on MacOS, for example).
The parent comment was referring to programs running inside the UXN virtual machine, which explicitly supports and endorses self-modifying code. Many of the creators' own programs take advantage of this capability, so any conforming implementation has to find a way to make it work.
There's a better workaround, incidentally, which is to map the same memory to two different address ranges with different access permissions. This allows code in the JIT region to be updated while threads may be running in it.
Instead of using unsafe Rust to optimize the interpreter loop, I would prefer to write a transpiler that compiles the source UXN binaries to local CPU binaries, which would not require making code unsafe/less readable and would permit further speed enhancements by getting rid of an interpreter loop altogether.