Date: Sun, 5 Oct 1997 16:53:13 +1000 (EST) From: Andrew Reilly <reilly@zeta.org.au> To: bde@zeta.org.au Cc: reilly@zeta.org.au, freebsd-current@FreeBSD.ORG, rcarter@consys.com Subject: Re: xlock: caught signal 8 while running galaxy mode. Message-ID: <199710050653.QAA10186@gurney.reilly.home> In-Reply-To: <199710050556.PAA20163@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5 Oct, Bruce Evans wrote: >>after all), but all I can say is Bah, Humbug! I do numerical (DSP) work >>all the time, and I'd much rather the floating point maths was >>absolutely as fast as it possibly could be, rather than worrying about > > But you would rather not write it all in assembler? :-) Hmmm. I generally do anyway, because C is not a good fit for the DSP processors I have to use, but I can see that the days of special purpose DSP architectures is limited, as workstation processors get faster at maths and cheaper, and more DSP-ish applications must run on workstations and PCs. Certainly once it is possible to write efficient code in C, then that (or some other HLL) is the way to do it. >>the last few bits of precision. I usually work with 32-bit floats >>anyway. Consistency of floating point results is a myth, and >>dependance on every bit of precision, and rounding modes is algorithmic >>error. > > IEEE floating point is consistent, and some algorithms depend on it. I believe you. It's just that most of the floating point code I've had to write recently was not running on IEEE floating point processors. >>I recently tried to port some speech recognition code that runs fine on >>two different DSPs, a Dec Alpha, a Sparc and a SCO Pentium box to my >>FreeBSD machine. The HMM is expected to underflow all the time. In >>the brief time I had available, I could not figure out how to stop the >>FreeBSD maths from trapping at that point, and I couldn't write a trap >>handler that would ignore the error and continue, so I gave up. So > > Do you mean overflow? FreeBSD masks underflow, denormal and precision > exceptions by default. I'm pretty sure it wasn't an overflow. I am not all that familiar with the x87 instruction set, so I don't for sure what was happening. The breakage was in a comparison (>) between a float in a register variable with a float loaded from memory. This resulted in a SIGFPE sometimes. ---time lapse--- In the interests of exactitude, and since I seem to have the attention of people who really know about this sort of thing, here is a bit of detail about this specific "bug". With the default FreeBSD maths environment (from a build world on current 2.2 sources on 3rd September), and the C program compiled in GCC with -g -Wall switches (only). No compiler warnings. (gdb) run -S call.lst Starting program: xxx_ux -S call.lst Call Setup. RunUtterance(model:amt4.bin, speech:amt1.lin) Program received signal SIGFPE, Arithmetic exception. 0x4a8c in CalcU () at state.c:305 305 if (s > *pMax) *pMax = s; [ register float s; register float *pMax; ] (gdb) p s $1 = 5.46506401e-44 (gdb) p *pMax $2 = -32.9900398 (gdb) disassemble Dump of assembler code for function CalcU: [elided] 0x4a76 <CalcU+518>: addl $0x4,%ecx 0x4a79 <CalcU+521>: movl (%edi),%esi 0x4a7b <CalcU+523>: movl %esi,0xffffffe8(%ebp) 0x4a7e <CalcU+526>: movl 0xffffffe8(%ebp),%eax 0x4a81 <CalcU+529>: fsts (%eax) 0x4a83 <CalcU+531>: addl $0x4,(%edi) 0x4a86 <CalcU+534>: addl $0x4,%edi 0x4a89 <CalcU+537>: movl 0xffffffe4(%ebp),%eax 0x4a8c <CalcU+540>: fcoms (%eax) 0x4a8e <CalcU+542>: fnstsw 0x4a90 <CalcU+544>: andb $0x45,%ah 0x4a93 <CalcU+547>: jne 0x4a9c <CalcU+556> 0x4a95 <CalcU+549>: movl 0xffffffe4(%ebp),%esi 0x4a98 <CalcU+552>: fstps (%esi) 0x4a9a <CalcU+554>: jmp 0x4a9e <CalcU+558> 0x4a9c <CalcU+556>: fstp %st(0) So: I imagine fcoms is a short floating point compare. Any reason that should generate an exception in this case? On a system without denorms and with real 32-bit floats, the comparison would be 0.0>-30.99..., which is hardly going to be a problem. > Continuing from SIGFPE handlers is much harder than masking FP exceptions, > at least on i386's. Yes. I tried doing a signal(SIGFPE,SIG_IGN) at the top of main, but that just made it produce totally incorrect results. -- Andrew "The steady state of disks is full." -- Ken Thompson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710050653.QAA10186>