Quote:Traditionally, computer programs had two modes of runtime operation, either interpreted or static (ahead-of-time) compilation.[citation needed] Interpreted code is translated from a high-level language to a machine code continuously during every execution, whereas statically compiled code is translated into machine code before execution, and only requires this translation once.

JIT compilers represent a hybrid approach, with translation occurring continuously, as with interpreters, but with caching of translated code to minimize performance degradation. It also offers other advantages over statically compiled code at development time, such as handling of late-bound data types and the ability to enforce security guarantees.

JIT builds upon two earlier ideas in run-time environments: bytecode compilation and dynamic compilation. It converts code at runtime prior to executing it natively, for example bytecode into native machine code.

Quote:I've got a - silly ? - question : Why Dolphin use only Just-In-Time Recompiler and not a Full Recompiler ?

Because it's an emulator and therefore a regular recompiler can't be implemented safely.

Quote:And bonus : what is JIT LLE for ? Is it for "Low Level Emulation" ?

Dolphin has two methods of emulating audio. High Level Emulation (HLE), which emulates the behavior of the software related to audio. Or Low Level Emulation (LLE), which emulates the behavior of the dsp, which is the chip that handles audio in the gc/wii. Normally the LLE audio plugin uses an interpreter but with the LLE jit option you can use a recompiler instead which is much faster but may be less accurate since it's still a work in progress.

Quote:It would greatly improve the games speed if wii code was already "translated" into pc code, wouldn't it ?

If it was possible yes. But it's not.

"Normally if given a choice between doing something and nothing, I’d choose to do nothing. But I would do something if it helps someone else do nothing. I’d work all night if it meant nothing got done."
-Ron Swanson

"I shall be a good politician, even if it kills me. Or if it kills anyone else for that matter. "
-Mark Antony

Just-in-time recompilation as we do it only compiles code thats actually used, and when it is used. Doing the recompilation statically and possibly ahead-of-time is not really possible for all games. Zelda for example dynamically loads stuff at runtime, and many other games use similar mechanisms to rewrite/modify code and/or load it at runtime - such code cannot be known at compile time, and would be missing.

(01-10-2011, 06:15 AM)Jack Frost Wrote: and many other games use similar mechanisms to rewrite/modify code

Are you sure, that self modifying code is still used today? I remember this coding stuff from Amiga with Motorola 68000 CPU to speed up loops. But it died with the 68020 CPU because the code modifications got only stored into ram und not into instruction cache too, what caused wrong code execution. I can't believe that this coding style should be back today.

Yes, Rogue Leader and a very few other games use self modifying code. The MMU emulation handles that situation. The SMC used on the GC is fed into the instruction cache, and the game has to specifically flush the old instructions from the cache for the new code to take effect. It was a nightmare to emulate under JIT.