[blog] Introduction to Dynamic Recompilation

[her34]

Thank you everyone for detailed response. Very insightful.


Seeing all that makes me curious about what theoretical speed an intel cpu would need to be at in order to emulate ps2 100% through interpreter.

Is it possible to calculate a quick rough estimate?

[pseudonym]

Entirely depends on the code being run and the R5900 is by no means all there is to the PS2. It has coprocessors and custom chips which use more CPU time.

[her34]

Although many variables can affect, could a general ballpark be estimated?

If you calulate worst case scenario for each component (max cycles to interpret) multiplied to clock speed, and then sum up would that give ball park? or are there more things to consider?

for example:
ps2 cpu core @ 299mhz = 5 cycles to interpret --> 1495 intel cpu cycles
ps2 fpu @ 299mhz = 5 cycles to interpret --> 1495 intel cpu cycles
ps2 vu0 @ 150mhz = 5 cycles to interpret --> 750 intel cpu cycles
ps2 vu1 @ 150mhz = 5 cycles to interpret --> 750 intel cpu cycles

Graphics Synthesizer @ 147 MHz = ?

Total intel cpu cycles = ?

[pseudonym]

The worst case is absolutely ridiculous, you don't even want to think about it. It's just depressing. Fortunately it has nothing to do with running real software.

[Air]

If you calulate worst case scenario for each component (max cycles to interpret) multiplied to clock speed, and then sum up would that give ball park? or are there more things to consider?

for example:
ps2 cpu core @ 299mhz = 5 cycles to interpret --> 1495 intel cpu cycles
ps2 fpu @ 299mhz = 5 cycles to interpret --> 1495 intel cpu cycles
ps2 vu0 @ 150mhz = 5 cycles to interpret --> 750 intel cpu cycles
ps2 vu1 @ 150mhz = 5 cycles to interpret --> 750 intel cpu cycles

Typically an interpreter costs a lot more than 5 cycles per instruction. It costs about 40-60 cycles just to load and decode the MIPS instruction and dispatch it to the interpreter's instruction executor. Actual instruction execution usually takes 4-20 cycles -- 4 being the bare minimum.

[her34]

Typically an interpreter costs a lot more than 5 cycles per instruction. It costs about 40-60 cycles just to load and decode the MIPS instruction and dispatch it to the interpreter's instruction executor. Actual instruction execution usually takes 4-20 cycles -- 4 being the bare minimum.

Well, I was just pulling numbers out the air. I don't know anything about emulation. I was hoping someone here with more knowledge would give a more educated guess.

[pseudonym]

Well decoding MIPS instructions is certainly tougher than SL3 or SL4, but 40-60 cycles to fetch and decode is a bit excessive I think. The fetch stage is slow because of vtlb, but that can be skipped for anything but PS2 linux. Our decode is also suboptimal... though if we're talking worst cases you have to use up to three tables before you have the actual instruction.

EDIT: Never mind, cached memory accesses are slower than I thought. 60 cycles is actually optimistic.

[james broad]

The advantages of dynamic recompilation are:
more speed
more speed (nothing else really)

The disadvantages of dynamic recompilation are:
quite complicated
hard to debug
not as exact as interpretive emulation
not portable to systems with other processors
problems with self-modifying code

This means, as long as you can pull the whole emulation off at a decent speed by using traditional emulation (perferable even a portable solution), just do it and don't give dynamic recompilation a second thought.
Although I've seen people toying with dynarecs for 6502 and similar 8-bit processors it's not worth the hassle, since a nice CPU core written in C would be portable to different systems and should run at full speed on any current and even most older computers.

Even most 16-bit processors should be tried in interpretive emulation before thinking of dynamic recompilation. One of the few reasonable 16-bit candidates would be the 68000, because it is widely used and quite complex, so a dynarec for it might speed up a lot of emulators if you stick to the same API.

Where dynamic recompilation really shines is 32-bit and 64-bit processors, because it makes sense to do operations on hardware registers when the original code does so. Especially the MIPS (used in PSX and N64, eg.) and SuperH (Saturn eg.) processors with thei

[refraction]

This means, as long as you can pull the whole emulation off at a decent speed by using traditional emulation (perferable even a portable solution), just do it and don't give dynamic recompilation a second thought.

Yeh thatd be a no go with ps2 emulation unfortunately. So much work has to be done, itd run at sub 10fps even on a high end computer. The advantages of dynarecs completely outweigh any of its downfalls in are scenario.

Also if you are careful, you can avoid most situations where the code would be unreliable, you just have to make sure you manage your register information properly and dont give it chance to get screwed up.

[cottonvibes]

The disadvantages of dynamic recompilation are:
...
not as exact as interpretive emulation
not portable to systems with other processors

Those 2 in practice are usually true, but they don't have to be.
A dynarec can be just as accurate as an interpreter if coded that way (it can even be cycle-accurate). Whether or not this is practical (implementation and speed-wise) depends on the architecture you're emulating.

A dynarec could also be portable to other processors if you use an IL (Intermediate Language) or IR (Intermediate Representation), and then you generate the platform specific code using different back-ends according to the IL that was generated.
This is more work though, and can be slower than a native dyanarec, so its usually not done by most emulators. Those that make a java-bytecode or CIL dynarec do retain portability though.