Coldfire - Binary Compatible

[jarrody2k]

Piru wrote:
@lou_dias

Why couldn't a 68K be virtualized and then fed the binary, then the virtual68k could make the determination and in the background, the app is repackaging the binary in a Coldfire-compatible way. The resultant binary could then be run natively.

Because it is impossible to tell whether certain part of the binary is code or data.

If I understood correctly you're suggesting here that the program would be run and that the executed parts would be translated? This doesn't work: There is no way to get any given program to run all code paths.

The only way is to do the translation on the fly: JIT.

Theoretically I can't see why not... executables have an entry point, and libraries will have some table of functions.  If you start at the entry point and take both directions on each possible conditional branch... why not?  I guess self modifying code may cause a problem, perhaps also jump thunks.... or any code jumps that jump to locations based on run-time variables.. and a lot of that stuff is more prominent in C++ templates and game code.  But certainly a lot of C executables could be converted with relative ease.

Not a robust solution or anything that would be used for general purpose emulation, but it isn't outright impossible.

Until Lord Piru corrects me

Jarrod

[jarrody2k]

Piru wrote:
@jarrody2k

Basically you'd need to emulate the whole program then. Just splitting at branches is not enough. You correctly note the dynamic jumps: this is a huge problem. There also are many points where the code are called from within the OS: For example interrupts, hooks and other callbacks.

If the OS does call to the program, the program needs to let the OS know where to jump to.  These function calls could be located and determined within translated code and the numbers changed to the new locations in the program.  I presume it would be quite possible (maybe not trivial) to detect kernel function calls or native library calls of the particular OS functions that register callbacks/interrupts etc.

For the locations it does register, these should also be translated.  So if the program registers some event response code for a button click, the code that is executed after that button click should be translated also.

So not only you'd need to emulate the m68k processor, you'd also need to trap every possible OS call. Also, some 3rd party library/device/whatever might be called that jumps into the the code, again generating a problem.

Surely libraries have some sort of function table where the entry points could be adjusted?

But certainly if code does tell another device/library to call back at a fixed point in code in a non-os friendly or unforseen way, this would be difficult to fix.

To correctly interpret everything would require running all possible codepaths in simulated environment. How does your simulation know when it's done? Running all possible codepaths in a given program take time x (x can be infinite). Running the same in emulation is not going to be faster than that.

Of course, any branches that branch back into already-translated code segments would terminate.  I hardly think you could make an accurate progress bar apart from the amount of code translated versus the total binary size (of which will be partly data sections)... but all paths will come to an end because they will eventuall skip to another part in code that is already translated or will return control to the OS.

I am not saying any of this is trivial, far from the case.  I am saying it is possible, and dare I say, achievable by an experienced team of software engineers.

Cheers,

Jarrod