Next Generation Emulation banner

1 - 20 of 20 Posts

·
Registered
Joined
·
75 Posts
Discussion Starter #1 (Edited)
I know there is a beta release of Windows XP x64 edition, and was wondering how much extra work it is to reprogram something to work in 64-bit? I don't know if this would require a whole rewriting of the program or just modifying to a smaller extent. I gotta imagine this would greatly improve performance since part of the problem is of PS2 emulation is running in 32 bits versus 128. I'm just suggesting the idea, I have no plans of doing this myself, and thank those who have the programming knowledge for considering this. Thanks.
 

·
Ocean Soul
Joined
·
1,420 Posts
Correct me if I'm wrong, but when they say the PS2 is "128-bit" they are talking about the GRAPHIC cpu and not the main cpu....but I do believe that it too is 32bit(main cpu, not the graphic chip, I know it's 128)...as for the OS question, I believe you have to rewrite it...I'm not sure though....
 

·
Coffee Demon
Joined
·
2,907 Posts
Aided Onslaught said:
Correct me if I'm wrong, but when they say the PS2 is "128-bit" they are talking about the GRAPHIC cpu and not the main cpu....but I do believe that it too is 32bit...as for the OS question, I believe you have to rewrite it...I'm not sure though....
Actually...no.
The PS2 CPU incorporates two 64-bit integer units (IU) with a 128-bit SIMD multimedia command unit, three independent floating point vector calculation units (FPU, VU0, VU1), an MPEG 2 decoder circuit (Image Processing Unit/IPU), and high-performance DMA controllers onto one silicon chip.

That is what makes it's emulation so difficult ;)
 

·
Registered
Joined
·
9,506 Posts
Well, if I am to make an educated guess, the majority of the work would be to rewrite the assembly based core from x86 into x86_64. That said it's more likely that such work be performed on linux, as it's x86_64 support is more stable at the current point of time.
 

·
PCSX2 Coder
Joined
·
10,122 Posts
we might see 64bit pcsx2 in the future, shadow has been kind enough to make some simple framework for it to get the ball rolling, not sure if it will be fully 64bit or if hes just made it to make use of the 64bit processor extensions like x86-64.

we will see :)
 

·
Registered
Joined
·
88 Posts
refraction said:
not sure if it will be fully 64bit or if hes just made it to make use of the 64bit processor extensions like x86-64.
What's the difference between a fully 64 bit and the usage of x86-64?
 

·
PCSX2 Coder
Joined
·
10,122 Posts
Neo-Zacar said:
What's the difference between a fully 64 bit and the usage of x86-64?
the difference is usage of x86-64 just makes use of the extra commands the 64bit chips have (namely the athlons), but to have it fully 64bit will send the data to the cpu all in 64bit format.

altho having it only using x86-64 might cause problems so it might get done all the way ;p
 

·
Super Moderator
Joined
·
6,283 Posts
AFAIK, shadow wants to make it fully 64bit (actually, there are even plans to drop the 32 bit version after a while, since it'll never be able to emulate most games decently)
 

·
Super Moderator
Joined
·
6,283 Posts
bositman said:
Drop the 64bit version? I hope you mean the 32bit version :p
Hmm, indeed, corrected :p
 

·
Registered
Joined
·
425 Posts
Well that's good news for us A64 owners. Must suck for the other guys though. All I know is I've become addicted to save states. It's like my crack.
 

·
Registered
Joined
·
18 Posts
It won't suck to bad. COmputers are slowly all turning to 64 bit. Mircrosoft has even been swearing lately that the next version of windows will only release with a 64 bit version. So like it or not you know they'll be a lot of 64 bit computers in the comming years

BTW, Can't you just take a 64 bit compiler and compile the code on it to make a 64 bit version. I mean, of course it wouldn't be taking full advantage of the 64 bit processor but it should work shouldn't it?
 

·
Registered
Joined
·
9,506 Posts
Well the recompilier core is written in x86 assembly if memory serves me correctly. That would need rewritten from scratch for a start
 

·
PCSX2ベータテスター
Joined
·
1,457 Posts
afaik Interpreter SHOULD work. But the recompiler on the other hand heavily requires that it be a 32 bit machine or 32bit compatible.
 

·
Premium Member
Joined
·
259 Posts
Interpreter should work but emu needs some modifications since type casting is now different since pointer in amd64 is 64 bit (on 32bit pcs it was 32bit). So it needs some work. Also we have to write a amd64 recompiler and modificate all the plugins for 64bit too. That requires a lot of work but we hope that 0.8 will release for 32bit and 64bit modes (32bit mode will last a bit more but soon we gonna abandon it)
 

·
Registered
Joined
·
82 Posts
shadowpcsx2 said:
Interpreter should work but emu needs some modifications since type casting is now different since pointer in amd64 is 64 bit (on 32bit pcs it was 32bit). So it needs some work. Also we have to write a amd64 recompiler and modificate all the plugins for 64bit too. That requires a lot of work but we hope that 0.8 will release for 32bit and 64bit modes (32bit mode will last a bit more but soon we gonna abandon it)
Hmm I'm really curious as to how much faster a 64bit native-version would be... Anybody have a link to a good article explaining what speeds it up? Passing more params per instruction? Also that would mean PCSX2 would require an AMD64 CPU until Intel gets its act together and releases and Intel64, wouldn't it?
 

·
Registered
Joined
·
5 Posts
I certainly hope that the quip about the recompiler core being written entirely in assembly is misinformation or a joke. The emit handlers no doubt emit run-time x86 assembly code, but there is no good reason to write the compiler routines in assembly. This will only serve to make the code much more difficult to understand, especially if complex instruction-selection and code-optimizer logic is added. All of my dynamic recompiler related routines are written entirely in C++ with no inline functions or macros, and the compilation time pales in comparison to the amount of time spent executing the native code blocks. In other words, the routines should efficient, but writing them in assembly probably isn't favored over using smarter compilation methods.

In any case, the only non-trivial modification needed to run in 64-bit mode should be to add support for the REX prefix and to add logic to support the appropriate encoding needed when the REX prefix is used to access the additional registers and such. Other than the slightly annoying need to eliminate unsupported instructions from the emit handlers (INC/DEC/etc), the move should not be very painful, provided the compiler framework was designed with flexibility in mind.

Assuming a full-blown dynamic compiler is implemented for all stages involving executable code, my educated guess would be that the performance of the emulator would be dependent mostly on the graphics rendering (e.g., how much can be offloaded to the video card, particularly the pixel shader unit) and the efficiency of the native code blocks. The latter issue also includes the expense of the dispatch loop and how often the emulator must switch from native code execution to interpretation and/or performing book-keeping.

The main benefit of adding 64-bit support is the availability of the eight extra integer registers. The x86 is register poor and many instruction handlers require the use of all the registers (for efficient implementations) such that register allocation for caching purposes is relatively useless. Having an extra eight registers available for the sole purpose of register allocation is undoubtedly beneficial for the purposes of decreasing reliance on the memory subsystem.
 
1 - 20 of 20 Posts
Top