3 ms·

As far as I can tell it does not feature a recompiler, only an interpreter. Emulator recompilers are very tricky to get right. Since you're working directly wit

by simias 8y ago

As far as I can tell it does not feature a recompiler, only an interpreter. Emulator recompilers are very tricky to get right. Since you're working directly with machine code instead of nice bytecode you generally need a bunch of heuristics to avoid optimizing something that shouldn't be optimized (register access being an obvious candidate). Furthermore machine code (especially for older consoles) tend to use self-modification liberally so you need to figure out the right heuristic to invalidate your recompiled cache when the machine code is modified. In general for these very old systems (anything 8bit these days I'd say, and even 16bits if you're only targeting the desktop) a recompiler is probably more trouble than it's worth.

amelius 8y ago
> In general for these very old systems (anything 8bit these days I'd say, and even 16bits if you're only targeting the desktop) a recompiler is probably more trouble than it's worth. I guess that's also because modern CPUs can easily handle very old systems, which were relatively slow, and hence software written for it had to be efficient. However, if emulating e.g. ARM on i86 (or vice versa), I guess that recompiling optimizations may be necessary to keep things efficient. Of course emulating JITted code can be a pain because of self-modifying code. Wondering: does VirtualBox use such approach?
- monocasa 8y ago
  > However, if emulating e.g. ARM on i86 (or vice versa), I guess that recompiling optimizations may be necessary to keep things efficient. Depends on the ARM in question and how dependent on cycle accuracy the rest of the system is. Anything more than ~100MHz you pretty much need to JIT, but a surprising number of systems don't reach that. So like a DS is generally interpreted, but a 3DS is generally JITed. > Wondering: does VirtualBox use such approach? VirtualBox uses a combo approach depending on the host. 32 bit host uses a very simple JIT that runs ring 0 and runs all guest code in ring 3. The JIT hides itself using the segment registers. It's mainly to emulate the few instructions that don't fulfill Popek & Goldberg on x86 (ie. instructions that act different in ring 0 vs ring 3, but don't trap). It'll also play with the page tables to know when self modification occurs. 64 bit host is way easier. Pretty much just relying on hardware virtualization, and interpreting a single instruction here and there when you get a trap out of hardware virtualization into the hypervisor.
- simias 8y ago
  >I guess that's also because modern CPUs can easily handle very old systems, which were relatively slow, and hence software written for it had to be efficient. It's that but it's actually worse than that: power aside, one hertz for one hertz, modern systems are generally much more recompiler-friendly than a GameBoy or Atari. The reason is that modern software is written using high level abstractions, you have well defined firmware interfaces, self-modifying code has become the exception instead of the rule etc... That lets you make simplifying assumptions that can speed things up greatly. For instance "I don't have to worry about self modifying code unless I encounter a call to the firmware's flush_cache method". That's better than "I need to be careful with every write to memory because it might potentially write to code instead of data or registers". Back in the days it wasn't rare to find timing loops that required cycle-accurate emulation, for instance because the drawing code expected that the delay between the interruption until a certain instruction was executed was precisely n cycles. I doubt many people do that on a PS4, actually I would be surprised if you could make something like that work between all the various hardware revisions and firmware updates. So older hardware generally requires the emulator to be a lot more strict which often means that you end up with a comparatively slow recompiler. Given the complexity of a recompiler compared to a simple interpreter it's simply not worth it anymore for these old systems.

by simias 8y ago

amelius 8y ago

> In general for these very old systems (anything 8bit these days I'd say, and even 16bits if you're only targeting the desktop) a recompiler is probably more trouble than it's worth. I guess that's also because modern CPUs can easily handle very old systems, which were relatively slow, and hence software written for it had to be efficient. However, if emulating e.g. ARM on i86 (or vice versa), I guess that recompiling optimizations may be necessary to keep things efficient. Of course emulating JITted code can be a pain because of self-modifying code. Wondering: does VirtualBox use such approach?

monocasa 8y ago
> However, if emulating e.g. ARM on i86 (or vice versa), I guess that recompiling optimizations may be necessary to keep things efficient. Depends on the ARM in question and how dependent on cycle accuracy the rest of the system is. Anything more than ~100MHz you pretty much need to JIT, but a surprising number of systems don't reach that. So like a DS is generally interpreted, but a 3DS is generally JITed. > Wondering: does VirtualBox use such approach? VirtualBox uses a combo approach depending on the host. 32 bit host uses a very simple JIT that runs ring 0 and runs all guest code in ring 3. The JIT hides itself using the segment registers. It's mainly to emulate the few instructions that don't fulfill Popek & Goldberg on x86 (ie. instructions that act different in ring 0 vs ring 3, but don't trap). It'll also play with the page tables to know when self modification occurs. 64 bit host is way easier. Pretty much just relying on hardware virtualization, and interpreting a single instruction here and there when you get a trap out of hardware virtualization into the hypervisor.
simias 8y ago
>I guess that's also because modern CPUs can easily handle very old systems, which were relatively slow, and hence software written for it had to be efficient. It's that but it's actually worse than that: power aside, one hertz for one hertz, modern systems are generally much more recompiler-friendly than a GameBoy or Atari. The reason is that modern software is written using high level abstractions, you have well defined firmware interfaces, self-modifying code has become the exception instead of the rule etc... That lets you make simplifying assumptions that can speed things up greatly. For instance "I don't have to worry about self modifying code unless I encounter a call to the firmware's flush_cache method". That's better than "I need to be careful with every write to memory because it might potentially write to code instead of data or registers". Back in the days it wasn't rare to find timing loops that required cycle-accurate emulation, for instance because the drawing code expected that the delay between the interruption until a certain instruction was executed was precisely n cycles. I doubt many people do that on a PS4, actually I would be surprised if you could make something like that work between all the various hardware revisions and firmware updates. So older hardware generally requires the emulator to be a lot more strict which often means that you end up with a comparatively slow recompiler. Given the complexity of a recompiler compared to a simple interpreter it's simply not worth it anymore for these old systems.