>> Part of the problem is that masking FP exceptions is system wide with the
>> ARM FPA/FPE. To support different exception masks for different processes
>> would mean FP instructions to save and load the FP control register on every
>> context switch.
>
>FP context switch!

Very true... Ideal case would be if the FPE core could tell us if the context
has changed.. Hmm Nope that is not good enough.
I guess we need to turn the FPE/FPA off on a context switch and re-enable it
on the first FP instruction.
Not sure how friendly the ARM FPE/FPA is when you try and do this ...

>Hmm, I haven't looked at the code, but what is the problem to save/restore the
>exception bits when you already have to save/restore the registers anyway?
>Surely the FP registers are much more stuff than the exception bits, aren't
>they?

Yes in theory the control register is just an extra word. The problem is the
that the save/restore of the context is done by the FPE core and the contexts
do not appear to change the FPCR. Certain save/load context routines do not
include the FPCR. This means that the mcr/mrc instructions for coproc 1 would
be needed to extract the information out of the core. This is the time
consuming bit ...

Currently the FPE core is an unchanged ARM Ltd one and gets treated as a black
box.

>> The exception number is the key. In my book divide be zero exceptions etc
>> are ok as the result is undefined.
>
>Don't have the definition available, but I'm pretty sure that it is a
>requirement for the OS to make it possible to modify the behaviour of an
>application on FP exceptions.

Currently the libc functions fpsetmask() and similar functions just
call abort() if they are used.
I did this as user processes cannot change the FPCR (requires SVC mode) and
I had not implemented a solution.

This means that I need to implement arch specific functions (in libarm32.a ?)
that will call the kernel to change the FPCR before I can make these functions
work properly.

I could implement masks to stop the signal delivery of specified exceptions
but the core would still have generated the exception rather than storing
Inf or Nan in the result etc.

I think Neil and myself may need to do a bit of rumaging in the FPE source to
try and clarify behaviour.

Cheers,
				Mark

-- 
Mark Brinicombe				amb@physig.ph.kcl.ac.uk
Research Associate			http://www.ph.kcl.ac.uk/~amb/
Department of Physics			tel: 0171 873 2894
King's College London			fax: 0171 873 2716