Freescale Coldfire V4s

[Piru]

See if you can get one of those chip running on an old 3640 Amiga 4000 accelarator board. I know lots of people that would be interested. A lot of people here on Amiga.org would be interested in an upgrade to the old 68000 chip in there machines.

Unfortunately this is not possible as there are differences between 68k and coldfire.

[Piru]

How about a Coldfire processor linked to its own memory and an FPGA that emulates the Amiga chipset?
Running a re-compiled version of AROS68K with the  CF68KLib library to help run 68K code.

This won't help. The incompatibilities also include the actual applications, most of which you cannot recompile.

Coldfire just doesn't work running amiga 68k applications.

[Piru]

If you recompile the code for ColdFire, you could put a ColdFire identifier for the code in the executable. This is how PPC code in an Amiga executable works. There is probably already a ColdFire ELF code identifier if using AROS. Vbbc/vasm may already be able to compile and assemble it. I have assembled ColdFire code on my Amiga into an executable with vasm. I disassembled which verified that it did use the ColdFire instructions.

He was clearly referring to the fact that you cannot execute 68k code in a transparent manner, even if using the compatibility library, not on how to detect CF binaries.

[Piru]

I still don't understand why someone can't simply create a compiler that treats a 68k executable and libraries as intermediate code and creates a compiled native CF version.

There is no way to tell which part of the binary is code and which data. If you translate data in similar manner you'll just corrupt it.

It is also extremely difficult if not impossible to handle code that calculates checksum of the code itself or does dynamic relocation and/or modification to the code before execution (not all self modifying code is bad, patching the code before running it is quite common).

In short, it cannot be done.

[Piru]

What you do know is that the program entry is code. You can start from there and put traps in sections where you are not sure (e.g jmp tables etc.). You could combine it with a cache that remembers translated code.
In a later stage you can make tools that makes binary patches from this cache so this information can be distributed or updated so that the loader doesn't need to find out each time it loads a program.

No, it still won't work. This doesn't account for code that dynamically jumps into various parts of code or performs run-time modifications to the code. Static analysis cannot account for these.

The only way to do this reliably is to perform the translation run-time, that is JIT.