AROS68K and the Freescale Coldfire CPU

[WolfToTheMoon]

The best thing we found out is that seems that Freescale haven't given up on Coldfire family.

This V5e core is a complete mystery. Hardly any info about it but it is plain that it is not a simple derivation of the V5 core(since V5 goes up to 333 MHz, but V5e has a 540 MHz version, leading me to speculate it may be a significant upgrade to the base V5 core or maybe even a different manufacturing process/technology). It may lead to a V6 core Coldfire sometimes in the future. According to their plans that were presented 8-9 years ago, a V6 core should have been out by now, but obviously things have not be progressing in a manner they anticipated. Still, if V6 core gets launched, that would mean a potential 800 MHz 68K compatible, with possible USB 3.0 support, SATA, PCIe...

[nicholas]

@WolfToTheMoon

The only reasonable way to start is to get hold of a CF V4 developer board and get AROS running on that first, _then_ you can come back and talk about doing all the other things you've mentioned.

Just buy an Atari cf board and get it working there first.

[ElPolloDiabl]

What is the price of those CPUs? Unless they are dirt cheap, I don't see the point.
If you want to resurrect an old project how about the G3 PPC card instead?

[WolfToTheMoon]

What is the price of those CPUs? Unless they are dirt cheap, I don't see the point.
If you want to resurrect an old project how about the G3 PPC card instead?

ColdFire CPUs are dirt cheap... in fact, you could probably sell an entire acc board with a V4e Coldfire, DDR RAM and PCI GPU for the price of one 68060 CPU.

[WolfToTheMoon]

If you want to resurrect an old project how about the G3 PPC card instead?

For AOS4/MOS?

Yes, there are dirt cheap PPC accelerators out there for old Macs but it will never happen for Classic Amigas because Hyperion will probably never sanction such a project. It would be too big ofa a threat to the Acube and A-eon partnership.

As to MOS, that should be discussed with the MOS team but I doubt they would sanction it either.

So, pretty much the only choice now for classics is either 68K(OS 3.x) or Coldfire(AROS68K) acc boards.

[yssing]

Run th CF68Klib in supervisormode, then most kind of 68k SW/OS should be possible to run on af CF cpu

[Iggy]

ColdFire CPUs are dirt cheap... in fact, you could probably sell an entire acc board with a V4e Coldfire, DDR RAM and PCI GPU for the price of one 68060 CPU.

Yes Coldfires are cheap. About a quarter the price of a 68060, and I can get '060 50s for under $50. I don't think the accelerator boards would be quite as inexpensive as you've estimated, but they should undercut 68K accelerators and would be a lot lower than PPCs.

[Iggy]

Run th CF68Klib in supervisormode, then most kind of 68k SW/OS should be possible to run on af CF cpu

The problem with CF68Klib, if you check the documentation, is that even in supervisor mode it doesn't trap instructions that run differently on the Coldfire than they do on the 68K.
I'm sure there's a way around this, but while CF68Klib looks promising, it may not be the only answer.

[vidarh]

The problem with CF68Klib, if you check the documentation, is that even in supervisor mode it doesn't trap instructions that run differently on the Coldfire than they do on the 68K.
I'm sure there's a way around this, but while CF68Klib looks promising, it may not be the only answer.

The best bet is probably something like a simple tracing JIT translator where most instructions translate 1-to-1. You could do it mostly "in place" by scanning block by block and rewriting any offending instructions, and replace Bcc, JSR, JMP etc. with traps if you can't show they point to "safe" (already JIT'ed) code, then you jump to the code. If/when you trap again, you continue JIT'ing and patch the instruction that brought you there back to its original.

As an example, lets assume this completely bogus example sequence:

       MOVE.L    D0,-(SP)
       SOME_BROKEN_INSTRUCTION
       RTS

You'd decode all three instructions, then rewrite it like this:

       MOVE.L    D0,-(SP)
       BSR         some_free_location (unless SOME_BROKEN_INSTRUCTION is long enough for you to be able to "emulate" it inline, in which case you have it easy)
       RTS

some_free_location:
       [code to emulate SOME_BROKEN_INSTRUCTION]
       RTS

