Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Static Recompilation .. ?!
Yeah there is a reason source code is usually written in high lvl languages vs assembler and then compiled for the machine with some hand tuning of the assembly after the fact. Have you ever tried to write the most basic of code in assembly? It takes god awful long for even the most basic of stuff. It's not that hard to do for those functions but it's still tedious. I'd hate to do anything that would be simple programs on C++ let alone something complex as PS2 game code. So unless you want to try to build something that will auto-magically "compile" assembly back into C++.

Sponsored links

(05-15-2010, 03:57 PM)tommy87 Wrote:
(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.

There's a bunch of things that can't be known at recompile time.
Indirect jumps for example.
If you have a jump based on the value of a 32bit non-constant register, that means there 2^32 possible destinations it can jump to.
That means you can't compile the destination code because its not known.

You either have to use dynamic recompilation techniques at that point, or you need to have coded your static recompiler to interpret such code blocks with an internal interpreter.

(05-15-2010, 03:57 PM)tommy87 Wrote:
(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.

well for example, psuedonym says games do not use SMC.
They probably don't, but that is an assumption he's making that is not proven.
If you code a static recompiler with the pretense that nothing uses SMC, then that means anything that actually does use it will not work correctly.

You can make more and more assumptions like this, and with each assumption you're limiting the amount of stuff you can run.

pcsx2 is not a simulator for running games, it is an emulator which attempts to emulate the hardware.
this means its not just about what games do, but rather what can be done on the ps2 system.
Check out my blog: Trashcan of Code
(05-15-2010, 07:26 PM)virmaior Wrote:
(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?)

that won't be useful.
first of all, hdd access is slow.
second, recompilation only needs to be done once per new-block and then cached to memory.
that means that emulation is not recompiling that-much, but instead running the recompiled blocks a lot.
you can have a game for example that runs some recompiled blocks 10,000 times in a minute, and then those blocks only needed to be recompiled once.
that means that as long as the recompile-time is bearable, then recompilation time doesn't matter too much.

there are some games however that love to recompile a lot because they're constantly swapping out blocks of code for other blocks. for these games recompile-time is more important, but thankfully that's not too many games.
Check out my blog: Trashcan of Code
To clarify the SMC thing, of course the recompiler should be able to handle it (though it's not safe even on real hardware without an instruction cache flush so protection isn't necessary until the program does this), but you should code with module loading in mind, not self modifying code.

I don't agree with cotton on the goals of a console emulator, but I agree that emulating the hardware is normally the right approach for a different reason. Emulating the hardware with reasonable accuracy is truly the "magic" solution. If everything's to spec, code works with you having to understand the techniques it uses at all. Understanding can lead to more efficient emulation in some circumstances, but these mostly involve waiting for work to be done, not the work itself.
Even with my fairly limited programming experience, I thought I'd add my $.02. Anyway Tommy87, a great emu programmer once said this "Writing an emulator is 20% understanding the target architecture, and 80% percent understanding the client architecture" What does this mean? It means that your idea of converting the game code to c++ wont help. Plus, there's less room for optimization in c++ rather than assembly. Moreover, because of all the abstraction that goes from c++ to assembly to binary to assembly to c++ (and why c++ I don't know. That'd be much harder to generate than straight c), the code would be 1) so cryptic, and 2) so different than what's actually happening that looking at it wont help. Why? Because emulation isn't in the majority concerning the EE or IPU or VU code. It's about the code that's running on your computer. And the 5 layers of abstraction wont help that, since you'd actually go another layer and convert your decompiled c(++) into x86 assembly. And good luck writing a decompiler that can make easily understandable c++. Plus, that's not even emulation. That's extra junk that doesn't need to be done.

Static recompilation won't help either. Nearly all code that can be statically translated can be dynamically translated (actually, it's vice versa. You can't statically translate unknown code, like jumps and branches or variable indexes). All that trying to do that does is create a horrible mess of assumption and bad code that's not even an emulator, rather just a guess. Which is what emulation isn't. So sorry, your theories are invalid. Just reading the wikipedia page about what an emulator does and looking at sample assembly without understanding it does NOT give you the understanding necessary to validly discuss the inner workings of an emulator.

Users browsing this thread: 1 Guest(s)