68060 and the 68882

[Karlos]

So, potentially, we could run a 75Mhz 68EC060 and a 50Mhz 68882 (both with heat sinks and fans) at 100Mhz?

I'd be surprised if the 68882 lived for very long at 100MHz as that's a factor of 2 overclock from their highest rating. Remember that the last mask 68060's run at 100MHz due to their improved manufacturing tolerances and also the fact they are 3.3v parts which dissipates less heat than 5V logic.

At 100MHz, and with appropriate care taken to the method (eg, trap and patch rather than trap and emulate) you'd probably be able to write a software floating point library that is faster than you'd get a 68882 running in any case.

[Karlos]

Karlos, where can I learn about both trap and patch and trap and emulate? Specifically, I'm interested in the trapping of FPU calls and the potential to improve upon them.

Trap and emulate is one of those things that the 680x0 programmer manuals will tell you about. All you are doing is implementing your own exception handler and then writing some code to deal with the exception (note that this all happens in supervisor state and you need to know the layout of your 680x0 exception stack frame which do vary from CPU to CPU).

You can write a handler to do some specific bit of work and then have it return. Normally, you'd write the handler to implement the unimplemented operation and return from the exception. However, you can go a step further and patch instead. Basically what you do here is modify the opcode that resulted in the exception and have it jump to a location of your choosing. If you are not fairly comfortable poking around in 680x0 supervisor mode this is not trivial to do, you have to be careful how much space there is to insert your jump and also you have to make sure you flush the instruction cache and so on. However, this is the basic gist of how tools like CyberPatcher and OxyPatcher do their magic.

I'm not sure if it will help you much but I played with some CPU exception handling a few years ago on 680x0 albeit for a different purpose:

http://www.amiga.org/forums/showthread.php?t=25181

In this case, I was using the CPU to trap illegal operations and have it invoke a language level exception mechanism (a C++ throw in this case). It does demonstrate some of the sneaky shenanigans you can get up to though.

[Karlos]

A further question. On 68Ks without FPUs, do all floating point operations produce exceptions?

Any opcode (floating point or otherwise) not implemented by the CPU will result in an unimplemented/illegal opcode exception.

Further, would it be possible to program an FPGA to emulate (or improve upon these trapped illegal opcodes?

Well, however you decide to implement your trap handler, the cost of invoking the exception mechanism is what kills you. For a fast 68060, I'd strongly advocate trap-and-patch, which only goes through the exception handler once for each encountered illegal opcode, over any mechanism that requires the exception to happen every time it hits said opcode.

The next decision is, how to implement the desired operation. Performing complete emulation of floating point on the 68060 will not be that fast (probably faster than a reeal 68882 for well-written, superscalar 68060 code) but I am not sure how you'd invoke an external FPGA device to do it. Unless it's a memory mapped bit of hardware that you can move data to and read back from. IIRC, on the 68020, the CALLM instruction allowed the invoking of external processors but that instruction is missing on later parts.

[Karlos]

Sounds interesting. If I can find a way to develop trap and patch code that relies on a external memory mapped peripheral I may be able to increase the speed of the math operations.
An FPGA is not the only option for this peripheral, I'm also considering what could be done with an e300 class PPC (which would be cheaper than an FPGA).

I fear that approach is taking you down the path towards cache coherency issues.

Remember, you would either have to make sure that any memory shared between both processors was either uncached by both, or you'd have to take care to flush cache lines, which can be expensive. All of which is taking you back to where PowerUP and WarpOS were, except you'd be getting cache issues per externally-handled instruction.