Pcsx2 64Bit .Exe And PCSX2SP

Commonly, this programs installer has the following filenames: pcsx2 0.9.6.exe, pcsx2.exe, pcsx2-r4600.exe, 1EEFFF72773535163E4216.exe and PCSX2SP.exe etc.

Our built-in antivirus checked this download and rated it as virus free.

Also the tool is known as Pcsx2 Watermoose, PCSX2 R3, Pcsx2 Watermoose 64bit.

The most popular versions among the software users are 1.6, 1.0 and 0.9.

Pcsx2 belongs to Games.

Anyone who wants to keep their sanity should stay away from it.

Most 64bit CPUs today support it, so it looks like a good candidate for 64bit recompilation.

The x86-64 architecture offers many more registers and can potentially speed up games by a significant amount.

Pcsx2 64Bit Code Base Is

Up to now, Pcsx2 has largely been ignoring the 64 bit arena because there have been massive compatibility issues, the developers werent sure if it was really worth it, and adding a new bug-free and fast recompiler to the existing code base is a very painful process.

Anyone seriously suggesting this to a dev would have been laughed out of the chat room.

However, the upcoming 0.9.2 release is looking very stable and after doing some research, we have decided to add support for x86-64 recompilation, both for 64bit versions of Linux and Windows (yes, Linux support is returning).

They are extremely important for testing and debugging purposes.

For example, interpreting a simple 32bit EE MIPS instruction (code) might look like.

For example, we know the instruction at address 0x1000 will never change, so there is no reason why the CPU needs to execute the switch statement and decode the instruction every single time it executes it.

So recompilers generate the minimal amount of assembly the CPU needs to execute to emulate that instruction.

Because were working with assembly, recompilation is a very platform dependent process.

For every new instruction, the used registers are read from memory and stored in real CPU registers, then some instructions are executed, and finally the register with the result is stored back in memory.

Before 0.9, Pcsx2 used to employ this type of recompilation.

There are many different types of register allocation algorithms using graph coloring.

Such compilers might also do constant propagation elimination.

A common pattern in the MIPS Emotion Engine is something like.

At the end of every block, all the registers will have to be pushed to memory because the next simple block that needs to be executed cant be predicted at recompilation time (ie: branch if x 0 depends on the value of x at runtime).

Once it knows, it can get rid of the register flushing at the end of every simple block by simply telling the next blocks to allocate the same real CPU register to the same target platform register.

This is called global register allocation and sometimes uses Markov blankets for block synchronization.

For those people that know Bayes nets, this is very similar, except it applies to the global simple block graph.

Just think about the nodes necessary for making a specific node independent with respect to the whole graph.

This will include the nodes parents, children, and the childrens parents.

So an EE register can be in an MMX, SSE, or regular x86 register at any point in time depending on the current types of instructions (this is a nightmare to manage).

But starting with the PS2, consoles got powerful and the Pcsx2 recompilers for the EmotionEngine and Vectors Units got complex really fast.

Pcsx2 0.9.1 supports all the above mentioned optimizations plus many more unmentioned ones.

The VU recompiler (code named SuperVU) is by far the most complex and fastest.