Interesting... since .Net is cross-platform and can run on ARM, if it's running on an ARM processor does it just run the instructions directly?
You can't just run random instructions like that. That code is compiled with the assumption that there's the Switch's OS and hardware underneath, which means it will do all kinds of things, like calling directly into the kernel and assuming a particular address space layout, that would crash it under a different OS.
ARM has hardware virtualization. If the host OS supports it, you should be able to make use of it.
IANAL, but in the US at least, I think every person would need to buy their own Switch and dump the software themselves for it to be even remotely legal.
The kernel however runs absolutely fine with zero modifications required. HorizonOS is a microkernel, and all the components are fairly well separated. To make it work on a jetson, you'd only have to replace a handful of services to make it work.
> IANAL, but in the US at least, I think every person would need to buy their own Switch and dump the software themselves for it to be even remotely legal.
Honestly, I'm pretty sure it'd violate the DMCA DRM protections in the US (you'd have to dump some crypto keys and provide them to an EL3 reimplementation, like Exosphere, to run anything below the kernel).
Maybe things are more standard now these days, but the support hardware around it, memory layout, etc... at least for the 6502, made this prohibitive.
- You could emulate the hardware only, on its lowest level, and make the user provide the firmware dump. This makes the emulation more faithful, but sourcing the firmware isn't always easy.
- You could instead go up a layer emulate the firmware interface that games see. This might get you performance benefits, because you now have the freedom to optimize the low-level implementation details for your particular host platform, but that would mean the emulation itself would not be 100% accurate.
However the previous cpu emulator apparently emitted .Net byte code and used RyuJIT (the .Net jit) to emit the final native code.
> if it's running on an ARM processor does it just run the instructions directly?
So maybe? There are some passes in between but one would think it would at least result in very similar instructions.
This seems like a good use case for using .Net. Why did they move away from it?
Also, I haven't tried JITting them but I've always found their bytecodes to be pretty inexpressive compared to a real CPU (or even LLVM).
>Rest assured, this is in our long term plan. Initially, we'll be bringing up ARM support as a dynamic code translation target architecture in the short term, as this is a relatively straightforward thing to add to our existing JIT. This work is already underway.