rabidpoobear
Active Member
ion, basically this is the process:
Source Code -> Compiler -> Compiled Code (machine code)
Just looking at it like this, it seems like you could do
Source Code <- decompiler <- Compiled Code
the problem is that the Compiler step is not a 1:1 function. It makes some alterations that cannot be reversed.
The compiler does various optimization techniques (removing 'dead' (unreachable) code, unrolling some loops, converting switch statements to jump tables, etc. etc.) that can't be undone.
So no, you can't get the original source code out of the compiled code. However, one thing you could do is...
Suppose you have a program like this (this is not actual code it's just an example) on one machine:
ADD 1 to X and Y
STORE X in MEMORY at location 3000
And now you want to move it to another machine.
Say it doesn't know how to ADD to X and Y at the same time, but all the other operations are the same.
So you could just rewrite this program as
ADD 1 to X
ADD 1 to Y
STORE X in MEMORY at location 3000
Notice that you aren't converting it to the original C source code or anything, you're just replacing instructions with other instructions that do 'the same thing'.
This is called Static Recompilation. It's similar to Dynamic Recompilation (Dynarec) that you hear about in emulators.
The difference is that static recompilation happens ONCE, dynamic recompilation runs every time you run the program.
So why would you EVER want to do dynamic recompilation? static sounds better!
The problem is that in most cases, code has the ability to MODIFY itself.
So you might have something like this:
ADD 1 to X
IF X is 3 CHANGE next instruction to SUBTRACT 1 from X
ADD 1 to X
So now since we don't know what 'X' is (if it's going to be 3) we don't know if line 3 should be ADD or SUBTRACT. So basically static recompilation can't really handle situations like this.
Dynamic recompilation would just wait until it knew what the value of X was, then change the line to ADD or SUBTRACT, and then compile it. It has the current state of the program so it can properly handle self-modifying code.
Some emulators have used static recompilation before. The emulator Corn is known as the fastest N64 emulator that was ever made, essentially. But its compatibility was low because it couldn't handle games that did self-modified code. Mario 64 wasn't one of them, so Corn could run mario 64 on a lot of machines that no other emulators could.
It's a pain and because of the low compatibility, not many people do it.
I'm actually pretty interested in static recompilation but I can't seem to find any statistics on which systems really self-modify code. everyone just does dynarec's these days 'cause in most cases it's not worth the compatibility hit to do static recompilation. But if you do have a program that can be statically recompiled it should be pretty fast
Source Code -> Compiler -> Compiled Code (machine code)
Just looking at it like this, it seems like you could do
Source Code <- decompiler <- Compiled Code
the problem is that the Compiler step is not a 1:1 function. It makes some alterations that cannot be reversed.
The compiler does various optimization techniques (removing 'dead' (unreachable) code, unrolling some loops, converting switch statements to jump tables, etc. etc.) that can't be undone.
So no, you can't get the original source code out of the compiled code. However, one thing you could do is...
Suppose you have a program like this (this is not actual code it's just an example) on one machine:
ADD 1 to X and Y
STORE X in MEMORY at location 3000
And now you want to move it to another machine.
Say it doesn't know how to ADD to X and Y at the same time, but all the other operations are the same.
So you could just rewrite this program as
ADD 1 to X
ADD 1 to Y
STORE X in MEMORY at location 3000
Notice that you aren't converting it to the original C source code or anything, you're just replacing instructions with other instructions that do 'the same thing'.
This is called Static Recompilation. It's similar to Dynamic Recompilation (Dynarec) that you hear about in emulators.
The difference is that static recompilation happens ONCE, dynamic recompilation runs every time you run the program.
So why would you EVER want to do dynamic recompilation? static sounds better!
The problem is that in most cases, code has the ability to MODIFY itself.
So you might have something like this:
ADD 1 to X
IF X is 3 CHANGE next instruction to SUBTRACT 1 from X
ADD 1 to X
So now since we don't know what 'X' is (if it's going to be 3) we don't know if line 3 should be ADD or SUBTRACT. So basically static recompilation can't really handle situations like this.
Dynamic recompilation would just wait until it knew what the value of X was, then change the line to ADD or SUBTRACT, and then compile it. It has the current state of the program so it can properly handle self-modifying code.
Some emulators have used static recompilation before. The emulator Corn is known as the fastest N64 emulator that was ever made, essentially. But its compatibility was low because it couldn't handle games that did self-modified code. Mario 64 wasn't one of them, so Corn could run mario 64 on a lot of machines that no other emulators could.
It's a pain and because of the low compatibility, not many people do it.
I'm actually pretty interested in static recompilation but I can't seem to find any statistics on which systems really self-modify code. everyone just does dynarec's these days 'cause in most cases it's not worth the compatibility hit to do static recompilation. But if you do have a program that can be statically recompiled it should be pretty fast