4 ms·

It’s probably not even possible to emulate the Pentium Pro (or any other out-of-order x86 CPU) in a cycle-accurate fashion at the original speeds on contemporar

It’s probably not even possible to emulate the Pentium Pro (or any other out-of-order x86 CPU) in a cycle-accurate fashion at the original speeds on contemporary hardware. Just attempting to match the original behavior for instruction scheduling, cache models, branch prediction, etc. would blow your CPU budget.

phire 5y ago
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 sequence of instructions that executing with the exact same timings every time. A tracing JIT is perfect for this usecase. You just need to normalise the pipeline state on entry (and this since this normally happens after a miss-predict, the pipeline is often drained), and then exit on every branch miss-predict or L1 cache miss and start a new trace. I suspect such a scheme might be fast enough for a Pentium III, I just need to find some time to actually try out my ideas at some point.
- cwzwarich 5y ago
  Here’s a paper describing a simulator that worked by similar means: https://dl.acm.org/doi/10.1145/384265.291063 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.
  - phire 5y ago
    Thanks, I've never encountered that paper before. 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.
mhh__ 5y ago
Some anecdata: gem5 is a simulator that aims to do precisely all that, and yes it is extremely slow. Probably on the order of 100x slower, but I don't have timings to hand. Similarly booting a small processor compiled into C++ with verilator is very taxing on the processor too.
ant6n 5y ago
Why would u want to do cycle accurate emulation? Software ran on a wide variety of different software, I doubt there’s any software that relies on cycle accuracy for a Pentium pro level machine. And afaik, box86 is about running software, not modelling some specific machine exactly.

phire 5y ago

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 sequence of instructions that executing with the exact same timings every time. A tracing JIT is perfect for this usecase. You just need to normalise the pipeline state on entry (and this since this normally happens after a miss-predict, the pipeline is often drained), and then exit on every branch miss-predict or L1 cache miss and start a new trace. I suspect such a scheme might be fast enough for a Pentium III, I just need to find some time to actually try out my ideas at some point.

cwzwarich 5y ago
Here’s a paper describing a simulator that worked by similar means: https://dl.acm.org/doi/10.1145/384265.291063 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.
- phire 5y ago
  Thanks, I've never encountered that paper before. 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.

mhh__ 5y ago

Some anecdata: gem5 is a simulator that aims to do precisely all that, and yes it is extremely slow. Probably on the order of 100x slower, but I don't have timings to hand. Similarly booting a small processor compiled into C++ with verilator is very taxing on the processor too.

ant6n 5y ago

Why would u want to do cycle accurate emulation? Software ran on a wide variety of different software, I doubt there’s any software that relies on cycle accuracy for a Pentium pro level machine. And afaik, box86 is about running software, not modelling some specific machine exactly.