[UserReview] Vampire V2-128 received and it's just pure p0rn.

[Karlos]

For me, FPU emulation is a must. However I'd temper that by saying just the 040 FPU subset, which includes one or two operations missing on the 060fpu and be able to trap properly any missing ones so that a software solution is possible (ala oxypatcher).

To be fair, if the CPU core advertised itself as a basic 020 but silently supported the 040fpu and some other 040+ instructions like move16, lots of software would just work.

[Karlos]

From what I understand, no 68k CPU "advertise" itself, it's a matter of software trying to identify the CPU based on poking around

A software fix that just sets the flags in Exec would be enough. The idea is, the CPU looks like a vanilla 020 and that's what is set. However, unlike a vanilla 020 it will silently support the 6888x subset of instructions from the 040 and in addition, some other useful ones like the cache line move. Note that this doesn't mean it needs to emulate it exactly, just move 4 long words at a time without touching any status register bits.

Most executables compiled for 040/060 don't specifically check for it and will work, albeit very slowly on 020/88x.

The CPU emulation in OS4 is similar to this. It looks like a basic 020 but silently supports almost every user mode 68k instruction/addressing mode.

[Karlos]

A full 882 inplementation is a waste of gates. An 040 compatible FPU is all that is really needed. The 68882 transcendental instructions were so chronically slow anyway that you'd be certifiable to use then over any half decent software solution that uses simpler FPU operations. Some sort of trap and patch like oxypatxher/cyber patcher would be a nice way to get performant support for old 882 dependent code. It was good enough for the 040/060 after all.

[Karlos]

No, this is not good enough. No patcher or trapper can be used, as this is taken care of outside the scope and reach of the hardware available from the operating system and any software running on the operating system.

I think you are missing the point. Full 882 emulation is just a waste. Can you show me any software released since people first started putting 040 and 060 in their systems that still needs needs a full 882 and doesn't have a version compiled that either does not require an FPU at all or relies only on the 040/060 subset?

Even assuming no software solution could patch an 882 binary at runtime because "reasons", we are now in the realms of programmable hardware. Is there a valid reason why the FPGA implementation could not implement it's own patch to call out to a handler routine when an unimplemented opcode is  first encountered?

[Karlos]

Again my point has been missed here. Show me any 3D game on the Amiga that requires floating point (as opposed to doom like fixed point which uses approximations for trig etc) that actually uses 68882 transcendental trig functions as opposed to being optimally compiled for 040/060.

Games like Quake that use proper floating point trigonometric operations for vertex processing were already utterly useless on anything less than a 68060. The developers certainly weren't going to make that worse by using unimplemented 882 opcodes in their binaries.

Maybe, just maybe, there's an F1GP or TFX build that uses 882 for this.

[Karlos]

So, my thoughts were based on an assumption that a full 882 implementation is a lot of work and would use up a lot of gates that could be used for other stuff and the fact that most people that really needed FPU had migrated to 040 and 060 based machines and recompiled binaries that no longer used unimplemented FPU operations.

If that's not correct, then great, 882 me up.

Eagerly awaiting an A1200 version!

[Karlos]

@ThomasRichter

By "hardware" 882, I'm simply referring to the fact that the transcendenal operations were handled by the 882 itself and not with some CPU exception and call out to software as in the 040/060.

All said, I'm not bothered. My assumption that the 882 implementation came at a large expense in terms of gates which apparently it doesn't, so that's great

[Karlos]

@ThomasRichter

By "hardware" 882, I'm simply referring to the fact that the transcendenal operations were handled by the 882 itself and not with some CPU exception and call out to software as in the 040/060.

All said, I'm not bothered. My assumption that the 882 implementation came at a large expense in terms of gates which apparently it doesn't, so that's great

[Karlos]

It all depends how much lower the precision really. 64-bit and higher is generally not used except for some niches like fractal zooming at high iteration. Games and many graphical applications use 32 bit. Just take a look at modern GPUs to see how much resource is given to single precision compared to double.

[Karlos]

@ThomasRichter

I think you are overstating the case. Warp3D, MiniGL etc use 32 bit floating point almost exclusively, as does quake. In fact, there original source assembler hacks in the x87 versions to explicitly set the precision to 32-bit.

Applications using the libraries you describe are by definition not compiled for any FPU as they are relying on libraries which in turn may use FPU. Binaries compiled to use FPU directly generally will use whatever precision their use case demands. For games, that's almost exclusively 32 bit