NaturalViolence Wrote:Axxer Wrote:
pre-assembly language even
I doubt that. He would have to be insanely old to have worked on anything in the pre-assembly era. Assemblers have been around since the 1950s.
He did everything using pure binary in his first class. He just flipped switches and loaded it into the computer to either run that instruction or put it on tape. Assembly language that I've seen uses some language (I.e. word 10101010) while he just input two bytes.
I also didn't mean to antagonize ncknck, I just couldn't understand that sentence because there wasn't any end-of-sentence marker.
Everything else you said I agree with, such as:
Quote:I suppose to a certain extent you could try to call a recompiler an interpreter
Which you referred to, but the end of that sentence says "but you really can't" which is the point I was trying to make.
I think I just got caught up in semantics.
Quote:Right, sorry, but some stuff here goes against what I'd been told by reliable sources, yet hasn't been flamed by NaturalViolence. I'd been told that:
Interpreter just used equivalent x86 instructions to the power PC instructions, with no optimisations, so was slow.
JIT translated each block from PPC to C++ (or similar), then recompiled it for x86 with optimisations.
JITIL translated each block from PPC to C++ (or similar), then to another language which was easier to optimise, then compiled it as x86 with optimisations. The extra optimisations have a chance of countering wasted time translating twice, but usually only noticeably on a 32bit OS.
Please correct any and everything wrong with this.
That's a very simplified version, but yes that's essentially what each method does. But then again pretty much all of this has already been stated in the thread.
Quote:Static Recompilation was effectively the exact source code but compiled and optimised for x86, like porting the game to PC, instead of emulating it. This is fastest, but needs a guy to rewrite the whole game before it can be played.
Not really. Static recompilation in this case would compile all of the games PPC code into x86 code before running the game. Thus producing an executable binary file to run (.exe). It has nothing to do with porting and it certainly does not require the games source code to be rewritten. It's fast and efficient but it won't work if the application uses any self modifying code, which these games do.
What kind of self-modifying code are these games using? Just curious.
??????
I didn't know that there were "kinds" of self-modifying code. Self-modifying code is self-modifying code.
No, i don't literally mean there are types of code, I am asking what the self modifying code is doing.
-_- I know what it does in a technical sense (it modifies the executable machine code) I was just wondering if it helped with any features or anything. If its just an optimization thing than ok.
EDIT: yeah self-modifying code generally doesn't do that I was just curious if it did in this specific case or if that could even be possible. It evidently either isn't possible or isn't useful for that sort of thing.
Quote:EDIT: yeah self-modifying code generally doesn't do that I was just curious if it did in this specific case or if that could even be possible. It evidently either isn't possible or isn't useful for that sort of thing.
????
If what is possible? What sort of thing?
(09-15-2012, 02:57 PM)Axxer Wrote: [ -> ]-_- I know what it does in a technical sense (it modifies the executable machine code) I was just wondering if it helped with any features or anything. If its just an optimization thing than ok.
You don't often get self modifying code in GC/Wii games AFAICT, but some games (all if you emulate the apploader and not just the DOL) load code at runtime from DVD. That cannot be anticipated by a static recompiler.
EDIT: The only case of self modifying code I've seen so far with the EA ELF packer, which uncompressed the DOL at runtime.