I just have a suggestion to make. After looking into the concept of Dynarec, i've come up with the an idea. Why not develop a program that will take a GCN ISO and run through it altering it's code to make it as though it was recompiled for that platform. Afterwards, it can run on a slightly modified version of the emulator designed to take advantage of this. This would probably increase the speed of games tenfold. What do you guys think?
an idea concerning Dynarec...
- Thread starter DJ Stenny
- Start date
- Thread Starter
- #3
http://en.wikipedia.org/wiki/Dynamic_recompilation
From what i've read, the only difference between my idea and Dynarec is that Dynarec recompiles on the spot which may take time.
And yes, i do know how computers and emulators work. I got a 5 on my Computer Science AP for god's sake.
From what i've read, the only difference between my idea and Dynarec is that Dynarec recompiles on the spot which may take time.
And yes, i do know how computers and emulators work. I got a 5 on my Computer Science AP for god's sake.
- Thread Starter
- #5
This is a post that Cyberman made in another thread.
"Dynamic Recompilation takes the existing code and recompiles it for another platform. Interpretor reads each code one at a time and executes it like the original machine. The difference is that Dynamic Recompilation is faster simply because it's running as a native application directly on the hardware. Interpretors are inherently slow because they perform the same functions as the original hardware reading and decoding the data one opcode at a time.
Dynamic Rec is very complex to do, first you have to generate code that's equivalent to the original games code. THEN you have to recompile sections of code if the code is self modifying (N64 had a number of games that did that).
Of course after generating the intermediate code, you might want to do optimizations of the generated code as well.
Anyhow the Dynamic Rec's output executes as a native application. Whereas the interpretor does not. The process is much slower therefore."
"Dynamic Recompilation takes the existing code and recompiles it for another platform. Interpretor reads each code one at a time and executes it like the original machine. The difference is that Dynamic Recompilation is faster simply because it's running as a native application directly on the hardware. Interpretors are inherently slow because they perform the same functions as the original hardware reading and decoding the data one opcode at a time.
Dynamic Rec is very complex to do, first you have to generate code that's equivalent to the original games code. THEN you have to recompile sections of code if the code is self modifying (N64 had a number of games that did that).
Of course after generating the intermediate code, you might want to do optimizations of the generated code as well.
Anyhow the Dynamic Rec's output executes as a native application. Whereas the interpretor does not. The process is much slower therefore."
Toasty
Sony battery
What you're refering to - compiling the whole game at once - is called static recompilation. Of interpretation, dynamic recompilation and static recompilation it produces the fastest running code, but also is the buggiest as it's very difficult to deal with things like self-modifying code. Also, as the other posters stated above, it's difficult to tell just what needs recompiling (which part is code and which part is data - and what if it's both!) and the compilation in mid-game isn't really what slows things down, so it would cause more (and more serious) problems than it would solve.
DR.BETRUGER
Banned
What? I have test some games, and i saw that when i run Dolpihn in Dynarec the games are a bit faster than the interpeter.:drool: So i think that when the dynarec will be fxed, we will see better speed than now right?
acman:
acman:
DR.BETRUGER
Banned
What do you mean when you say BUGS IN GAMES??:down:
DR.BETRUGER
Banned
AHAHADIDIOU,COFIKIYOU!!!(I think you understood this is the slogans who say the monsters in Doom3, i mean the securities!)HEHEHEHE!!!!
Static recompilation isn't really feasible if you want accurate emulation. As a previous poster mentioned, it can't handle self-modifying code. Furthermore, in many cases, calculated jumps wouldn't work either because the recompiler wouldn't have known where the jump lead to, and thus wouldn't have recompiled the code at the jump target correctly.
This is my first post, BTW.
This is my first post, BTW.
A mixture of static recompiled code with an interpreter (perhaps even dynamic recompiler?) for unhandled indirect jumps (till it jumps back into a recompiled region) should be more than feasible. Also, how many Gamecube games actually make use of self-modifying code? I gather its a fairly outdated practice.
(I did a decent amount of research into the subject quite a while ago, but never got around to implementing it, though.)
(I did a decent amount of research into the subject quite a while ago, but never got around to implementing it, though.)
bohdy said:
That's a possibility, but it would remove some of the benefit of static recompilation. I could also see getting back to the statically recompiled code being a problem if you wanted it to recognize anything more than jump targets you found when statically recompiling. By this, I mean jumping into the middle of statically recompiled code regions from interpreted/dynarec'd code. The interpreter would have to look up the GC code from that region and then figure out how much native code would have been generated from the start of the region to the point you want to jump to in order to figure out where to jump in the native code. So you might end up spending a lot of time in the interpreter/dynarec for some games.
I still maintain static recompilation isn't very feasible, though. Combining it with an embedded interpreter isn't true static recompilation.
You can keep cascaded case statements as jump targets every block of instructions that you statically recompile. Compiler will turn it into a fast jump table, so you will be able to jump through to any target in the original code that has been recompiled. Some way of stepping through to exactly the right spot in the block would be necessary, though. And yes and interpreter would slow it down, but it beats having to map the execusion flow for every game. Your best bet it to recompile anything that sits in the code section, and hope the execusion spends most of the time in that region and rarely jumps out.
It would take some doing, but it is the best way that I can think of to make a static recompiler that works somewhat generally and still fast.
It would take some doing, but it is the best way that I can think of to make a static recompiler that works somewhat generally and still fast.
bohdy said:
Yes, that is what I was talking about. I just realized that a reasonable way of doing that would putting a table at the start of each block with a pointer to every instruction in the block... This would solve the problem of there possibly being cases where the same GC instruction is recompiled into different native code.