ColdFire V4 Amiga accelerator project from the m68k emulation perspective

[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.

[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).

[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.