The biggest problem is if SOME_BROKEN_INSTRUCTION is too short to provide enough space to branch elsewhere, in which case you have two choices: Resort forcing a trap or rewriting following instructions too.  The latter quickly makes things trickier as you then have to deal with rewriting branches etc. that may point to the later instructions that you move.

You pay the additional cost of the JIT process, but once critical paths have been JIT'd, it'll run at near optimal native speed. "Near" because you get the extra overhead of potentially having extra branches to account for "patch sites" where there was no space in the original code to plug in the modified instructions, unless you go to the potentially significant extra trouble of rewriting the whole thing.

Note that this is not foolproof. Self modifying code etc. or code that intentionally jump into the middle of an instruction could still cause trouble and is much harder to deal with.

The JIT could be very fast, as for any instructions deemed "safe" it'd just need to recognize them and move on to the next instruction, and recognizing them could be done with a very small, compact decoder since it could discard large groups of instructions as safe with a few simple bit masks.

[WolfToTheMoon]

I have some info on the V5e...

The guy I contacted informed me that the entire motherboard from the HP laserJet that contains the V5e @ 540 MHz can be bought for about 500ish $ thru his service. I'm still trying to find info on whether I could get any V5e documentation.

[Iggy]

...Note that this is not foolproof. Self modifying code etc. or code that intentionally jump into the middle of an instruction could still cause trouble and is much harder to deal with....

Man, I'd almost forgotten about that practice (self modifying code). Anyone resorting to that should be bitch slapped.

The JIT could be very fast, as for any instructions deemed "safe" it'd just need to recognize them and move on to the next instruction, and recognizing them could be done with a very small, compact decoder since it could discard large groups of instructions as safe with a few simple bit masks.

Having seen what the MorphOS team managed to do with JIT for 68K code running on PPCs I'd have say you've got a point. Since many of the instructions would not require modification, this should work fairly quickly.

[Iggy]

I have some info on the V5e...

The guy I contacted informed me that the entire motherboard from the HP laserJet that contains the V5e @ 540 MHz can be bought for about 500ish $ thru his service. I'm still trying to find info on whether I could get any V5e documentation.

Well, at least we know they're available. Removing them from the boards and re-using them is nightmarish task, but not impossible. And the printers may be available used, refurbish, or broken allowing salvage of V5es from those sources.

Although I wouldn't discount the idea of using V4s just yet. They're available, low cost, and run at up to 266Mhz. As has been pointed out, JIT translation of 68K instructions to Coldfire should be aided by the similarities in the instruction sets.

[WolfToTheMoon]

here are some becnhmarks... a V4e Coldfire running at 200 MHz on a MCF5484 evaluation board vs CT60-100-25(68060 @ 100 MHz!) and Hades 060 atari clones.


http://img402.imageshack.us/img402/3604/kronos2.jpg





More info can be found HERE


As you can see, the Coldfire V4e did rather good in most tests.

[Iggy]

here are some becnhmarks... a V4e Coldfire running at 200 MHz on a MCF5484 evaluation board vs CT60-100-25(68060 @ 100 MHz!) and Hades 060 atari clones.


http://img402.imageshack.us/img402/3604/kronos2.jpg





More info can be found HERE


As you can see, the Coldfire V4e did rather good in most tests.

I was actually surprised to see the 68060s doing as well as they did in comparison. That early Coldari posting is fascinating. Thanks..

[vidarh]

Having seen what the MorphOS team managed to do with JIT for 68K code running on PPCs I'd have say you've got a point. Since many of the instructions would not require modification, this should work fairly quickly.

Exactly - for m68k on PPC it's a massive amount of work, and even more work to get it fast. For M68k on Coldfire a lot of it should be no-op's (though reading up on it, there *is* a lot of stuff that's common in Amiga code that will need JIT'ing - such as ROR/ROL, arithmetic on bytes or words, DBcc etc.) - just map and figure out if it's a "safe" instruction, if so decode enough to know the length of the instruction and skip; if not, check if it's one that can be replaced in-line, and patch or worst case patch in a branch and use a small-ish set of functions to generate the appropriate replacements...

If you want to be fancy, you can later deal with relocating jumps etc. and so inline all the modifications (which would even if you wanted to let you do "proper" tracing the way modern Javascript JIT's does, and take advantage of the larger cache on the ColdFire to trace longer instruction streams and unroll loops and auto-inline other functions).