I wouldn't call trapping 1/2 the 68k instructions on a ColdFire as "running native". It would destroy performance and thus the reason why Cod3r made an emulation layer. It's probably the same idea as OxyPatcher/CyberPatcher/MuRedox does for FPU instructions before they are trapped. It no doubt is easier to emulate the 68k on a ColdFire because of it's architectural similarities but the slow speeds and handicapped performance of the ColdFire make up for any advantage. Motorola/Freescale decided that the 68k can't compete with the PowerPC so they have been crippling it ever since the 68060 outperformed early PowerPCs. Freescale would rather develop weak sauce scaled down 68k like ColdFire micro-controllers and pay ARM licensing fees for an inferior product than use a little initiative to come up with an innovative and modern 68k design. It would be easier to run ColdFire code on a 68k processor. Not counting MAC or FPU instructions, there is only 6 or 7 instructions to trap at the user level and the emulation could be put in the CPU libraries. Freescale/Motorola did put MOV3Q in the A-line so no more 68k Macintosh emulation, REMU/REMS is not fully compatible with the DIVS/DIVU instruction and the ColdFire stack is 32 bit aligned instead of 16 bit aligned so there are "problems". The best bet for 68k and ColdFire native is probably in a new fpga CPU and possibly an ASIC after that. I have been working on a new ISA called 68koolFusion. The current evaluation documentation has BYTEREV, BITREV, FF1, SATS, MVS, MVZ, REMU and REMS. MOV3Q is weak and we found better ways to have the best code density in the industry (should easily beat ARM with Thumb 2 and CF 
. Some CF instructions have different encodings or mnemonics though. BYTEREV and BITREV are mnemonics for the new PERM instruction, FF1 is a mnemonic for BFFFO and REMU/REMS weren't compatible with the 68k as is. MVS, MVZ and SATS are encoded the same as the CF. That's as close as you will get to running "native" 68k and CF code.
http://www.heywheel.com/matthey/Amiga/68kF_PRM.pdf
@Cod3r
Nice work. The CF is weak but it does have 2 advantages and that's the built in hardware support (SoC) and price. I wondered why the Natami didn't use the CF for the hardware support considering the price and use the fpga for the main processor and Amiga chipset emulation. The CF could be used like a simple sound DSP also. SMP would not be easy to add but the Amiga has always been about coprocessors . The fpgaArcade offloads some of the work and processing to it's ARM processor but the CF would be more familiar to Amiga programmers even if it's a watered down 68k microcontroller for the hardware. Add an fpga of Cyclone III size or bigger for the 68k and chipset emulation with basic hardware support like ethernet, USB and PCI through the CF and do it for less than $500 U.S. and you might have a winner. There is fpga code for 68k processors and the AGA chipset available to enhance and put in the fpga.
What I did was straight up emulation... no trapping or anything. I created a few psuedo-instructions that would allow the supervisor to activate a few native routines on the ColdFire, but that was about it.
Aros isn't aware it is running on a CF and other than optimizations I added for speed (that were called by my psuedo instructions), the whole OS basically ran on pure 68k code. The 68k emulator I wrote is called after initialization prior to loading the OS.
I agree that it isn't the fastest solution, but it works and it is clock-cycle accurate so that makes it really stable for software that doesn't work well with JIT emulation.
And ColdFire development boards are relatively inexpensive, so a complete system could easily be built under $500 USD.
