A 64-bit Dynamic Recompiler has come to town!

[Richard42]

It's in the mupen64-amd64 SVN trunk right now. It was a large effort - I basically duplicated all of the 32-bit dynarec source files, renamed it to x86_64, and rewrote the whole thing to operate natively on x86_64 CPUs, but only using the 32-bit operations for maximum compatibility with the current 32-bit code and thus fewer bugs. It's a little slower than the 32-bit dynarec right now (it will take more memory as well, as the 64-bit code takes more space), but after optimizing the code to take advantage of the bigger registers and expanded register file of the x86_64, it will probably be faster (or take less CPU to run at real-time speed). It's not perfect yet, some games throw exceptions - so there's at least 1 bug left. But SM64 and mkart played perfectly. This is one of the most fascinating pieces of code that I've ever worked on. It is structured as self-modifying code: the C code (after compilation, at run time) writes assembly code translated from the r4300 state machine to the Intel/AMD CPU, then it assembles and runs it. And the running automatically-generated assembly code can call back into the functions in the C code. Quite ingenious.

Once I fix the outstanding problems and optimize it, I'll make a new release of mupen64-amd64. Until then, beta testers are welcome as usual to get the source from svn and play with it. Report any issues or observations here.

[Toasty]

Great news!

[smcd]

I'm not sure if this fix is already incorporated in your code or not, but http://www.emutalk.net/showthread.php?t=41210 post #2 anyhow nice progress

[nmn]

I need to hurry up and finish the massive rom browser modifications i'm making. I accidentally started playing Cave Story on my GP2x as i discovered it and if anyone here has ever played that you'd know its very addictive.

Also I shall check out the problems with the wireless X360 controllers soon - I can't get it to work though, even with the latest kernel built off of GIT it still doesn't seem to properly connect to the controller. I hold down the sync button on the receiver, then on the controller, they appear to connect but then the controller continues to blink its round led and no /dev/input/js* or /dev/js* appear. The receiver does get outputted in dmesg, but no error is outputted when the controller appears to connect and then doesn't. If anyone knows whats going wrong here please tell me so i can mess with blight. For the record it does work properly in my Windows XP Pro installation.

Anyways, back on topic, this is great news, the main goal was to have a 64-bit recompiler and it appears that its not long before it will be mature with the way things are going. I shall reboot and check this out immediately.

[Richard42]

I'm not sure if this fix is already incorporated in your code or not, but http://www.emutalk.net/showthread.php?t=41210 post #2 anyhow nice progress

Thanks for the link. That was some kind of fix for the macos port - I have also modified the same code in the new 64-bit recompiler, but I don't think that fix applies.

[Surkow]

Woah good work with the Dynamic Recompiler. I'm looking forward to the new rom browser. And nmn...what driver are you using for your xbox360 controller? I thought for the newest kernel a device node in "/dev/input/joystick" has te be created. But it seems for me that it's created in "/dev/input/".

[nmn]

Actually, i got a modified Xpad driver off of some forums and viola - it worked great. Couldn't be happier about the way it works - and unlike the mentally retarded microsoft drivers, L and R are seperate axes in the Linux drivers.

edit:
http://www.2shared.com/file/2660323/...2/xpadtar.html

There we go. Note that unless you are using the GIT version of the Linux kernel you will need to modify your kernel source path. If you are using a distro which links the latest kernel source to a generic path /usr/src/linux will probably work, but not all distros will do this.

[Richard42]

Great news, I believe I have fixed the remaining bugs in the 64-bit dynamic recompiler. The last one that I found was also present in the 32-bit dynarec build, but it never caused a problem for me previously. I wonder if anyone else saw any 32-bit dynarec crashes? Anyway, those of you with 64-bit machines and SVN access, please test this build and report any crashes. Thanks!

[MIO0]

The latest dynarec gives me segfaults in s(n)printf when the GFX plugins update the FPS in the window title. It appears that the stack pointer is not 16 byte aligned before calling C functions, which violates the AMD64 ABI. The sprintf and snprintf functions on my system use the MOVAPS instruction, which requires a 16 byte aligned address, with stack data.

[Richard42]

The latest dynarec gives me segfaults in s(n)printf when the GFX plugins update the FPS in the window title. It appears that the stack pointer is not 16 byte aligned before calling C functions, which violates the AMD64 ABI. The sprintf and snprintf functions on my system use the MOVAPS instruction, which requires a 16 byte aligned address, with stack data.

I made a change which should fix this. Please update, recompile, and test again. Thanks!