On Sun, 28 Feb 2016 09:43:21 -0000, "Bill Davy" <Bill@SynectixLtd.com> wrote:> ><upsidedown@downunder.com> wrote in message >news:afb5dbp4n29fep9p7utnlagi9rpunudmld@4ax.com... >> On Sat, 27 Feb 2016 23:31:38 -0500, rickman <gnuarm@gmail.com> wrote: >> >>>On 2/27/2016 10:24 AM, Bill Davy wrote: >>>> "Tim Wescott" <seemywebsite@myfooter.really> wrote in message >>>> news:UJednYstNY8hN03LnZ2dnUU7-YudnZ2d@giganews.com... >> >> >> <clip> >> >>>> Taking a punt here but things I would wonder about: >>>> >>>> Has something changed the operating set-up of FP unit? >>>> Could an interrupt be coming in, saving and restoring FP result? >>> >>>I'm not certain an interrupt would cause this problem. 80 bit floating >>>point is a valid size for calculations. The interrupt code won't know >>>how the floating point registers are being used so it will have to save >>>and restore the full state of the FL unit rather than truncate the >>>values before saving. >> >> It is very hard for me to understand why someone would need to use >> floating point instructions in the ISR, thus no need to save and >> restore the FP stack. >> >> Usually there is something seriously wrong with the program >> architecture if you _have_to_ use FP in ISR. >> >> >> > >I agree it is neither nromal nor desirable to use Fp in an ISR but (a) >someone else may have written the ISR, and (b) s**t happens, and (c) when >you have discounted everything else ... >Floating point instructions have various kinds of traps or faults (whatever you call them) such as division by zero, A trap service routine is more or less similar to an ISR and in general, you do not want to trigger an other ISR from within an ISR. There are priority issues, is the original ISR be interrupted by the trap or should it be suspended after the ISR returns (but then the ISR can't use the result of the trap). Neither do you want to have e.g. a segment fault within, which usually results in a more or less well handled OS crash.
Damned floating point
Started by ●February 26, 2016
Reply by ●February 29, 20162016-02-29
Reply by ●February 29, 20162016-02-29
On 28/02/16 19:10, Paul Rubin wrote:> upsidedown@downunder.com writes: >> It is very hard for me to understand why someone would need to use >> floating point instructions in the ISR, thus no need to save and >> restore the FP stack. > > I have to wonder what x86 model this is running on and what compiler, > since it occurs to me that x86 floating point computation is typically > done these days with XMM instructions rather than the x87 (stack based) > instruction set. I don't know what that does to the 80 bit intermediate > results. I guess Tim has deadlines to meet and is happy to have put the > issue behind him with a workaround but it would be interesting to see > the assembly code that came out of the compiler from his code. >No, floating point is typically done with x87 instructions when you are compiling as "32-bit x86 code that works on anything" - which is typically the default setting for x86 32-bit compilers. XMM registers and instructions will only be used if you set the minimum target requirements to something a little higher, using appropriate compiler flags. Obviously if you are interested in performance you will do that - in most cases, you can rely on the user having something more recent than an early Pentium. But you have to make an active decision to do this. I can only make guesses about how Tim set up his build, but my guess is that he only bothered with simple flags like "-O2 -Wall -Wextra", rather than figuring out what architecture flags were appropriate for a good balance between speed and portability, because code efficiency was not particularly important.
Reply by ●February 29, 20162016-02-29
On 28/02/16 09:25, upsidedown@downunder.com wrote:> On Sat, 27 Feb 2016 23:31:38 -0500, rickman <gnuarm@gmail.com> wrote: > >> On 2/27/2016 10:24 AM, Bill Davy wrote: >>> "Tim Wescott" <seemywebsite@myfooter.really> wrote in message >>> news:UJednYstNY8hN03LnZ2dnUU7-YudnZ2d@giganews.com... > > > <clip> > >>> Taking a punt here but things I would wonder about: >>> >>> Has something changed the operating set-up of FP unit? >>> Could an interrupt be coming in, saving and restoring FP result? >> >> I'm not certain an interrupt would cause this problem. 80 bit floating >> point is a valid size for calculations. The interrupt code won't know >> how the floating point registers are being used so it will have to save >> and restore the full state of the FL unit rather than truncate the >> values before saving. > > It is very hard for me to understand why someone would need to use > floating point instructions in the ISR, thus no need to save and > restore the FP stack. > > Usually there is something seriously wrong with the program > architecture if you _have_to_ use FP in ISR. >That makes no sense whatsoever. You use the features you need, inside an ISR or not. Obviously you /usually/ want to keep ISRs' runtimes short, but there are exceptions - a task switcher will often be done as part of an ISR, and you may have an arrangement with nested ISRs where the outer ones can be long running. And why would you think that floating point is slow or otherwise unsuitable for an ISR? Software floating point on an 8-bit AVR is slow, but on an x86 the basic FP operations are no slower than basic integer operations. On an ARM Cortex M4F and many other embedded microcontrollers with floating point hardware, as long as you are careful to stick to single-precision and use "-ffast-math", your basic floating point operations will be single cycle. Certainly "real" floating point code will be smaller and faster than using scaled integers and shifting to emulate it.
Reply by ●February 29, 20162016-02-29
On 29.2.2016 г. 09:47, David Brown wrote:> On 28/02/16 09:25, upsidedown@downunder.com wrote: >> On Sat, 27 Feb 2016 23:31:38 -0500, rickman <gnuarm@gmail.com> wrote: >> >>> On 2/27/2016 10:24 AM, Bill Davy wrote: >>>> "Tim Wescott" <seemywebsite@myfooter.really> wrote in message >>>> news:UJednYstNY8hN03LnZ2dnUU7-YudnZ2d@giganews.com... >> >> >> <clip> >> >>>> Taking a punt here but things I would wonder about: >>>> >>>> Has something changed the operating set-up of FP unit? >>>> Could an interrupt be coming in, saving and restoring FP result? >>> >>> I'm not certain an interrupt would cause this problem. 80 bit floating >>> point is a valid size for calculations. The interrupt code won't know >>> how the floating point registers are being used so it will have to save >>> and restore the full state of the FL unit rather than truncate the >>> values before saving. >> >> It is very hard for me to understand why someone would need to use >> floating point instructions in the ISR, thus no need to save and >> restore the FP stack. >> >> Usually there is something seriously wrong with the program >> architecture if you _have_to_ use FP in ISR. >> > > That makes no sense whatsoever. You use the features you need, inside > an ISR or not. Obviously you /usually/ want to keep ISRs' runtimes > short, but there are exceptions - a task switcher will often be done as > part of an ISR, and you may have an arrangement with nested ISRs where > the outer ones can be long running.Obviously a task switch exception using FP would be a frequent case but I think he did not mention it in this context because it is an obvious exception. As a rule, you practically don't use FP in an ISR - apart from the case mentioned. Then even during a task switch sometimes the OS may not use the FPU (e.g. in DPS each task can turn FPU usage on/off in order to prevent saving all the FP regs - 32 64 bit ones, in fact many times it is done dynamically within a task).> And why would you think that floating point is slow or otherwise > unsuitable for an ISR?There are many reasons why, I think he already listed some in another reply to someone else. It makes life more complex - FP exceptions because of data variations are no rarity, these will have to be excepted from your IRQ handler. Not the greatest idea. Then the IRQ handler writer will have to be aware of all the subtleties about saving/restoring the FPU context, mainly the FPSCR and other registers with all interdependencies etc. which may well vary between implementations on the same architecture; whereas a plain integer unit IRQ handler will take a lot less knowledge to write. That being said using the FPU in an ISR is certainly possible, however I would like to see some real examples when this might do you any good. Have you _actually_ written an IRQ handler which does use FP opcodes? (Other than the obvious case of a task switch of course). Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/
Reply by ●February 29, 20162016-02-29
On 29/02/16 09:17, Dimiter_Popoff wrote:> On 29.2.2016 г. 09:47, David Brown wrote: >> On 28/02/16 09:25, upsidedown@downunder.com wrote: >>> On Sat, 27 Feb 2016 23:31:38 -0500, rickman <gnuarm@gmail.com> wrote: >>> >>>> On 2/27/2016 10:24 AM, Bill Davy wrote: >>>>> "Tim Wescott" <seemywebsite@myfooter.really> wrote in message >>>>> news:UJednYstNY8hN03LnZ2dnUU7-YudnZ2d@giganews.com... >>> >>> >>> <clip> >>> >>>>> Taking a punt here but things I would wonder about: >>>>> >>>>> Has something changed the operating set-up of FP unit? >>>>> Could an interrupt be coming in, saving and restoring FP result? >>>> >>>> I'm not certain an interrupt would cause this problem. 80 bit floating >>>> point is a valid size for calculations. The interrupt code won't know >>>> how the floating point registers are being used so it will have to save >>>> and restore the full state of the FL unit rather than truncate the >>>> values before saving. >>> >>> It is very hard for me to understand why someone would need to use >>> floating point instructions in the ISR, thus no need to save and >>> restore the FP stack. >>> >>> Usually there is something seriously wrong with the program >>> architecture if you _have_to_ use FP in ISR. >>> >> >> That makes no sense whatsoever. You use the features you need, inside >> an ISR or not. Obviously you /usually/ want to keep ISRs' runtimes >> short, but there are exceptions - a task switcher will often be done as >> part of an ISR, and you may have an arrangement with nested ISRs where >> the outer ones can be long running. > > Obviously a task switch exception using FP would be a frequent case but > I think he did not mention it in this context because it is an obvious > exception.Fair enough.> As a rule, you practically don't use FP in an ISR - apart from the > case mentioned. Then even during a task switch sometimes the OS > may not use the FPU (e.g. in DPS each task can turn FPU usage on/off > in order to prevent saving all the FP regs - 32 64 bit ones, in fact > many times it is done dynamically within a task).Obviously you don't use FP in an ISR if you don't need it - and ISR's typically do not need FP. That would be the main reason for not using FP in ISR's! If you need to stack and restore a lot of FP registers, then that can take time (although on some embedded processors, like the MPC5674, FP is done using normal GP registers rather than an additional register set). If your ISRs are short and avoid calling other functions (at least, those that are not static or inline or available through LTO) then no registers, FP or GP, need to be stacked unless they are used.> >> And why would you think that floating point is slow or otherwise >> unsuitable for an ISR? > > There are many reasons why, I think he already listed some in another > reply to someone else.He mentioned traps or faults, such as from division by 0. There are a few points here. First, don't divide by zero - that would be a bug in the program. Second, use FP modes, instructions and compiler settings that assume the FP operations are done on reasonable operands, and disable such traps or faults (-ffast-math on gcc). Third, on many embedded processors (like the Cortex M4F), the FP instructions don't have any traps or faults. Fourth, if you worry about FP divide by zero traps, you should worry equally about integer divide by zero traps - FP is not special in that regard.> It makes life more complex - FP exceptions because of data variations > are no rarity, these will have to be excepted from your IRQ handler. > Not the greatest idea. > Then the IRQ handler writer will have to be aware of all the subtleties > about saving/restoring the FPU context, mainly the FPSCR and other > registers with all interdependencies etc. which may well vary between > implementations on the same architecture; whereas a plain integer unit > IRQ handler will take a lot less knowledge to write.If this is something that your compiler and/or library and/or IDE project "wizard" does not handle for you, then I agree it is an extra complication.> > That being said using the FPU in an ISR is certainly possible, however > I would like to see some real examples when this might do you > any good.Ah, that's a different matter! I don't have any code convenient that uses floating point at all, never mind inside an interrupt. (The last project I had with floating point used software floating point, and it is not in an ISR.) Floating point just doesn't turn up often in the kind of systems I work with.> > Have you _actually_ written an IRQ handler which does use FP opcodes? > (Other than the obvious case of a task switch of course). >Personally, no. But I have a good customer who has a motor control system on an MPC561 that uses hardware floating point both in the main loop and in an interrupt that runs every 600 us (IIRC). We did not write the software itself, but I made the HAL, startup code and some library functions. So I handled the details of preserving the FPSCR and FP registers (it was a good few years ago, so I don't remember details of the process). I don't disagree that it is rare to want to do FP in an ISR. I just disagree that it is something to actively avoid beyond the usual aim of keeping your ISRs short and simple, or that it indicates "something seriously wrong in the program architecture".
Reply by ●March 2, 20162016-03-02
On Mon, 29 Feb 2016 08:47:27 +0100, David Brown wrote:> And why would you think that floating point is slow or otherwise > unsuitable for an ISR? Software floating point on an 8-bit AVR is slow, > but on an x86 the basic FP operations are no slower than basic integer > operations.It's not the individual instructions, it's the cost of saving and restoring the entire FPU state (bearing in mind that each 80-bit x87 register is 2.5x the size of a 32-bit integer register). For this reason, x86 has a flag which is set whenever the FPU state changes, so that the state doesn't have to be saved/restored if that would constitute a no-op. Actually using the FPU in an ISR would require the state to restored upon exit, which may be significant compared to the rest of the ISR. I don't know whether it's still the case, but it used to be a matter of policy that the Linux kernel doesn't use floating point at all (not just for ISRs).
