1. 19
    1. 1

      So: Can we make uxn virtualizable, so that an uxn hypervisor can manage one or more child virtual machines, each running a program presented with a seamless illusion that it’s the only software on the machine? Let’s find out!

      Uh, you can do that already. By running multiple uxn interpreters ?

      Like, not to say this isnt a cool implementation or a good toy project, but I don’t see what the difference in this context between a hypervisor and a normal interpreter, given that there already isn’t any “shared rom” in the spec ?

      1. 2

        Totally! Analogously, there’s nothing virtualization can achieve that actually running multiple physical computers can’t.

        One difference is that the hypervisor code doesn’t include an instruction interpreter. The native interpreter is used directly. Another is that the “wiring” between virtual machines is implemented in terms of uxn constructs, where running multiple uxnemu processes brings Unix IPC into the mix.

        1. 1

          I would have thought this enables you to run 2 uxn programs on the same hardware without Unix or any OS at all? Or am I misunderstanding what this does?

          I thought uxn usually runs on machines with no OS?

          Or do you need an OS to run the hypervisor?

          1. 1

            Having a virtualization facility allows that, yes. But you still need a base interpreter of some kind: there are no chips that interpret uxn opcodes. The base interpreter might be on the bare metal, with no other OS involved. What adding virtualization gives you is a way to run nested VMs at “native speed” (the speed of the base interpreter) while also fully virtualizing the resources used by each nested VM.

            There’s a kind of grey area among OSes, interpreters, language runtimes, hypervisors and supervisors generally. They all do very similar things.