Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

86Box: Why Not Pentium III?

86box.net

Post reply on HN
Print view View original

21–30 of 102 posts

Re: 86Box: Why Not Pentium III?

#21

Post by phire »

cwzwarich wrote: post #19

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.

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.

Re: 86Box: Why Not Pentium III?

#22

Post by actionfromafar »

zozbot234 wrote: post #10

Arguably, cycle-accurate emulation should be done with FPGA support anyway. The Pentium III is old enough that there should be no legal obstacle to implementing new compatible hardware.

Patents are 20 years, so if you are unlucky, no. Also there are those infamous "submarine patents".

I wonder though about truly ancient x86, why aren't there more clean-room clones of those?

Re: 86Box: Why Not Pentium III?

#23

Post by pornel »

AshamedCaptain wrote: post #15
dusted wrote: post #14

Earlier quoted context omitted.

Let's say I want to emulate my first SMP system, a dual p3 with windows 2000, well, without P3 (and smp) emulation, I can't. If there was SMP P3 emulation, then I could (albeit at horrible speed, at the moment) but at some point, it'd become quite reasonable.

There is SMP P3 emulation. qemu is an emulator, not a virtualizer. There is no cycle-accurate emulation, but again the question is: why would need cycle-accurate emulation to run win2k? It runs just fine on virtualizers, even.

Perhaps for games with DRM?

Re: 86Box: Why Not Pentium III?

#24

Post by AshamedCaptain »

phire wrote: post #17
AshamedCaptain wrote: post #9

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…

> your only goal is running all known software, then you can get away with some massive accuracy bugs.

> Some people want to do retro programming and develop new software for a platform. And if you don't have accurate emulation, then the more likely you are to introduce a bug that works in the emulator but not on real hardware.

The two things go hand by hand. If era-developed software is unlikely to suffer from timing bugs, then _your own software_ is also unlikely to suffer from timing bugs. It's down to the same argument.

It's like claiming that because I developed for Pentium 4, my software is unlikely to work on the Pentium 3. Save for the very explicit case that I use some new extensions, how crazily out of the way would I need to go in order to even remotely hit such an issue?

In fact, it can all be summarized to: what CPU timing would you even emulate ? Why would you even target the P3 _specifically_? Why not Transmeta?

Note that this does not apply to accuracy emulation of accompanying hardware, but then again I would also claim that accuracy of hardware emulation is hardly relevant post-P3, since _the real hardware_ often is massively inaccurate by any definition of the word. Why accurately model a specific Radeon card, when the budget model of the same year is completely different , with the differences abstracted by hacks in the driver ?

Re: 86Box: Why Not Pentium III?

#25

Post by Macha »

phire wrote: post #17
AshamedCaptain wrote: post #9

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…

Neither Xbox or PS2 are emulated at a cycle level though. They mostly rely on recompilation and API emulation, and PCSX2 has gotten pretty far on that. That generation was really the start of cross platform being the norm, and so the start of a dramatic drop off in games requiring very specific hardware details. If your game had to run on Xbox/PS2/WinXP then there has to be some level of portability considered in the software.

Re: 86Box: Why Not Pentium III?

#26

Post by zozbot234 »

actionfromafar wrote: post #22
zozbot234 wrote: post #10

Arguably, cycle-accurate emulation should be done with FPGA support anyway. The Pentium III is old enough that there should be no legal obstacle to implementing new compatible hardware.

Patents are 20 years, so if you are unlucky, no. Also there are those infamous "submarine patents". I wonder though about truly ancient x86, why aren't there more clean-room clones of those?

The Pentium III family was launched in Feb 1999. That's more than 20 years ago.

Re: 86Box: Why Not Pentium III?

#27

Post by actionfromafar »

zozbot234 wrote: post #26
actionfromafar wrote: post #22

Earlier quoted context omitted.

Patents are 20 years, so if you are unlucky, no. Also there are those infamous "submarine patents". I wonder though about truly ancient x86, why aren't there more clean-room clones of those?

The Pentium III family was launched in Feb 1999. That's more than 20 years ago.

Damn I'm old.

Re: 86Box: Why Not Pentium III?

#28

Post by cwzwarich »

phire wrote: post #21
cwzwarich wrote: post #19

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.

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.

Re: 86Box: Why Not Pentium III?

#29

Post by dusted »

AshamedCaptain wrote: post #15
dusted wrote: post #14

Earlier quoted context omitted.

Let's say I want to emulate my first SMP system, a dual p3 with windows 2000, well, without P3 (and smp) emulation, I can't. If there was SMP P3 emulation, then I could (albeit at horrible speed, at the moment) but at some point, it'd become quite reasonable.

There is SMP P3 emulation. qemu is an emulator, not a virtualizer. There is no cycle-accurate emulation, but again the question is: why would need cycle-accurate emulation to run win2k? It runs just fine on virtualizers, even.

But I don't want virtualization, I want cycle accurate emulation of my p3, actually, I want emulation of the underlying chip so that I can run the original Intel microcode on it. I want my bios chips and all that jazz. I want a ship in a bottle, complete with the seven seas and the world to travel. I want it described in software, so it can be emulated, on whatever the future brings, forever.
Post reply on HN