ColdFire V4 Amiga accelerator project from the m68k emulation perspective

[jdiffend]

Does anyone actually know how many times this has already been covered?
FWIW, Motorola's own estimates of full cpu emulation based on millions of lines of existing code is much better than what is mentioned here.
BTW, the 4e core (which Motorola has been talking about with developers a lot) will help a little too.

[jdiffend]

We've been through it before but I doubt in so much depth

LOL, uh... how about a couple years ago before the last major hack of this site... like right after the V4 came out.

[jdiffend]

Running unmodified code designed for a full 680x0 computer system is not quite the same thing as Motorola intend for these devices and woud require a fair bit of work to emulate efficiently.

The entire purpose of the emulation is for running unmodified code.  They wanted companies that had invested a lot of money in 68K development not too feel like they would have to start over.

[jdiffend]

I know the info was posted because I posted it.  I copied if straight from some of the docs on the emulation and conversion tools.  That was a looooong thread mostly made up of my posts just passing on what I'd found out.  I also pointed out which of these instructions don't even work on the 060.

Any instruction that can be emulated will slow down the system but it will run.  Instructions that can't be emulated are the ones that are a problem.  

The Coldfire can't emulate some of the instructions due to the way the pipeline executes instructions.  By the time the Coldfire discovers the illegal address mode it has already modified  the program counter which makes it impossible to decode the original instruction to emulate it.  The other ones that can't be emulated are legal instructions with different behavior.

The complex address modes would result in an illegal instruction guru.  The incompatible math instructions would result in altered program behavior.  I suggested patching code that doesn't run, with illegal instructions that could be trapped.  That would let most code that couldn't be recompiled run.  The code would still run on an old cpu with an interrupt handler (similar to decigel) that patches the instructions back to their original form.  From then on they would run full speed.

Motorola's estimates for slowdown by emulating the 68K was between 10% and 20% for user mode code.  It wasn't mentioned but I'd guess you  could expect up to a 50% slowdown on when emulating both supervisor and user code with a V4 Coldfire.  That's still considerably faster than an 060.

Now, with the intro of the V4e core you'll see higher clock speeds, better compatibility (supervisor stack pointer and more address modes) and faster speed at the same MHz.  That means that even with a 50% slowdown it would still stomp on an 060.  

Oli doesn't seem to think the exec needs a rewrite to get it to boot.  If you look at my comments in other threads you'll see I don't criticize Oli's efforts but I do point out that it isn't working yet and sometimes that I don't think his emulation idea will work.

I say the exec needs to be rewritten because the supervisor stack is different on the Coldfire, the V4 (and below) has no supervisor stack pointer, the emulation interrupt handler really needs to be part of the exec's interrupt handler and a coldfire compatible exec would be much faster.  

BTW, I also posted that I thought we'd have to wait for the V4e core for it to be practicle to make a Coldfire Amiga.

[jdiffend]

The complex address modes would result in an illegal instruction guru.

Actually, it's been a while since I looked at the guru docs or code so it may be something else.

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.

[jdiffend]

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

It's not quite that simple.

Let's see... you build the emulation for 020 since it will emulate the most instructions that way and give you the most compatibility... and then a program thinks it's running on an 020 and decides to use some of the 020 address modes that can't be emulated.

68000?  Some software won't like that and it won't be as fast.

For the best speed, setting bits for 060 would work unless the software tries to detect the CPU.  So you drop the extra compatibility for that reason. But there's no FPU or MMU emulation so that's still a problem.  Ummm... does the emulation code even offer 060 compatibility?  Didn't used too.  We could do our own by removing instrucitions from the 020.

Or go with the ec040.  It wouldn't require as many mods to the code as for the 060
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.

Then enters the V4e or higher core which has FPU and MMU... but they aren't quite the same as 68060 versions.

The point was making it possible to detect a coldfire without every program having to detect it on their own and still having existing software identify it as the cpu it's emulating.

[jdiffend]

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.

It's only a couple address modes that can't be emulated through the illegal instruction trap.  Since the program counter is modified before the illegal address mode is detected by the Coldfire the trap doesn't know what address the instruction that failed was at.

The mpy/div instructions cam't be emulated with an illegal instruction trap because they are legal instructions on the Coldfire... they just work different.

My proposed solution to this was to write a full 68K emulator that tracks the original hunks from the load file so that the emulator patches the code on disk whenever it encounters an instruction that can't be emulated with a trap.  The patches are done with illegal instructions that can be trapped.   Once the program has been run enough a patch file can be built and distributed.  The Coldfire can then trap and emulate the instruction.  To run it on a 680x0 you have to catch the exceptions and patch the instructions back to what they were... how difficult that is depends on what illegal instructions remain unused on the 68K/Coldfire. Basicly UAE with the ability to patch the file or build a patch file.

A full JIT emulator is definately possible and would be simpler than for another CPU family.  What it wouldn't do that the trap method does is take advantage of new Coldfire CPUs that add more compatibility with 68K code.  At least not without changes for each new CPU.  As newer CPUs are release the trap method takes advantage automatically because less traps are generated and the code doesn't care.  We also have the instruction trap emulation code now.

The good news about the address modes that can't be trapped is that they are slow so it's doubtfull a compiler will generate them and they rarely appear in assembly code.  These instruction/address modes only appear on the 68020 if I remember right.

I think your solution to the speed/AttnFlags/new api issue is pretty close.
Untill better 060 emulation is available let the speed suffer.  Not much choice in the matter.  
Create a standard api to query CPU type for new apps.
Hope for the best on old software.
I suppose the speed/AttnFlags could be set through a prefs option so programs that don't use the math chip could select 68060 routines for C2P and other functions that might benefit.