Is the Coldfire project dead?

[lordv]

Coldfire V4 & V5 have an ability to fully emulate 68k opcodes... But only AT THE FIRST SIGHT. No provisions made to emulate 64-bit mul, 64-bit div and division with remainder instructions (coldfire just won't trap on them and will make rubbish), so virtually every piece of real amiga code will fail on coldfire.

The overall JIT emualtion as well as other methods of workaround for this bug will make coldfire totally uneffective when compared even with 060.

So the coldfire accelerators "suck and must die" =)

[lordv]

[/quote]Does it fail, or are you "if-ing" about hypothetical stuff? Id think that in trapping an instruction it doesn't have implemented, it wouldn't say anything about afew certain functions like muls or mulu being non-implemented but not allowed to trap...

Everybody doubting please go to the freescale.com (former motorola) and find 68k software emulation library for coldfire, where it is written, that coldfire JUST WON'T TRAP on 32x32->64 mul, 64/32->32 div and 32/32->32:32 div instructions! Because they differ only slightly from 32x32->32 and 32/32->32, which coldfire supports. And coldfire just won't see any difference and execute them as 32x32->32 or 32/32->32. Unlike the 060, which will trap anyway.

This is a serious bug preventing virtually any 020+ program from correct executing. There are several workarounds, like a total JIT-emu of 68k code or hell MMU stuff like examining every codepage it's going to execute and see if there are such muls, but overall it will make coldfire even slower than 060.

FPU is also a pain, which probably won't work correctly anyway.

[lordv]

If the Coldfire doesn't trap 32-bit muls and mulu instructions then there is no way it could ever run Amiga software without something like a JIT... in which case using a modern RISC would be a better idea.

Yes, you're right. A g4-only accel card will be enough for everybody (whoops! . fast g4 (1ghz) could fully emulate 68k at the rough speed of 040 or 060 when no JITting. With JIT it will become the fastest 68k ever seen And you still have conventional amiga, not the pc-like monster (pegosos or amigaone, whose the only difference from pc is the powerpc processor). Optionally you can have on such an accel modern single-chip videocard (I don't understand why I could ever wish geforce4 on my amiga!).

[lordv]

I didn't realize that they had changes somewhat the results of certain instructions. That can make it more difficult than just being able to trap everything. But I doubt it's impossible. Come on, we've got the Amiga background, a tradition of doing the unnecessary, the bizarre, and the nigh-impossible.

For what is it worth to do impossible things with coldfire? It can't fully emulate 68k by trapping everything, so the only way is JITting. Then, JITting is more effective on ppc-g4/g5/soon. Exhaustively enough? =)

[lordv]

Actually, JIT mechanism for 68K on coldfire need not be more complex than HP's Dynamo mechanism. That is effectively a hotspot JIT emulating the actual same CPU it is running on and gets faster performance due to various runtime optimisations that arent possible to make at compile time.

Like Dynamo, a JIT 680x0 on coldifre implementation has the benefit that most of the instructions would need no translation - you only need to worry about branch offsets that change as a result of expanding some code "inline", like your unimplemented 680x0 instructions.

Don't know anything 'bout dynamo (maybe some urls?), but with coldfire it's not that easy.

Just imagine - you have all regs filled with data and you must JIT-emulate add.w d1,d2. No stack push/pops are allowed by definition, flags must be also set correctly. The same but to a greater extent goes to mulu.l d1,d2:d3 or smth similar.

That's why I'm saying about g4/g5 JIT emulator as an accelerator for amiga. Unfortunately I have no needed knowledge to do such thing by myself.

[lordv]

@Karlos

Dynamo is a dynamic recompilation engine for HP PA8000, running on he HP PA8000.
It blows away the arguments against register allocation and so on. It is a hotspot JIT (ie mostly interpretation which in this case translates into just executing the code as is) that simply optimises away loops, conditional branches etc. at runtime.

Ok, now it's clear. It works as any other JITter - first runs code interpretive, then taking some fragments, generating for them new code fragments in an isolated buffer and running them from there instead of interpreting original code. In such a manner it could perform on coldfire as well (for a system-wide code fragments). BUT! - when doing so, it would be more effective to use G4/G5 - because they're significantly faster, having more registers (JIT is easier), at last have ability to run warpup/powerup applications natively.

[lordv]

@bloodline

But karlos... the coldfire isn't going to trap the 32bit mul, it's just going to return the wrong result.

Even the standard 040/060-like OXYpatcher method isn't applicable for coldfire, because OXYpatcher replaces every unsupported command with jsr -xxx.w, which takes 2 words and fits perfectly into any unsupported command. But when we have unsupported add.w d1,d2... Nothing except trapping possible. The unrecognized mulu.l commands do even worse - preventing coldfire from direct (trapped) execution of 68k code.

Also, if one were to go the JIT route... then I would prefer an XScale rather than a G4, as the ARM uses less power and generates less heat and is much cheaper!

Does it have altivec-like features? How faster is it over existing G4/G5 processors? How do you manage to support 'legacy' powerup/warpup applications with it?

[lordv]

MULU and MULS instructions executed on ColdFire do not set the overflow flag. Because these are legal ColdFire instructions, with the same opcodes as the 680x0 equivalents, no exception is generated and the CF68KLib handler will therefore not be called. If the original code depends on multiply setting the overflow flag, it will need to be patched or modified to run correctly.
Certain variants of the divide instructions DIVS.L and DIVU.L behave differently under ColdFire.

Not quite right. See here for details.

http://www.microapl.co.uk/Porting/ColdFire/Download/CF68KLib.pdf

"The most significant difference between ColdFire and 680x0 is that some of the
multiply/divide instructions introduced with the 68020 do not behave the same
and do not cause an exception. The following instructions are affected:
MULS.L ,Dh:Dl (Signed multiply: 32x32 -> 64)
MULU.L ,Dh:Dl (Unsigned multiply: 32x32 -> 64)
DIVS.L ,Dr:Dq (Signed divide: 64/32 -> 32r:32q)
DIVSL.L ,Dr:Dq (Signed divide: 32/32 -> 32r:32q)
DIVU.L ,Dr:Dq (Unsigned divide: 64/32 -> 32r:32q)
DIVUL.L ,Dr:Dq (Unsigned divide: 32/32 -> 32r:32q)"

Then go to freescale.com and see CFPRM.pdf (coldfire programmers reference manual). There are NO 64bit mul/divs.
So "they behave differently" means "they just generate rubbish"!

[lordv]

@Karlos

Agreed but it isn't quite like any old JIT in that it has a much smaller transcription overhead than other JIT since the majority of any code is simply pased through the translation stage unchanged - in fact, in many cases blocks that contain no unimplemented instructions do not need to be copied at all, simply referenced.

But you can't modify the original codem because it can rely on itself in an unpredictable manner! (I think it's obvious! . So anyway mainloop is emulation and JITting of frequently-used parts.

A G4/G5 card would be great, but then there is absolutely no reason not to use MOS/OS4 on those systems instead since that will be even faster than a pure 680x0 emulation of OS3.x (by virtue of having the native OS / driver resources).

There IS reason not to use mos/os4. os3.1 is freely available to you as amiga user, while mos and os4 were made especially for some ppc workstations (wrongly called as new 'amigas'). Neither firm will release them for g4 amiga accelerator, because it will lead to decreasing of their sales.