Arculator's FPA10 emulation defines instructions a real FPA10 doesn't

[Sophira]

Hello,

An interesting Arculator bug was found recently on one of my Stardot forum threads. It appears that *Unplug'ing the FPEmulator module on a RISC OS 3.11 machine with an FPA10 inside and then rebooting has different effects on Arculator vs. real hardware:

• On Arculator, the desktop will load successfully.
• On real hardware, the desktop fails to load with an "undefined instruction" error at &03877AC8, which is an RFS instruction.

The real hardware behaviour can be replicated on Arculator by disabling FPA10 emulation, which suggests that the FPA10 emulation is providing the RFS instruction when the real FPA10 does not.

I don't know what other instructions this might apply to, so I don't feel comfortable trying to fix this myself as I don't have real hardware to test it, unfortunately.

[Sophira]

It seems there might be more to this, which I don't fully understand. From the forum thread:

The FPA macrocell docs do say it provides RFS, so I'd guess that the issue may be down to how ARM handles the illegal instruction - with no FPEmulator module, there's nothing to trap the 'faulty' CoPro instruction and divert it to the FPA - so I'd have to guess Arculator's doing that in some other special way. But honestly I don't how if ARM somehow has some actual way of auto-sending unknown instructions to CoPros rather than the trap for software emulation.

I'm not altogether sure how this works but figured I should pass it on. Also, I edited my opening post here to reflect that the error is an "undefined instruction" error rather than an "illegal instruction" error, as per the thread.

[IJeffray]

FPA support module is pretty huge... https://github.com/stardot/RiscOS_371/tree/master/Sources/OS_Core/HWSupport/FPASC/coresrc/s