I've got all of the SPARCstation 2's cache diagnostics passing. Now I'm on to the FPU diagnostics, which are even more brutal. I swear these tests were the product of a brilliant, but sick, mind.
Näytä tämä ketju
-
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.
Näytä tämä ketju
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.
Näytä tämä ketju -
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.
Näytä tämä ketju -
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.
Näytä tämä ketju -
So now I pretty much *need* to make the FPU execution in MAME's SPARC core occur asynchronously. And handle FP register interlocks. Oh, what a lovely tea party.
Näytä tämä ketju
Keskustelun loppu
Uusi keskustelu -
Lataaminen näyttää kestävän hetken.
Twitter saattaa olla ruuhkautunut tai ongelma on muuten hetkellinen. Yritä uudelleen tai käy Twitterin tilasivulla saadaksesi lisätietoja.