Coldfire - Binary Compatible

[Piru]

Many (if not most) of these ideas have been discussed in the past threads. They're worth checking out, too.

[Piru]

@pyrre

68k is based on CISC instructions. And the coldfire is a 68k core but is designed as an RISC based CPU.
So... what difference does that make?

None. Whatever the CPU does internally to actually execute the instructions is irrelevant.

In similar way modern x86 CPUs are RISC, but execute x86 CISC code. See Wikipedia: x86, Current implementations

[Piru]

@lou_dias

I'm pretty sure that when I looked up Coldfire tools that Freescale had a binary analyzer/converter that could take a 68K binary and make it CF-native.

It doesn't work for amiga binaries, and it never can.

The problem is that in any given amiga executable it is impossible to automagically determine which part is code and which data. It just can't be done.

[Piru]

@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.

[Piru]

@bloodline

As far as I can tell he didn't, he wants separate, native binaries:

The resultant binary could then be run natively.

JIT doesn't reconstruct the whole binary, just the executed parts (and depending on the implementation it might even choose to use interpretive emulation for some parts, rather than spending time to translate everything).

Due to the nature of the global, shared memory map of amigaos, it's quite impossible to store the translated code on disk, either (well you could store it, but it'd only be loadable to the exact same addresses as before, rendering the whole thing unusable).

[Piru]

@pyrre

That means the Intel x86 cpus are CISC, in the way that the OS sends complex instructions. But the instructions is translatet to "RISC" before execution inside the CPU

Yes. However, new x86 also have native RISC instructions and registers.

However the coldfire is a true RISC based CPU, in the way it gets RISC instructions from the os...

No, it uses CISC instructions, but internally is RISC, just like these new x86 CPUs (just less advanced obviously). Freescale calls it "variable-length RISC architecture". Basically they've ripped out anything too complex, but still support as much of the m68k as possible. Rest must be emulated.

I just don't get what makes the coldfire "incompatible" to run Amiga OS

If you want full compatibility it gets very slow since you need to do full emulation. I discussed the problem >4 years ago here: http://www.iki.fi/sintonen/coldfire-v4-m68k.txt

Even with the latest Coldfire CPUs there are differences in the way some instructions work. These instructions cannot be intercepted via some exception, the results are just different compared to real m68k. Also there are some differences in supervisor mode, too, which pretty much means you're forced to emulate supervisor to get good compatibility. The compatibility figures quoted by Freescale are for user mode code.

[Piru]

@lou_dias

Sort of like a JIT, but not actually executing code, just analyzing it's execution, marking offsets and translating into CF compatible version. If one 68K instruction has to be emulated by 4 CF instructions, then all jump/branch offsets have to be moved up 3 bytes/words thereafter.

Even if you saved the generated code on disk, you could no longer read it back (since everything would need to be located to exact same addresses as while saving).

It just doesn't work, sorry.

[Piru]

@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.

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.

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.