Why Can't The Pandora Emulate The Ps2?

[alucart1984]

PS3 doesnt have a PS2 emulator either.

What?

...SNIP
Some PS3s have a software PS2 emulator.
...SNIP

The 80GB PS3 (That can run PS2 games) still has the GPU from the PS2 they just don't have the CPU so its not completely rendered with Software Emulation.
From Wikipedia

"Like the South Korean and European models, the North American 80 GB (2007) model also excludes the PlayStation 2 "Emotion Engine" CPU chip.[77] However, it still keeps the "Graphics Synthesizer" GPU.[82] Due to the elimination of the "Emotion Engine", the level of compatibility was reduced.[77] The 40 GB, 80 GB (2008), and 160 GB models have two USB ports instead of the four USB ports on other models, and do not include multiple flash card readers, SACD support,[83] or any backwards compatibility with PlayStation 2 games.[20][77] This was due to the removal of "Graphics Synthesizer" GPU, which stripped the units of all PlayStation 2 based hardware.[84][85]"

This is the CPU in the PS2
Once again from Wikipedia
"CPU: 64-bit[2][3] "Emotion Engine" clocked at 294.912 MHz (299 MHz on newer versions), 10.5 million transistors "

Sorry but I just didn't want people to get confused and say if the PS3 can do PS2 via Software Emulation then why did they not allow the newer PS3 models have it also. It's still a matter of a lack of hardware.

 

[Exophase]

Do you know of any other recompilers that do liveness analysis? I'm not aware of any, and I did it only because I needed a way to reduce the amount of register swapping due to the large number of registers that MIPS has. It's a slightly dangerous optimization since you end up with garbage values in registers if an exception occurs. Because of this I often turn off the liveness analysis when debugging.

When I said "liveness analysis" I didn't mean to imply "assume registers are not live over interrupts".. it's much more general than that. Usually interrupt handling is done between basic block execution and analysis doesn't usually span blocks.

Liveness analysis can still be useful w/o crossing block boundaries. For instance, if you know a previously allocated register is dead you can use that register as a temporary - relying on dead registers for temporaries (and saving/restoring when none are available) means you can reserve more for allocation. Dead flag elimination is also liveness analysis, although occasionally register stores will become dead too (and can be nullified) - this is especially true if you're doing any kind of target platform optimization like copy or constant propagation. The operations used for intermediate calculations that can be propagated may be eliminated, but only if their result registers can be confirmed to be dead after propagation.

I do have a recompiler now which passes liveness information (registers and flags) between blocks, and I am assuming them dead across interrupts. Have you actually ran into any issues with this yet? It might be safer to just do it for flags.

Daedalus does it, sort of. It does hot-path compilation, eliminating the jumps.

Inlining doesn't count ;P

 

[Exophase]

Sorry but I just didn't want people to get confused and say if the PS3 can do PS2 via Software Emulation then why did they not allow the newer PS3 models have it also. It's still a matter of a lack of hardware.

Huh, I always heard it was removed with the Slim, not the 40GB units before it that also had no PS2 hardware. Guess that clears that up.

Although, I wonder if it's really just the GS, because that meant that the especially hard parts were still being done in software, like the VUs..

 

[Jourdy288]

Half of this post was TL so I DR! *CRIES* Why did Exophase get into this thread? WHY?!
Whatever you do, don't mention virtualization.

 

[ari64]

When I said "liveness analysis" I didn't mean to imply "assume registers are not live over interrupts".. it's much more general than that. Usually interrupt handling is done between basic block execution and analysis doesn't usually span blocks.

Liveness analysis can still be useful w/o crossing block boundaries. For instance, if you know a previously allocated register is dead you can use that register as a temporary - relying on dead registers for temporaries (and saving/restoring when none are available) means you can reserve more for allocation. Dead flag elimination is also liveness analysis, although occasionally register stores will become dead too (and can be nullified) - this is especially true if you're doing any kind of target platform optimization like copy or constant propagation. The operations used for intermediate calculations that can be propagated may be eliminated, but only if their result registers can be confirmed to be dead after propagation.

Consider the following MIPS code:

loop:
 lw r8,(r9)
 addi r9,r9,4
 sw r8,(r10)
 addi r10,r10,4
 addi r11,r11,-1
 bne r11,r0,loop
 nop
 or r8,r0,r0

r8 is dead after the store. I designed the dynarec to recognize this, and since r8 is dead, it won't write it out to the register file, and will free that register for re-use.

The problem is what happens if the loop is interrupted. You end up with junk in r8 instead of what's supposed to be there. In practice it doesn't matter since nothing looks at r8, but theoretically the interrupt handler could look at it.

I do have a recompiler now which passes liveness information (registers and flags) between blocks, and I am assuming them dead across interrupts. Have you actually ran into any issues with this yet? It might be safer to just do it for flags.

How does that work? What if the next block hasn't been compiled yet? Are you doing deep recursive compilation? How do you handle self-modifying code that changes the liveness analysis?