[whoisthemachine]

> The CPU emulator, ARMeilleure, emulates an ARMv8 CPU and currently has support for most 64-bit ARMv8 and some of the ARMv7 (and older) instructions, including partial 32-bit support. It translates the ARM code to a custom IR, performs a few optimizations, and turns that into x86 code.

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?

[grishka]

> 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.

[jyrkesh]

I think it does beg the question though, of whether it might be possible to dump the Switch OS and firmware and run it on some alternative ARM hardware (with some modifications for redirecting weird custom chips). IIRC the Switch is running an overclocked Tegra (X1?)

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.

[roblabla]

I attempted this a while ago, running the Switch OS (Horizon/NX) on a Jetson TX1. It's definitely possible, *but* it requires modifications to the OS services, otherwise you'll just fry the Jetson (that was a lesson learned the hard way...). The pinmuxing between the two devices is different, so you'd need to modify that at least. And then you'd probably need some more modifications to get joycons to work (how do you sync them without a rail), etc...

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).

[tibbon]

I might be making a bad analogy, but I don't think this would work any better than dumping the CMOS firmware for a C64 (6502 processor) and hoping you could just run it on an Apple II or NES, even though they had the same architecture processor (also a 6502).

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.

[grishka]

As I understand it, there are two ways to approach emulating a console that has a firmware, whether it's a BIOS or a full-fledged OS:

- 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.

[astrange]

There is a Switch emulator using virtualization on M1 Macs.

[Wowfunhappy]

Wow, that’s neat. Link?

[saagarjha]

https://twitter.com/daeken/status/1340777743244509196

[whoisthemachine]

Interesting, Dolpin emulates the Wii and Gamecube OS's to some degree, I would assume that would be necessary for the Switch as well. What would that have to do with ARM assembly however?

[calaphos]

The current ARMeilleure seems to emit x86 instructions directly and execute them, so never really using the intermediate representation of Jit compiler of the .Net runtime.

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.

[worewood]

> However the previous cpu emulator apparently emitted .Net byte code and used RyuJIT (the .Net jit) to emit the final native code.

This seems like a good use case for using .Net. Why did they move away from it?

[astrange]

The .NET and Java VMs probably aren't optimized for the incoming bytecode also being JIT generated, never needing to allocate memory, wanting to be register-based, etc.

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).

[molticrystal]

From https://github.com/Ryujinx/Ryujinx/issues/1884#issuecomment-... :

>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.