I'm using and AMD Athlon 1GHz I'm having a very seroius problem with the FPU. I can load on six values and they'll remain intact, I can then pop them off and they're still intact. After loading on these values I can also load on two zeros (therefore fill up the FPU) these can be poped off and the rest of the values remain intact, as they should. If however the 7th value loaded on is non-zero it i.e st(0), becomes scrambled the same result as if a division by zero was proformed. Even odder st(6) becomes scrambled. This happens if there is no 8th value or if the eight value was zero. Now if the 8th value non-zero then st(0), st(6) and st(7) suffer from this scrambling. Even more odd is the fact that if the eight value is non-zero then the 7th value remains intact so the scrambling seems like its cause by the popping of values off the stack. If 6 values are loaded on, you can load on the 7th value, proform a calculation, say fmul st(3), st. This caluation works. However when popping the values off the stack into variables again st and st(6) are scrambled. If however st(0) was removed by a fstp st or fcomp then st(6) which would have changed to st(5) remains intact. These tests seem to be saying that problems only occur when storeing values from the FPU when it contains more than 6 non zero values, or maybe just when st(6) or st(7) are non zero, more tests are needed. This has me completely confused and I really needed to be able to work with more values on the FPU, please say this isn't a problem with my processor, could this explain random crashs. Theres only one good thing I can sya about these problems, they're consistent, they always occur if you repeat yourself. Hopefully I'm doing something absolutly stupid, this is something I'll have to leave to the experts. Thanks.
Just a guess: some other app or the OS (an event handler?) is using the FPU but not saving it accurately. Ouch. This message was edited by Larry Hammick, on 6/19/2001 2:42:15 AM
Larry I don't know if thats the problem, after all then it wouldn't always occure when six valies were loaded on, this is a very specific problem that seems to always occur. And its really messing up my programming.
I thought, if some fields in the fpu stack are stable but others are not, maybe some other process saves them all to memory, accidentally changes just one or two, and then restores them. Probably the chip is okay; these chips have some sort of power-on-self-test routines, at least. Could there be some (defective) fpu emulator running? MMX code also uses the fpu stack. Are there any dubious MMX apps around? Sorry if I sound dumb; I'm guessing, but I can see how serious this problem would be. If you post or email some source which reproduces the problem, I'll try it here and also with masm 5.1. This message was edited by Larry Hammick, on 6/19/2001 11:18:58 PM
Hi Zadkiel, I offer no solution to your question, only confirmation. I was working on a simple calculator program last year. After seven or so divisions or mult result was always NAN. I didn't try too hard to find solution and just assumed it was poor coding on my part and abondoned project. I still don't know what was going on but very similar to what you write but not defective chip. best regards, czDrillard
Why don't you post your code ?, we will try to reproduce the problem.
Yes, I no longer feel its a defective cpu, I just managed to run a test on an Intel PII 400, completely different from my AMD Athlon and it acted the same. I knocked up a program to test it, get it here. Simply enter the no of values you wish to load onto the fpu in the last edit box (1 - 8) and click test from the menu. It should fill up the number of edit boxes you selected with PI. The rest contain what I think represents NAN. On my PC number 1 to 6 work but for 7 or eight the first box and the last two are always NAN. Anyway codes included so mess around with it yourselves. Sorry however for the code, this program was bodged together for at least two others so it a mess. Thanks for all the help so far.
The problem doesn't come from your program or the CPU. It happens when there is a stack overflow. Everything you push becomes NAN. The same thing happens when you use fsqrt and st is negative. The top of the stack becomes NAN. As Larry suggested, there must be an exception handler that traps the exception and replaces the top of the stack with an invalid value. Correction : it's not an exception handler, it's normal behavior. From Intel's manual :
When the x87 FPU detects stack overflow or underflow, it sets the IE flag (bit 0) and the SF flag (bit 6) in the x87 FPU status word to 1. It then sets condition-code flag C1 (bit 9) in the x87 FPU status word to 1 if stack overflow occurred or to 0 if stack underflow occurred. If the invalid-operation exception is masked, the x87 FPU returns the floating point, integer, or packed decimal integer indefinite value to the destination operand, depending on the instruction being executed. This value overwrites the destination register or memory location specified by the instruction. If the invalid-operation exception is not masked, a software exception handler is invoked (see Section 8.7., “Handling x87 FPU Exceptions in Software”) and the top-of-stack pointer (TOP) and source operands remain unchanged.This message was edited by karim, on 6/21/2001 11:46:40 AM