ColdFire V4 Amiga accelerator project from the m68k emulation perspective

[Piru]

Original & revised document is available at http://www.iki.fi/sintonen/coldfire-v4-m68k.txt v1.0.2   28-Jun-2003

 ColdFire V4 Amiga accelerator project from the m68k emulation perspective
                                 by
                   Harry Sintonen


MCF5407's V4 ColdFire core adds Revision B of the instruction set. At first
glance it looks like it really adds lots of improvements especially suited
for the m68k emulation, however a closer examination reveals the grim truth:
These additions help only a little, more likely not at all.


Examining the CFPRM.pdf(1), the MCF5407UM.pdf(2) and the M68000PRM.pdf(3)
reveal that a lot of m68k features are missing.



V4 COLDFIRE CORE REVISION B INSTRUCTION SET IMPROVEMENTS


The improvements in Revision B of the instruction set for m68k
compatibility are:

long offset for Bcc/BRA/BSR
byte/word sizes for CMP, CMPI
word size for CMPA
byte/word sizes for MOVE.[BW] #,d16(Ax)



MISSING ADDRESSING MODES


Address Register Indirect with Index
  Base Displacement  (bd,An,Xn)

Memory Indirect
  postindexed (od,[bd,Ax,Xn])
  preindexed  ([bd,Ax,Xn],od)

Program Counter Indirect with Index
  Base Displacement  (bd,PC,Xn)

Program Counter Memory Indirect
  postindexed (od,[bd,PC,Xn])
  preindexed  ([bd,PC,Xn],od)



MISSING SIZES FOR OPCODES


add .b .w
adda .w
addi .b .w
addq .b .w
addx .b .w
and .b .w
andi .b .w
and .b .w
andi .b .w
asl .b .w
asr .b .w
lsr .b .w
lsl .b .w
eor .b .w
eori .b .w
movem .w
neg .b .w
negx .b .w
not .b .w
or .b .w
ori .b .w
sub .b .w
suba .w
subi .b .w
subq .b .w
subx .b .w
[probably missed some]



COMPLETELY MISSING OPCODES


BCD missing (binary coded decimal, virtually unused)
bit field (bf*, rarely used, 020 XPK SQSH)
logical rotate (rol/ror roxl/roxr)
DBcc, (dbra/dbf, dbne, dbeq etc, used a lot)
mulu/muls 32*32->64 (used a lot)



CONCLUSION


All the missing addressing modes, opcodes and sizes for opcodes need to be
emulated. Especially common math operations like add, and, asl, eor, neg,
not, or, sub for sizes .b and .w will be met a lot. Also rol and ror are
common and will need to be emulated. DBcc is common in loops, and need to
be emulated aswell.

My conclusion is that MCF5407 with the V4 ColdFire core will be unbearably
slow when executing average m68k code typically found in the Amiga
environment. I'd estimate that the overall performance drops below MC68060
@ 50MHz performance.

The situation can be improved by replacing slow programs and os components
with specially ColdFire optimized code or by doing just-in-time
recompilation.

Another possibility is to use CyberGuard/OxyPatcher method to replace the
emulated opcodes with 'jsr (abs).w' to low 64K memory and that will contain
the emulation routines (or JMP to actual code, if 64k is not enough to hold
all the emulation code).

However, with such method new problems arise:
- ROM code cannot be patched (can be worked around with MMU ROM mirror)
- Some software do checksum of their code (virus checkers, Elbox drivers)
  This problem can perhaps be worked around with different code and data
  virtual memory space. However I didn't look closer at ColdFire to see if
  this is possible.



REFERENCES


1) CFPRM.pdf     ColdFire Family Programmer's Reference Manual

2) MCF5407UM.pdf MCF5407 ColdFire(r) Integrated Microprocessor User's Manual

3) M68000PRM.pdf Motorola M68000 Family Programmer's Reference Manual


--- edit ---
Updated to 1.0.2

[Piru]

Sorry for the double thread post, but I couldn't figure out how to rename the first thread.
Moderators: Please delete the dupe without topic.
Suggestion: Make it impossible to post a thread without topic. :-)

--edit--
Ok the bogus thread is gone now. Good.

[Piru]

BTW, one of the problems I saw while working on the ROM disassembly was just what bits do you set to identify a Coldfire CPU? I know how to detect it but after I do... then what? Programs need to be able to identify it and there is no standard.

Excuse me?
Of course it would set the SysBase AttnFlags to identify the CPU/FPU it is emulating.

No program need to know that it is really running under ColdFire and not real m68k CPU.

identify.library is open source nowadays, it could be easily expanded to report ColdFire CPU. That's how system information programs would know about the CPU.

However, this is all theoretical until the card is actually working.

[Piru]

It's not quite that simple.
*** useless blabbering snipped ***

Of course it is not.

However, either you emulate the CPU/FPU fully or live with the problems that arise from the missing EAs.

m68k supervisor mode can't be emulated anyway, since ColdFire (even V4e) is totally different beast in there. So m68k MMU can never be supported.

So we're left with m68k CPU and FPU emulation on user level.

Either we live with the fact that some addressing modes crash the app (I take your word here that these exception can't be emulated. Personally I consider it possible though with some magic. Remember how tricky 68060 exception restart is? Yet it can be done), or we do JIT translation in the first place, where we handle these missing addressing modes by generating native ColdFire code for them.

A Coldfire aware program still can't tell which optimized c2p routine or math functions would be best to use without detecting the CPU itself which defeats the purpose of the AttnFlags in the first place.

Sigh. AttnFlags is just for the app to know which CPU and FPU are *EMULATED* so it doesn't crash outright.

If there is some control wanted for special ColdFire aware applications, new Query API need to be added. I suggested identify.library. It can be whatever the system designer sees feasible. Anyhow, this stuff is trivial compared to the actual m68k emulation.

Naturally unless if the application is specially crafted for Coldfire, it doesn't need to know about this API since it can't make any reasonable judgement anyway. If the app is ColdFire aware, it knows the API and can query the ColdFire CPU type and pick proper routines.

So there is no problem here. Also similar stuff has been successfully implemented for MorphOS years ago.

MorphOS always identifies 68060 + 6888x/68060FPU in the AttnFlags. There are further APIs to identify the host PPC type (ppc.library emulation, powerpc.library emulation, and native NewGetSystemAttrs call).