A Moogle  🏳️‍🌈 💻 🎮 🎶 🇸🇪

First it tests storing a double-precision value to an unaligned address. Fair. Then it tests single-precision arithmetic. Also fair. Then it tests the five exception types. Still fair. Then - Exception and Timeout Test. Wait, what? I'll tell you what.

There's a divide, with a divisor of zero, then a store of the FP register containing the result into unmapped memory. If you emulate FP instructions synchronously, as I do, the divide by zero exception will be taken, handled, then a memory exception occurs from the store.

But FP insns happen asynchronously. The IU will move right on to the store insn, but since the store source is the in-flight FP reg, the CPU will interlock on the FPU during execution. The zero-divide exception hits, then the exception handler returns to the instruction after it.

So as a hack, let's still advance the program counter despite a pending FP exception. Great, two more self-tests pass. Now the "FPU Exception and Misalignment Test" fails - *because* there's a divide-by-zero exception. Why? I'll tell you why.

Misaligned stores are detected during the decode stage. So while the FPU is asynchronously gearing up for a divide-by-zero exception, the IU fetches the store insn, decodes it, and triggers a misalignment exception.