It's not a trivial task (major understatement ), but this type of technology could certainly be userd to run PPC on a Pi at better-than-emulator speeds. PearPC, PearPC is an architecture independent PowerPC platform emulator capable of Mac-on-Linux is a Linux/PPC program that virtualizes MacOS or MacOSX in.
Mac ppc emulator code#
It ran i386 apps in emulation mode, and on-the-fly translated code to native Alpha using compiler-like technology, which it subsequently rewrote into the image. If you know the hardware and system specs then where is the problem? I'm not saying it is easy but its a long, long way from impossible, I've seen people tackle harder projects.ĭEC had a technology for the Alpha RISC processor called FX!32.
I seem to recall some emulators do a bit of this with JIT techniques. I wrote a number of decompilers and cross-compilers many years ago and I envisaged that instead of emulation that conversion would be the way to go, decompile, convert and compile (in simplistic terms). I guess though things might get hairy when writing an emulator/translator that is translating code optimised by some compiler for some architecture to run on a different architecture with a different memory model. But then we have higher level abstractions to handle that in our languages, like "volatile" in C and atomics in C++. Unless they are talking to hardware or writing multithreaded code. Typically developers never need to worry about all this and compilers are not putting in barriers willy nilly. Other threads for example, or hardware devices mapped to those addresses. The only time this matters is when something else is watching that same RAM other than your piece of code. Similarly processors can rearrange things, as long as the outcome is the same. Or it may be keeping intermediate values in registers and never write them to memory. Of course if that x is not used it can elide that as well. In C then the optimiser can reduce that to an instruction sequence that only writes 3 to x.
0 kommentar(er)
