|
Message
From: Matt Porter<mporter@k...>
Date: Tue Dec 30 15:16:22 CET 2003
Subject: [openrisc] FPU
On Mon, Dec 29, 2003 at 05:20:39PM +0100, Damjan Lampret wrote:
> Hi All,
>
> I'm integrating a FPU into OR1200. Openrisc architecture defines FP
> instructions however it doesn't defines some additional results of FP insns.
> For example FP insns can produce the following flags: not a number,
> underflow, overflow, invalid result, infinity, divide by zero etc. Question
> is, should this flags be available to the user or not? If yes, how should
> they be available? Also FPU supports different rounding modes. Two control
> bits can control rounding mode. I see two ways:
> 1) SR register
> 2) FPU specific SPR
>
> For result flags I prefer FPU SPR because SR doesn't have to be modified by
> adding these special flags. However to control FPU rounding modes if FPU SPR
> is used, and there are different user applications running that use
> different rounding modes, then FPU SPR would have to be saved by context
> switching code. So in a way using SR for rounding control bits would already
> save FPU rounding mode by current context switching code.... Also should
> some FP result flags cause an exception - for example divide by zero flag?
Yes, this is needed to implement userspace SIGFPE handlers on Linux.
On other architectures (PPC, i386) this is accomplished by having a
control register (the FPU SPR) that is user accessible. Setting various
bits will cause the FP exception to be taken which allows linkage to
a userspace handler to do the right thing. Note that this also allows
for lazy context switching which is a big performance advantage since
it is not necessary to context switch all the FP regs for every process.
> Which exception should happen? Also keep in mind that there are probably two
Ideally, a separate FPU exception...though I've been lurking for a while
I don't know how fluid the OR1K arch spec is.
> scenarios: 1) Embedded applications where application software can run also
> in supervisor mode and could easily switch between different rounding modes
> etc. And 2) Linux type of application code where there is a big difference
> between user application code running only in user mode and OS running in
> supervisor mode - in this case user code can or should be able to set
> rounding modes or not - SR can onyl be written in supervisor mode... By the
> way how can application SW under Linux/I386 change rounding modes?
The old way is using /usr/include/{i386}/fpu_control.h to directly
manipulate it. Later versions of glibc have versions for other
arches, but it has all been dropped for the ISO C99 controls in
/usr/include/fenv.h.
> So what do you think is the best way to incorporate FP support? Remember
> maybe result flags are not needed, and only one rounding mode is enough?
>
> I copy Stefano who developed the FPU and has a lot of experience with the
> rounding modes etc. I remember Stefano you once told me that only one
> rounding mode is usually used and the other two and rarely used.
I'm not a FP expert since I mostly do PPC kernel work, but I see
that scientific apps make the most use of multiple rounding modes.
If nothing else, it would be useful to support multiple modes to ensure
portability of user apps to OR.
I'd suggest the following:
* A floating point exception
* A user-accesible FP SPR providing:
- control/status bits for divide-by-zero, underflow, overflow, etc
exceptions.
- control bits for rouding modes.
-Matt
|
 |
Browse
