Why JIT ?

[nowid50]

Hello,

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

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

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

THanks in advance for your answers

[Squall Leonhart]

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.

man, i dunno either

[NaturalViolence]

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.

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.

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.

[nowid50]

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

... Dolphin can recompile code on the fly, so why it is not possible to recompile it off-game ?... I don't really understand the difference between both of them...

[Squall Leonhart]

and you never will if you keep expecting us to tell you.

[Jack Frost]

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.

[nowid50]

Oh I see. I thought that the wii "executables" where only basic procedural engines. I didn't thought it could be so dynamical.

Sorry for the silly question again.

[Jack Frost]

Your general "basic procedural engine" may be able to do the same just aswell. In the end, it comes down to some sort of assembly, and pretty much everything is possible there.

[KarstenS]

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.

[skid]

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.