
My branch here is already synced up with most of tellowkrinkle's changes.

But we got this :-) I noticed you are a reviewer on tellowkrinkle's PR about making the interpreter work on 圆4/Unix. Also, the convenient SIB 32 addressing cannot always be used as before. There's a lot discussion about eXx registers vs the rXx registers.
#PCSX2 GITHUB HOW TO#
We are discussing the pseudo assembler and C-code on how to address those changes. recLUT and recLUTReserve_RAM are now 8-byte wide. We fixed a bunch of broken emitted code, some 4-byte/8-byte pointer issues, and partially the entries in the LUT, but it is still work in progress. Optimizations are not the primary focus, we're still struggling to make it work in general.

#PCSX2 GITHUB CODE#
Personally, here's what I think the code should look like (using e** as 32-bit registers and r** as 64-bit We are trying to port the recompilers to x86. Instead we can calculate correct number to wrap around a 64-bit integer in BaseblockEx.h and continue to use the optimization. The unoptimized version would have stored page-table-pointers directly here (with reclut = (uptr)mapbase) and would have anded ebx with 0xFFFF before jumping. I'm pretty sure the whole thing you described was an optimization to go faster.Note: My personal opinion on how to do this switch cleanly is to define some new registers (maybe e**d) to temporarily be our 32-bit registers, migrate all uses of e** to either r** or e**d, then delete the e** registers and use an IDE's rename function to rename all uses of e**d back to e**.We should either do the switch over to 32-bit e** registers (and change all uses that need to be 64-bit to the r** registers), define some new 32-bit registers, or use eax.GetNonWide() I don't know what your opinion is on the "should e** registers be 32 or 64 bits" argument, but as it stands, right now they're 64-bit. and use them to index psxRecLUT // Normally we would want to jump to ((uptr*)ecx) // but as an optimization ecx already has the top bits of ebx subtracted from it // so we can just add and jump xJMP( ptr32 ) īased on these, a few things with the new code: and ebx xSHR( eax, 16 ) // psxRecLUT is a 2-level page table so first get the top 16 bits xMOV( ecx, ptr ) //.
#PCSX2 GITHUB PC#
XMOV( eax, ptr ) // Load the PS2 PC into eax xMOV( ebx, eax ) //. Also, I understood you wanted to replace the entire part, so I won't focus too much on optimizations "in the old code". I noticed when I printf many thousands of debug lines to the terminal (I had 10 or 20 in there for each pseudo assembly code so that the buffer of the terminal wasn't enough), the load time for the game becomes long, but the game itself was fine. I'm not so much worried about performance at the moment. When you guys say "there are only 32bit displacements", is that referring to the EE? I guess this comes back to my question about what to do with the LUTs. So far, it did fix the two "mov 64bit-offset" / "mov 64-bit immediate" in _DynGen_DispatcherReg, see above byte code. So the s32 displacement topic is still giving me a headache. XJMP( ptr32 ) // jump ( (c + b) )Įbx is loaded with the stack pointer 0xbfc0 0000, then the value retrieved from recLUT causes ecx+ebx to overflow. XMOV( ecx, ptr ) // c = (recLUT + (a * 4))

With the current livecheck on the script I am getting Error: pcsx2-dev: Unable to get versions. Therefore I aim to get the version from the name of one of the downloadable assets. The version of the app is not fully stated on the release's tag, but on its assets. I am making a cask for PCSX2, but I have not been able to do a suitable livecheck for it.
