News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

FPU display question.

Started by KeepingRealBusy, December 19, 2012, 07:02:36 AM

Previous topic - Next topic

dedndave

this will enable all 6 exception types
        push    eax
        fstcw word ptr [esp]
        fwait
        pop     eax
        and     al,0C0h
        push    eax
        fldcw word ptr [esp]
        fwait
        pop     eax

Adamanteus

That's undocumented not stable state of FPU after some long cycles calculations, solving by initialisation of it before block of critical code. I'm using such two functions for no exceptions/exceptioins types  :eusa_boohoo:
Code (asm) Select

OPTION PROLOGUE : NONE
OPTION EPILOGUE : NONE

feinit PROC

; сбрасываем слово состояния сопроцессора

FINIT ; сборс слова состояния сопроцессора
FSTSW AX ; сохраняем слово состояния сопроцессора
FWAIT ; ожидаем завершение операции сопроцессора
TEST AX, 0FFFFh ; проверяем сброс сопроцессора
MOV EAX, 0 ; ложное значение возврата
JNZ Exit1 ; сброс не выполнен - сопроцессора нет

; отключаем прерывания, устанавливаем точность и округление к нулю

ifdef NO_LD
PUSH WORD PTR 027Fh
else
PUSH WORD PTR 037Fh
endif
FLDCW [ESP]
POP AX ; истинное значение возврата
Exit1 :
RET
feinit ENDP

feninit PROC

; сбрасываем слово состояния сопроцессора

FNINIT ; сборс слова состояния сопроцессора
FNSTSW AX ; сохраняем слово состояния сопроцессора
FWAIT ; ожидаем завершение операции сопроцессора
TEST AX, 0FFFFh ; проверяем сброс сопроцессора
MOV EAX, 0 ; ложное значение возврата
JNZ Exit2 ; сброс не выполнен - сопроцессора нет

; включаем прерывания, устанавливаем точность и округление к нулю

ifdef NO_LD
PUSH WORD PTR 02A0h
else
PUSH WORD PTR 0380h
endif
FLDCW [ESP]
POP AX ; истинное значение возврата
Exit2 :
RET
feninit ENDP

OPTION PROLOGUE : PrologueDef
OPTION EPILOGUE : EpilogueD

raymond

Quoteif there aren't too many, stick FWAITS in there and take them out until the problem pops up again

I would do it a bit differently if you know which parameters always generate that NAN (and the time it takes to arrive at those parameters is relatively short).

a) Put a break point after the last FPU instruction. I would also change that instruction to exit the program;  the first run will be to make sure that the NAN gets produced.

b) Leave that first break point and insert a second break point behind the preceeding FPU instruction, and restart the program; check after that breakpoint if the NAN got produced.

c) Remove that second breakpoint and continue to move it behind the preceeding FPU instruction until the NAN stops being produced. The next FPU instruction would then be the main culprit. Check the content of all the FPU/CPU registers along with the expected effect of the next FPU/CPU instructions on such content. You may also check if the NAN still got produced at the end of the computation; it could be an important clue.

Have fun.

Edit:
If you have several possible branches in your algo, you may also need to check those other branches if the program doesn't stop at the "second" break point.
Whenever you assume something, you risk being wrong half the time.
http://www.ray.masmcode.com

KeepingRealBusy

Solved!

I enabled all exceptions and immediately ran into a precision exception doing an FDIV. This should be expected, so I re-enabled the PM mask and tried again. I Immediately got a fault and determined that the loaded value in ST(0) was way wrong. I had recently converted my code from using real8 values to using tbytes, but failed to convert the array access for the change in size of the variables. I am using tbytes in an oword array to keep alignment, and just increment the array pointer by 16 for each entry.

Now it all seems to work again.

I will have to re-test all that I did before to insure that I have not introduced another error, but feel confident that all will work.

Dave.

dedndave


raymond

 :t :t

But, don't feel bad. We've all done something similar (or worse) in the past and will probably do it again sometime in the future. :icon_redface:
Whenever you assume something, you risk being wrong half the time.
http://www.ray.masmcode.com