41–50 of 102 posts
Why do people who write emulators all seem to dislike each other?
My friend wrote an NES emulator decades ago and he fit this model. Got into flamewars on Zophar's Domain and such lol
Earlier quoted context omitted.
The question is which software that requires a Pentium III also requires some CPU timing peculiarity. There have been enough CPU vendors that such software would have been difficult to run even at its era. This is not a videogame console where all hardware was the same, or the early PC world were everything was designed for the Intel 8086 timings as on the IBM PC. This is the modern PC world. Which exact CPU model wo…
I'm of the belief that hardware is not truly preserved until you have a fully-accurate emulation of it. You are correctly that software doesn't require fully accurate timings. Just accurate enough to bypass any timing bugs and replicate the experience. Especially outside of the console space. If your only goal is running all known software, then you can get away with some massive accuracy bugs. But there is more to h…
This makes sense in principle, but exact emulation is something computationally prohibitive even for a (probably) 386¹. The computational problems of exact emulation have been described in a famous article about emulating the SNES².
I suppose that emulating even "just" a superscalar architecture is going to be prohibitive (due to the split into micro ops), and an out-of-order one would probably require transistor-level emulation (or at least, another, lower, level of emulation).
¹=Fairly arbitrary; I'm basing this just on the complexity of emulating the SNES, and the following considerations.
²=https://arstechnica.com/gaming/2011/08/accuracy-takes-power-...
Why do people who write emulators all seem to dislike each other?
It's difficult to let go of your code baby, especially when you could technically do it all on your own. It's probably easier when the task is so large there's no way you could do it alone
Earlier quoted context omitted.
I've actually put quite a lot of thought into this topic (but for a different, non-x86 out-of-order CPU) It might not be possible to do it with an interpreter, but a well-designed JIT should be able to shift the cost of calculating instruction scheduling and cycle-costs from execution time to JIT time. Since OoO CPUs spend long stretches of time between branch miss-predicts and L1 cache misses, you can get long seque…
Here’s a paper describing a simulator that worked by similar means: https://dl.acm.org/doi/10.1145/384265.291063 It’ll help, but still won’t get you down to the 10-20x cycle overhead range that you need to claim success.
You a right, they get a 190-360x overhead, and on today's CPUs, I think I need need to get it down to about 20-30x overhead to get realtime on current CPUs. It's only off by a single order of magnitude.
Though, it would be fast enough for some usecases. 10% of realtime would be bearable for some TAS usecases.
It might be possible for me to improve on what they have. For starters, they aren't using a trace-based approach and I think they are applying the memorisation on every single branch, correctly predicted or not, and every single memory access (even when they hit L1). But I would need a 10x improvement over what they had, and that's a big ask.
Something alluded to, but not really elaborated on, is what the motivation is for emulating progressively newer CPUs, versus virtualizing them. With old hardware, the sort I imagine 86Box is mainly used to emulate (it's how I use it, anyway), old OSes rely on specific behavior of old systems and peripherals that can't be easily virtualized through KVM + QEMU or the like. A mixture of processors being too fast and beh…
I recall awhile back Linus Tech Tips pointed out that the primary failure point for old machines wasn't the CPUs which tend to be piling up cheaply (I can't say how true this is for pre PIII parts) but instead the motherboards. I wonder if in some sense there isn't a market for someone to just make new motherboards instead for this stuff using modern parts. I realize there are some licensing issues after a certain po…
https://en.wikipedia.org/wiki/List_of_VIA_chipsets#:~:text=V....
But to your original point: CPUs don't really fail unless abused is my understanding. The bad ones are filtered out at the factory before they ever get to consumers.
I would guess this article is an effort to distance themselves from this dev if people google it
https://www.reddit.com/r/emulation/comments/tjnxg3/why_not_p...
Earlier quoted context omitted.
Windows 9x couldn't even run on ~2007 era Intel Macbooks because of the A20 gate.
The Intel Macs were a strange not-quite-PC-compatible; the BIOS was EFI, and I believe things like the 8042 (which controls A20) weren't present although I'd have to check the schematic to be sure. That said, I'd be surprised if port 92h "fast A20" wasn't present --- that's been in nearly every chipset since ~386 or so.
Something alluded to, but not really elaborated on, is what the motivation is for emulating progressively newer CPUs, versus virtualizing them. With old hardware, the sort I imagine 86Box is mainly used to emulate (it's how I use it, anyway), old OSes rely on specific behavior of old systems and peripherals that can't be easily virtualized through KVM + QEMU or the like. A mixture of processors being too fast and beh…
What about old versions of VirtualBox? As far as I understand, VirtualBox originally used some kind of dynamic recompilation to run on hosts without modern virtualization (like VT-D). It used to run most instructions directly on the host CPU, emulating only certain ones. I think they removed it at some point, though. Is it not accurate enough? I remember it used to run OS-X much better than other virtualizers.
I don't understand,the yuzu (switch) emulator has excellent performance and correctness. It perfectly emulate a modern ARM cpus at multiple GHz and properly emulate the Tegra Nvidia GPU. Why would emulating x86 be so much harder, especially since you can actually use the host x86 cpu... via hardware hyoervisors e.g. https://github.com/intel/haxm
86Box is not entirely cycle accurate, but much more accurate than QEMU, so no patches are required.
gem5 is on the other end of the spectrum, it can emulate hardware very accurately, but very slowly.
Article claims it’s not possible to emulate a Pentium III at full speed on an Apple M1, and so there’s no point to a fork attempting this feat. But isn’t that exactly what Rosetta 2 does?
The original Rosetta software provided during the PowerPC to Intel x86 transition was an instruction and system call translation layer. I haven't used Rosetta 2 but it's probably similar.
As I understand 86Box is emulating specific chip implementations and all of the peripherals, cards and boards needed to run them, not just translating instructions. This makes the emulated machines appear to the guest OS as real hardware, I assume with all the flaws and quirks included.