Coldfire - Binary Compatible

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

[alexh]

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

[Zac67]

alexh wrote:

You do not know what is data and what is instructions (made worse if anything is compressed).

Not entirely true (afair) - looking at the 68k's function control signals (intended for the MMU), the FPGA/glue chip could indeed judge whether code or data is fetched. Er, well, I've got no idea if a ColdFire has anything like FC signals...

However, this would effectively rule out any (code) caching since that would bypass any possibility to manipulate the code stream before it gets executed. Furthermore, it would slow down the memory access, which most of the time is a bottleneck anyway. No way anyone wants to go...

[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

[Louis 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.

Or someone could make a 68k->Coldfire compiler...or a 68k dis-assembler->CF instruction converter->Coldfire re-assembler->Colfire compiler.

[bloodline]

lou_dias wrote:
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.

Replace the word Coldfire in the above sentence with x86, and you have an easier, cheaper and more powerful solution.

[AeroMan]

Intel AAAAaaarrrgghhh......    :-D

Why use a Intel in the Amiga ? Buy a PC and use AROS, UAE or both. Cheap and easy.
Conecting an Intel compatible to the Amiga will be way more expensive than a small PC.

If something should be used to do that, I believe it should be a PPC or a 68K compatible. (this is where the fun is at...)

[nyteschayde]

Sadly enough, and this is hard for me to say, the Intel processors are fast and dirt cheap. It's the same reason we have IDE now instead of SCSI. At the beginning they weren't worth buying for coasters relative to other processors but these days.... well lets just say things are different.

[bloodline]

AeroMan wrote:
Intel AAAAaaarrrgghhh......    :-D

Why use a Intel in the Amiga ? Buy a PC and use AROS, UAE or both. Cheap and easy.

I quite agree.

Conecting an Intel compatible to the Amiga will be way more expensive than a small PC.

Damn right!!!

If something should be used to do that, I believe it should be a PPC or a 68K compatible. (this is where the fun is at...)

Well, a 68K is fine... that's what the Amiga was designed around... Using a PPC is just as hard as using an x86...

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

[bloodline]

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.

I thought he was suggesting a JIT... :-D

[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).

[AeroMan]

bloodline wrote:

Well, a 68K is fine... that's what the Amiga was designed around... Using a PPC is just as hard as using an x86...

I've included PPC mainly because of OS4 and Morphos. I wasn't thinking about a full blown G5 or similar, but a embbedded chip like MPC5200 or AMCC's ones. They don't need heatsinks and have a local bus for memory mapped stuff that could be easier connected to an Amiga than the big chips would.

@nyteschayde:

Yes, I fully agree, they are cheap and easy to find, but this is nice for big companies. Home brewing an Intel board would be more expensive than buying a PC mobo.
In the other hand, microcontrollers like the ones above are really cheap also (maybe cheaper than x86s), and powerful enough to make us happy.
I have to admit Intel is faster, but a 700 mips PPC is good enough for me. Take a bigger one and you can get even more with all the advantages like built in Ethernet, USB, SPI (for SD cards..) and so on
(sorry... I'me already drooling  :-D )

[bloodline]

Piru wrote:
@bloodline

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

The resultant binary could then be run natively.

Yes you are quite right, he did imply that.

I really can't understand the obsession many on this site have for the coldfire... If I was starting a project, I choose either an ARM or a x86... depending upon the application.

[Zac67]

The only solution to this problem - as has been said months ago - is building a patch database where the required patches for all applications are collected over time to be applied to the binaries when needed (a bit like WHDload). This might have been feasable with the user base in '94 and today's Internet, but it's impossible today.

[Crumb]

@bloodline

If I am not mistaken, raw performance of intel ARM cpus is half the performance of PPC cpus (even embedded ones).

If I was desgning such a board for classic I would probably choose a low-power PPC chip (as it's very cheap, offers PCI, memory controller, usb and other stuff and could bring the possibility of running MOS/OS4). Or maybe an x86 low-power single-core chip (but this could turn much more complex and expensive).

I guess that interfacing a modern x86 chip to an Amiga classic bus would be quite complex: 0.5 to 1 Ghz memory buses, you would need to build some kind of "northbridge" to communicate the amiga hardware with it... and I think it would be much more easy with an embedded PPC chip (memory bus is slower so board layout is easier), these include nice controllers built in for SATA, PCI, ...

With a 68k->PPC JIT a modern embedded PPC chip running at 1Ghz would probably offer better performance running 68k code than a 68->x86 JIT on a single core low power x86 cpu.

IMHO an accelerator's cpu shouldn't require much more than 18watts.