Coldfire - Binary Compatible

[Plaz]

Coldfire and 68K are about 99.8% code compatible. That's been the case from the start, Freescale didn't change it. There are two problems to solve with a coldfire card for Amiga.

#1 There are instructions in the 68k that are also legal on the coldfire... but they do a different type operation. It would be better if these instuctions were excluded on the coldfire all together. That way you could trap them with an illegal op exception and direct the code to a lib that would do a compatible operation in software instead. Many missing instructions are handled this way with current methods. The trouble comes in dealing with the "alien" instructions that do exist and can't be trapped.  Some have suggested a JIT compiler method to intercept every binary code and process it. But that would require lots more code, probably more hardware and sap the speed of the coldfire down to an estimated 060/50 at best. It's a challenging problem that no one (that we know of) has solved yet.

#2 is the IO architecture. Only certain coldfire models support the necessary input/output options to interface well with the Amiga system. Hardware designs would have to be worked out to deal with the motherboard/buss interfaces.


There might be an Option #3.....
Use this instead.... http://www.innovasic.com/fido.htm
as suggested in this thread....

FIDO 1100 MPU

If this CPU executes every included instuction like a 68k, then missing instructions can be handled in software.

Plaz

[Plaz]

is stopped due the incompatibilities of the Coldfire versus a true 68k.

Not entirely true. According to his last emails, he's still messing with a design that would use a coldfire as a pluggable replacement for cpu cards that have a soceted 68030s. Even if succesful though, there would be code compatibility issues with some software.

Plaz

[Plaz]

@Painkiller

Hmm where is that Elbox Dragon 1200

Probably still trying to work out issues #1 and #2 in my post above. One rumor was that they had made good progress with compatibility, but speed suffered because of it.

It's possible to request a custom coldfire chip from freescale. Such a chip might help with I/O and speed issues. I've wondered if Elbox ever tried. But the production run would probably be too small and expensive to make it feesable.

Plaz

[Plaz]

The converter would have to RUN the code, and that just isnt possible. I doubt such a converter really exists.

I recall see such a tool, buts it's limited. It reads your binary offline, replaces the offending instructions and then you have a new binary to run.

But for the reasons Piru mentions, it doesn't know when to stop. It may replace bits you don't want replaced. Also some code is very memory location dependant. If I see a 2 byte illegal instruction and I replace it with a 3 byte substitue, I've just offset the reset of the code for disasterous results probably.

The only way I can see that would work is to have the original C/C++ code and recompile it to coldfire. This is ok for apps written in a higher language, but the OS is too dependant on machine code, memory and chip addresses. First you need the original machine code, then you need to try and rewrite it in a why that makes both the native hardware and coldfire happy. No easy task.

Plaz