ColdFire Project?

[Piru]

@rkauer

I think the best solution for the Coldfire instruction set issue is adding a parallel "small" Spartan to catch the instructions who are not compatible with 68k.

How would that work exactly? How can some external chip know what the CPU is doing?

[Piru]

@Ragoon

The coldfire since core V4e is fully compatible with the 68040. The first generation (5102) was already fully compatible with the 68EC040. It is an enhanced version of the originals 68k (410 MIPS @ 260MHz for actual coldfire and 110 Mips @ 75 MHz for 68060).

They are not compatible.

Supervisor mode is totally different. User mode is different, and even with emulation library loaded the user mode has a small difference which cannot be trapped.

[Piru]

@rkauer

I mean use a Spartan as a translator table to catch the instructions the Coldfire can't process in the right way.

But how can you do that? How can you make the spartan interface with the CPU in such way?

[Piru]

@jdiffend

People that claim a Coldfire wouldn't be faster than an 060 either haven't looked at the benchmark info from Motorola or they are just ignoring it. Extensive code analysis of millions of lines of code showed *at most* a 30% performance drop emulating existing 68K code on older Coldfire chips (V2 core). I also believe that was 68000 code, not 060 code which has fewer incompatibilities. Even if their estimates are optimistic the 4e has added many more instructions and addressing modes over the V2 so it should run 68k code much faster than the V2. Software should be over twice as fast on the 260MHz 4e than on the 75MHz 060.

So how come Elbox Dragon is 040 speeds then?

[Piru]

Some say they are probably burning much of their cycles running a JIT compiler to handle those instruction differences I mentioned between CF and 68K.

Possibly. However, accoding to jdiffend it should be at least twice as fast as 060@75, by just using the stock emulation library (no JIT). That just doesn't add up... :-)

Lie, bigger lie, benchmark by the manufacturer...

[Piru]

@Hans_

Wasn't there a tool to convert 68k assembly to coldfire assembly? If there is one, it should be possible to create coldfire binaries for the whole OS using a suitable disassembler and this tool.

Not easily.

You'd need to manually disassemble everything in a way it can be recompiled. This is highly demanding work which requires tons of assembly knowledge and time. It cannot be automated.

[Piru]

@jdiffend

Actually, the disassembler I used to make the commented 2.? exec disassembly generated code that could be reassembled.

A program could be written to take that, make the patches with the existing tool and then optimize the code to remove stuff that isn't needed.
It would need to use register tracking similar to a modern optimizing C++ compiler AND would need to trace flag usage.
It would take a LONG time to build such a beast from scratch. I've spent some time in the guts of a few C compilers and it's not easy work... then add some stuff those don't have to do and it's a huge undertaking. All for a computer that has been off the market for over a decade.

Exec is quite trivial, it only has couple of arrays in it (which has relative offsets in them).

It gets much hairier with complex code that has baserel references, or even worse references with varying base. Those are pretty much impossible to resolve without actually executing the code.

Another problem is that you can't always be sure what is code and what is data. Automation will not get that right every time.

So while it might work for some random samples, it might easily produce sourcecode that while building ok, actually produces broken code, in worst cases in a way that it doesn't crash, but rather just generate bogus results.

There is no way to workaround this via automated software. Human interaction and guidance is required.