Static Recompilation .. ?!
#21
Well. First of all, there is a kind of operations named "jumpes". For example, jump on calculated address, that stored in some register. If we do static compilation, than we should store virtual store table for EVERY operand of code (or we could have a lot of NOPs and translate one command in fixed lenght sequence, but it's stupid choice). Right now such jumpes triggered new translation sequence (well, I look at this code 2000 revisions ago, so it could be changed), and vtlb addressing routine is highly effective.

Second, there is self modifying code, that simple could not be staticaly translated at all. In "normal" programming style modifying code is forbidden, but for PS2 programmers such trick are osometimes unawoidable

Third (and may be most important) is timing scheme. PS2 system consist form few parts, that are functioned "as whole" with help of rather cleverly made and fast system. Several parts should not be working correcly if you don't made correct timings, and it's rather unpredictable outside runtime.
Reply

Sponsored links

#22
Static recompilation won't work out in a way that would be useful.

Basically the static recompiled resulting program will still have to use a lot of dynamic recompilation since many things won't be known at the time at static recompilation.

The more vigerous you want the static recompilation to be, the more you have to make assumptions about the game's code.
This effectively means worse and worse compatibility.

Stuff like self-modifying code need dynamic recompilation techniques and the result of the SMC can't be predicted most of the time (or else they wouldn't have been using SMC in the first place).

Anyways static recompilation for pcsx2 isn't a good idea...
Check out my blog: Trashcan of Code
Reply
#23
I've already said most of what I think needs saying on the topic, but the SMC code issue should be addressed.

PS2 games do not use SMC. No, really, they don't. (I do in some of my own test programs but game programmers have more of a life.)

What they do is load and unload modules which is a similar problem for emulator developers as the code can be different when you revisit an instruction, but there are ways to avoid checking all the time as the loading is done with DMA. (We don't do this yet.)

Complicating the issue, we protect pages in order to detect modifications to them but games (...and the kernel) often keep code and data within the same page. Most blocks that pcsx2 installs manual protection on are victims of this, not actual modification.
Reply
#24
@rama
what do you mean when you say "without having the source code?"
what do you think is on a PS2 disc? Bananas? Wink but maybe you mean something else?

@Zeydlitz
first: its funny how you explain jumpes^^. But what you say sounds good.
second: you are right SMC would make static recompiling more difficult, but if its right what Pseudonym says, its not used in PS2 Games
third: I agree with you, timing is important and doing it static will make a lot of work. But doing as much as posible static and the rest during runtime whould be a great deal

(05-14-2010, 10:04 PM)cottonvibes Wrote: Basically the static recompiled resulting program will still have to use a lot of dynamic recompilation since many things won't be known at the time at static recompilation.
Thats not exaktly the truth. You can know EVERYTHING about the programm when you make static recompilation BUT its the question how much work and time you want to put in static recompiling.
Edit: Perhaps I should limit my statement. There are some things like Keystrokes and random numbers which can only be known during runtime.

(05-14-2010, 10:04 PM)cottonvibes Wrote: The more vigerous you want the static recompilation to be, the more you have to make assumptions about the game's code.
This effectively means worse and worse compatibility.
Yes you need to make assumptions about the game's code, but there is no need to make assumptions which can not be proved.
Reply
#25
(05-15-2010, 03:57 PM)tommy87 Wrote: what do you think is on a PS2 disc? Bananas?

I knew it!

But no... you're mistaking what the source code is...
Core i5 3570k -- Geforce GTX 670  --  Windows 7 x64
Reply
#26
I remember I had asked a similar question to the OP's question back on the generalemu board. echosierra set me straight with many of the same ideas the fine developers of pcsx2 have stated in this thread (though I didn't make the follow claims [about which I will not comment] that tommy87 is now making).

One idea I was wondering though is whether there is any caching in the dynamic recompiler between uses of the same code block? i.e. when an RPG moves from world screen to fight screen, can (is?) the fight screen start up code's dynamic recompiled code be reused?

And if so, couldn't this then be cached in a file for the next time pcsx2 emulates that game. Or do the same pitfalls related to memory pointers etc. obviate the possibility or the benefits of?
Reply
#27
(05-15-2010, 06:39 PM)virmaior Wrote: One idea I was wondering though is whether there is any caching in the dynamic recompiler between uses of the same code block?

If I understand you correctly, that is exactly what the dynarec does. Read the blog entry "Introduction to Dynamic Recompilation".

Quote:
"The basic idea of dynamic recompilation is to translate emulated instructions once, cache the emitted translated instructions, and then run the emitted native instructions as much times as needed."
Reply
#28
(05-15-2010, 07:16 PM)lightchris Wrote:
(05-15-2010, 06:39 PM)virmaior Wrote: One idea I was wondering though is whether there is any caching in the dynamic recompiler between uses of the same code block?

If I understand you correctly, that is exactly what the dynarec does. Read the blog entry "Introduction to Dynamic Recompilation".
Yeah, that does answer my question in the first part. The second part of what I am asking and why I put this here rather than in that thread is why can't those recomps be cached on the HD for future runs of the same game?
(or is that too marginally useful?)
Reply
#29
(05-15-2010, 06:05 PM)Shadow Lady Wrote:
(05-15-2010, 03:57 PM)tommy87 Wrote: what do you think is on a PS2 disc? Bananas?

I knew it!

But no... you're mistaking what the source code is...

hehe i know what you mean, but even assembler can be called source code^^
but i know you mean the original code befor compilling a gameWink

Oh in between have you ever calculate the percental slowdown of every part of the emulator? (I mean when executing one Instruction of the PS2 code)
Reply
#30
If you mean profiling then yea we do that.

So lemme get this straight:
Native PS2 machine code (heavily optimized by various compilers for EE / VU) is the same to you as the original game sources?
Reply




Users browsing this thread: 1 Guest(s)