hi all, first and foremost sorry for the bad joke, the misspelling of think is deliberate.

anyway i was sitting around in the CSE (computer science engineering) lounge at UNSW and for some reason we were talking about emulators. First we were discussing the problems with completely recompiling an executable for another platform, and in the end decided it would probably be feasible assuming you had >= the number of registers used by the target program, other than that it would just be too complex.

the interesting idea that came up however was that the recompiler is constantly analyzing and recompiling blocks of EE machine code to i386/ia-64 machine code. the question is is it possible to save a recompiled block so that it does not have to be recompiled every time its needed. Its kind of like how functional languages use the idea of thunks for lazy evaluation, a thunk can either be evaluated or unevaluated. If it is unevaluated, when it is needed it will be evaluated and the result will be used, if it is already evaluated then the result is used. An example i can give is

f x = x + 2
g y = (f y) + (f y)

this will be optimized out so that the thunk containing f y will be used twice, and only evaluated once.

The reason this would work is because most code spends 90% of its time within 10% of the program, so that portion would be recompiled first and after that point there would already be a significant speedup.

as a disclaimer, i have literally only the faintest idea about how PCSX2 works, to be honest ive had a poke around in the sources and its scary. It could very well be that this is already done, or completely unnecessary because the time to recompile a block is insignificant compared to time taken by register thrashing.

Quote:the question is is it possible to save a recompiled block so that it does not have to be recompiled every time its needed.

Isn't that the whole point of a recompiler?
I'm not sure if I understand what you mean...

(12-13-2008 03:08 AM)Nneeve Wrote:  

Quote:the question is is it possible to save a recompiled block so that it does not have to be recompiled every time its needed.

Isn't that the whole point of a recompiler?
I'm not sure if I understand what you mean...

Im under the impression that blocks are recompiled at runtime when they are needed. I could be completely wrong.

(12-13-2008 02:24 AM)sayuke Wrote:  the interesting idea that came up however was that the recompiler is constantly analyzing and recompiling blocks of EE machine code to i386/ia-64 machine code. the question is is it possible to save a recompiled block so that it does not have to be recompiled every time its needed.

This is exactly what Pcsx2 does. Recompiled blocks are saved into large buffers for future use. On occasion blocks must be invalidated, either because of TLB changes (memory mappings / addresses are re-arranged), or because the buffer gets full. When the buffer fills up you'll get one of these messages:

EE recompiler data reset
IOP recompiler data reset

(the latter being the IOP processor's recompiler, which is a separate entity).

The EE's recompiler buffer is 16 megs, and the IOP's is 8 megs. There is also the VU recompiler, which is a good bit more complex and, for games that make heavy use of the VUs, can end up doing a lot of repetitive work. But it's hard to avoid since VU programs are literally generated and uploaded dynamically by PS2 apps, so you can't ever assume that one program is the same as a previous one. The current VU recompiler actually does an MMX/SSE optimized memory compare of the current VU program being uploaded against the 10 previous programs run. If it matches, it uses that recompiled program. If no match, it recompiles. We might improve that algorithm in the future.

As far as the EE and IOP are concerned, in many games there is little or no recompilation done after the initial startup sequences of the game. Even games that do TLB remappings tend to only need to recompile some IOP code (which is very fast compared to the much more complicated EE recompiler).

So yeah, there's probably no magic "easy" fixes to make the recompiler 90% faster. It's already pretty incredibly efficient as it is.

neat. some day i must give my self some time to hack on pcsx2. right now i spend all my time on robocup doing the vision stuff, and im pretty sure after im done with that ill be needed on the locomotion.

Just a newbie question... Why exactly are the recompiler buffers limited to 16 and 8 Mb? Is it something related to the ps2 hardware or is it just some nice number that allows a lot of code to be stored, possibly more than ever will be needed?

(12-13-2008 09:22 AM)Dantemss Wrote:  Just a newbie question... Why exactly are the recompiler buffers limited to 16 and 8 Mb? Is it something related to the ps2 hardware or is it just some nice number that allows a lot of code to be stored, possibly more than ever will be needed?

as a best guess, as its been shown im no expert, those buffers are where the chunks of recompiled code are stored. The ps2 only has 32 mb of memory, and ive never seen an executable bigger than about 4 mb. actually thats not true, windows doesnt have a (proper) dynamic linker, and ppl like distributing statically linked code, so if you consider statically linked code perhaps its feasible, but 16 mb would be more than enough to store the code section of a game.

(12-13-2008 09:22 AM)Dantemss Wrote:  Just a newbie question... Why exactly are the recompiler buffers limited to 16 and 8 Mb? Is it something related to the ps2 hardware or is it just some nice number that allows a lot of code to be stored, possibly more than ever will be needed?

The 16 / 8 mb buffer sizes are self-imposed by the emulator due to PC hardware limitations. They were selected many years ago when the idea of using larger buffers would have seemed excessive. By today's standards the buffers are probably undersized, considering most PCs have a minimum of 1GB of ram, but on the other hand making them larger wouldn't really improve performance anyway.

In the event we run into some games that actually end up doing semi-frequent EE/IOP recompiler resets, we might consider enlarging the buffers at that time. For now though I don't know of any, so it's not really an issue.