68060 and the 68882

[psxphill]

So to claim that "there is nearly NO software that takes advantage of a peripheral math copro" is absolute nonsense, you either haven't looked hard enough or don't use a FPU otherwise you would already know this...

He's talking about using a 68881/68882 in memory mapped mode. I don't remember any software supporting that on the Amiga, you'd struggle to actually find the hardware as well. It was only the 68000/68010 that needed it, on the 68020+ it worked as a coprocessor.

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

[Iggy]

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

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

[Iggy]

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.

I was not thinking of caching at all. Just a very small memory mapped area for exchange.

[matt3k]

I clocked my 882 on my 3k motherboard to 50 about 15 years ago.  Runs perfect to this day...  Suspect with a heat sink 75 should be easily achieved.

Good luck!

Matt

[a1200]

@iggy

Sorry to drag up a very old thread but I read this with interest. I couldn't fathom why you needed to to run an 060 at 100MHz and even more confusing was what application you had for running the FPU so hard? Only things I could think of was you are doing raytracing, or you are a scener but at demo parties the productions need to run on the party machine - usually an 060 at 50 to 75MHz or you are one of those overclockers who would think of nothing about cooling their system with liquid nitrogen just because they can!

[Acill]

@iggy

Sorry to drag up a very old thread but I read this with interest. I couldn't fathom why you needed to to run an 060 at 100MHz and even more confusing was what application you had for running the FPU so hard? Only things I could think of was you are doing raytracing, or you are a scener but at demo parties the productions need to run on the party machine - usually an 060 at 50 to 75MHz or you are one of those overclockers who would think of nothing about cooling their system with liquid nitrogen just because they can!

I have upgraded plenty of Apollo 1260, Blizzrd 1260 and even a few CS-MKII cards to 100+Mhz using the rev 6 version of the full 68060. It runs wuite cool and has been done by a lot of people. Even more so in a CD MKII. I have seen those do 120Mhz.

[guest11527]

Thomas Richter created a program much like OxyPatcher called MuRedox that avoided the trapped instructions with replacement code on the fly. He posts on the Natami forum frequently. His code would need a fair amount of work to support all FPU instructions though. Optimized 68060 integer code and no traps should be faster than a 68882.

Sorry for necro-bumping this, but just one correction: MuRedox *does* patch all FPU and integer instructions, quite unlike other programs. The interesting part of it is a "code generator" that creates the necessary stub-code on the fly. That is, if a missing instruction is used for the first time, the program appears a little bit slower as MuRedox first needs to create the necessary code, but it will "learn" quickly.

[psxphill]

Sorry for necro-bumping this, but just one correction: MuRedox *does* patch all FPU and integer instructions, quite unlike other programs. The interesting part of it is a "code generator" that creates the necessary stub-code on the fly. That is, if a missing instruction is used for the first time, the program appears a little bit slower as MuRedox first needs to create the necessary code, but it will "learn" quickly.

does it work if you have a 68060 without an mmu or fpu?