x64 version of PCSX2?

[Squall Leonhart]

So I (and others) should push for it harder? Interesting. Well, most games run fine on my laptop, so I guess I don't have that big of a problem (the KH2 1000 heartless battle runs at 60fps throughout for me, and I swear it actually lagged a bit on the actual PS2).

more lag from a NFS game

[devek]

Wouldn't it be quite a bit slower?

MIPS doesn't have things like a stack, so the recompiler would need to be a lot smarter to not end up drowning in 64 bit addresses....

[devek]

I'm going to double post, so suck it! hehe

This is something I have been thinking about a lot actually. The first time I looked at code emitted by pcsx2, I knew nothing about MIPS and thought the recompiler was retarded because most of what it was doing was pointless. Comparing the actual MIPS code against the recompiler changed my tune and made me realize that it was pretty brilliant.

MIPS has like 45 instructions total while x86 has more than you can count. Turning MIPS into good x86 code on the fly is impossible in my opinion.

Turning x86 code to C isn't that hard, even if the C code ends up being more confusing than the machine code. With the limited MIPS instructions, turning it into C should be trivial(or at least much easier than writing a code emitter). It doesn't have to be good C for our purpose, it just needs to identify things like local variables well.

Once you have your crappy C code, you can link into libraries like clang to convert it back into machine code. I don't know if any of you have messed with clang, but it would be perfect for this and incredibly fast. Done properly it wouldn't be that slow, at most it would make game startup take a few more seconds. With how cheap disk space is you could cache most of the result anyway.

To be honest, I know very little about how pcsx2 works so I have no idea how this would even work with the project but it might be easier than rewriting the code emitter for 64 bit heh. I am churning some ideas through my head for this, but I can't promise anything.

[refraction]

The ps2 actually has loads of ops, combined with the fact half of them aren't available in x86, there is no easy quick way to emulate them. On a broader scale, you cant port a games through emulation, its impossible.

[devek]

I wasn't thinking about emulating anything.. I don't even know much about the ps2, but I do have linux on my ps2 and I can compile programs for the r5900l. I understand how the compiler is generating code for it, and I understand the instructions it uses compared to what an x86 compiler would use are very limited.

For example, the game calls a function to see how much damage an attack does. Rather than emulate the function, you analyze it to figure out what it is trying to do and use C as an intermediate medium to dump the result. It doesn't take long to break down a game like final fantasy xii into just a list of functions, which may end up being reduced to very little code at the end of the day when passed through a library like clang.

When it comes to the program dealing with ps2 hardware like the GS or audio, I have no idea what happens next as I haven't written any programs that do that yet. I have a long ways to go, hehe. Right now I am learning vector math just to get something sensible enough to send to the GS.

[refraction]

Well, good luck with that

[devek]

It is the journey, not the destination I have fun learning new things, so I win no matter what hehe.

[Koji]

So I (and others) should push for it harder?

Errr no... I think that is definitely NOT the lesson to take from this thread. The devs are all doing this on their own in their free time while making absolutely no money off of it. While you can certainly suggest things, and you can ask for things... But PUSHING for things will only lead to bad results.

Don't believe me? Check out the world's biggest douchebag thread... That's what happens when you try to push something

[refraction]

Don't believe me? Check out the world's biggest douchebag thread... That's what happens when you try to push something

Yeh, you get your OWN thread!

[rama]

For example, the game calls a function to see how much damage an attack does. Rather than emulate the function, you analyze it to figure out what it is trying to do and use C as an intermediate medium to dump the result. It doesn't take long to break down a game like final fantasy xii into just a list of functions, which may end up being reduced to very little code at the end of the day when passed through a library like clang.

There's the issue though of how unique the PS2 is:
You have several components and sub processors all specialized for their task.
Getting your data to and from these chips requires use of the complicated DMA systems.
You'll find that at the end of the day you have one function to calculate the damage but 123 threaded library functions to get there.
It's the threaded nature with it's queues and handshaking (or lack thereof) that makes this hell to actually code.