On Mon, 8 Apr 2002, Jun Sun wrote:
> Generally interrupt dispatching belongs to machine/board-specific code. So I
> think FPU exeption through an interrupt is probably best handled within DEC's
> code, instead of being generalized to the common code.
The dispatching of the FPU interrupt for the DECstation is local to
DEC-specific code (note that it's so mainly due to performance reasons
anyway -- there is no problem with making dispatcher's code common with
appropriate backends installed for different IRQ types, like it is already
done in generic controller-based IRQ handling code). Any other system
using a CPU/FPU in such a configuration has to provide its own dispatcher.
The handler for the FPU interrupt is the very same handler used for the
FPU exception; only a different entry point is used to accomodate the fact
registers are already saved on the stack.
And for safety you don't want the FPU exception handler to be enabled for
FPUs that report exceptions via an FPU interrupt. For such systems a
spurious FPU exception should be treated as a system error.
> In addition, conceptional you might have a system where FPU exception is
> handled through an interrupt and yet CPU has FPU exception.
Not quite. The FPU exception is not maskable, so you can't make a choice
at the run time. It has to be hardwired.
> Of course abstraction and generalization can happen later when it becomes
> obvious. It is just not obvious, at least to me.
MIPS_CPU_FPUEX is specific to the CPU not to the system. IDT R3081 is
another example (mysterious R3400 used in DECstation 5000/240 being the
first one) of a CPU with an integrated FPU unit which is logically
external and uses an interrupt to report FPU exceptions. And all R2k/R3k
setups using a physically separate FPU deliver FPU exceptions via an
interrupt line. I can't see a reason why to handle this option in
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+ e-mail: firstname.lastname@example.org, PGP key available +