Announcement

**Michael Mattias** · 29 Nov 2008, 08:44 AM

Official explanation from SDK:
" The result of a floating-point operation cannot be represented exactly as a decimal fraction"

What it means:
I have no clue; many many floating point operations cannot be represented as a decimal fraction.

Best guesses:
1. Doing some assembly-language math, impermissibly mixing floating point instructions with decimal-only instructions.

2. You have corrupted your memory, placing invalid bits/characters into a floating-point operand which is needed later. THere are, of course, lots of ways to corrupt your memory, many of which require very little effort....array bounds violations, wrong pointer vars, incorrectly defined UNIONs, TYPE SET out of range of target variable....

3. Main program doing #1 because it did not expect your function to do #2.

MCM

**Paul Dixon** · 29 Nov 2008, 09:15 AM

Guenther,
the FPU has a number of exception conditions and INEXACT RESULT is one of them. Others are underflow, overflow, divide by zero, denormalised operand and invalid operation.
These are usually masked in the FPU control register so they don't cause an exception.

In certain types of computation it may be necessary to know that the result produced isn't just extremely close to the real result but is actually exact. In those very few circumstances you would unmask the FPU INEXACT RESULT exception flag (also called the PRECISION exception flag) and allow this condition to be reported.

In normal circumstances you wouldn't use INEXACT RESULT exceptions because almost all "normal" calculations will cause the error.
e.g. all of these will produce an inexact result:
sine, COS, ATN, Log of almost anything
1/3 or 1/7 or 22/31 and many other divisions
SQRT(most things)
Assigning an EXT or DOUBLE result to lower precision variable.

I don't know if that'll help you narrow down the problem.

Paul.

**Guest** · 29 Nov 2008, 11:37 AM

Micheal, Paul,

thanks for your quick answer. In fact i don´t do any higher math in my
addon (except +,-,* and /), nor do i use any floating point data types
(i use: ptr, byte, word, long, dword, string and asciiz - nothing else)

In the meantime i´m pretty sure it is a question of pb8 versus pb9.
What really upsets me, is the fact that i don´t know where and why and
that there possibly are similar code snippets in other projects producing
unwanted results if recompiled with pb9. You cannot be sure ...

I don´t think there are logic bugs in my code anymore, otherwise it
wouldn´t have run for several years now without problems. It could
be some variables i return in many different functions. Maybe an implicit
byval/byref problem or something like that, which is recompiled in a
different manner with pb9 than before. Maybe i missed something in the docs.

What are your experiences porting code from pb8 to pb9, what changes were
necessary in your code in order to recompile/run with pb9, what problems
did you encounter, and how did you solve them?

My hope is, someone else stumbled over a similar thing and knows what to
look for (revising several thousand lines of code having no clue at all
is really though work ...)

Thanks to all in advance for your contribution

guenther

**John Petty** · 29 Nov 2008, 11:47 AM

Guenther
Don't know if this helps but many other languages do more extinsive error checking than PB, had an instance where I was generating an overfow in a DLL but not actually clearing the error, so the next math operation in VB would report the error. Can't comment why in 9 and not 8 but if you havn't changed you code then some floating point or quad operation is sometimes setting that error flag in PB, which is not checking for it or clearing it and it is being detected later in the other language.
John

**Guest** · 29 Nov 2008, 04:59 PM

Bingo !

John,

your post brings up the right clue, as it seems !

Armed with a disassembler and a debugger i found out this:
- the gpf location in my "host" holds an fpu opcode (fstp)
- a few lines down is one of numerous "interfaces" between
my dll and my host
- some more lines down i can read "fldcw" another fpu opcode
resetting exception conditions in the fpu (thanks Paul)
- running "version 8" fldcw is executed always, running "version 9"
fldcw doesn´t get executed under all circumstances !!!

This is not a matchpoint, because i still don´t know yet what
exactly is going wrong. But at least i now have a very good theory
to work upon. I have a raw guess where the problem could be located
and - the more - i found a method to reproduce the crash now, which
makes me quite sure i´m on the right track.

Doing a binary diff on both versions of my dll showed reasonable
differences - much more than i would have expected. From the filesize
you can see Version 9 is about 10% longer (!?!) compiling from
exactly the same sources (would be nice to know why?).

I will post the solution to my riddle here asap.

Thanks to all,

guenther

**Bob Zale** · 30 Nov 2008, 12:40 AM

This is virtually certain to be a classic case of memory corruption. Some code in your program is overwriting needed data when it should not do so. This snowballs into additional unpleasant side effects later.

Could be an array bounds error, an erroneous pointer, errant assembler code, a RETURN without a GOSUB, or something/anything else which changes memory that should not be changed. You need to find the source and cause of the memory change.

A good start is to run the code with #DEBUG DISPLAY ON. This will notify you of untrapped array bounds errors.

Best regards,

Bob Zale
PowerBASIC Inc.

**Guest** · 30 Nov 2008, 02:05 AM

Does not work here

Bob,

a very good feature, but it does not work for me here!
My addon stops initializing and aborts with #DEBUG DISPLAY ON.
I checked this and many other things before. Some routines in fact are heavy asm code, maybe this is the reason. Using built in test features like #TOOLS,
#DEBUG etc. seem to make my code not functional.

To make one thing clear, this is a problem with my code not with Power Basic!
In different circumstances these tools really have helped me a lot.
As stated above, i don´t think it is a compiler bug it is more likely
a problem with my code.

I will track it down and report

Thanks anyway

guenther

**Guest** · 30 Nov 2008, 11:23 AM

Problem solved

To begin with, this is not a compiler bug. But the problem arises, because
pb9 compiles different code than pb8 does. The problem lies in how and
what for i use this compiled code!

Things will become clearer, if i give some more explanation beforehand:

I´m using a third party app, which does a lot of useful things for me.
To make my work much more efficient, i would like to have some more
info displayed in a certain screen of this app. Retrieving this additional
info is no problem at all, but this app offers no option to present the
necessary data needed in a way i need it. So i decided to to it - among
other things - by myself.

I do this by applying a runtime patch to its TextOut routine - to be exact,
i overwrite the address of a call to TextOut with the address of my own
routine - thus beeing able now to control screen output by myself (insert
additional info, change formatting, colorize, etc.)

this is sample code of my replacment routine. It does nothing useful here
than to call TextOut by itself

Code:

SUB dopaint
'***********************************************************************************************
' paint 
'***********************************************************************************************

  pt_dopaint = CODEPTR(do_paint)                       'get a pointer to do_paint (runtime)


EXIT SUB


do_paint:                                              'replacement routine for rc textout
! int 3                                                'for testing only

  !  mov eax, [esp+4]
  !  mov pt_hdc, eax                   ;get hdc
  !  mov eax, [esp+8]
  !  mov pt_x  , eax                   ;get x
  !  mov eax, [esp+&H0C]
  !  mov pt_y  , eax                   ;get y
  !  mov eax, [esp+&H10]
  !  mov pt_txt, eax                   ;get pointer to text
  !  mov eax, [esp+&H14]
  !  mov pt_len, eax                   ;get textlength

  !  pushad

  !  push ebp
  !  mov ebp, esp
  !  sub esp, 20

'  !  mov ax, &H133F
'  !  mov [ebp-&H10], ax


CALL textout(pt_hdc, pt_x, pt_y, @pt_txt, pt_len)  


' ... other code here


'***********************************************************************************************
' return and cleanup stack
'***********************************************************************************************

  !  add esp, 20
  !  pop ebp

  !  popad

  !  ret 20                                            'five dword size parameters = 20 (decimal)


END SUB

this is pb8 output

Code:

 sub_40D0C9      proc near               ; CODE XREF: LIBMAIN+4E0p
                                         ; DATA XREF: sub_40D0C9+9o

 var_C           = dword ptr -0Ch

                 push    ebp
                 mov     ebp, esp
                 push    ebx
                 push    esi
                 push    edi
                 sub     esp, 64h
                 push    offset sub_40D0C9
                 xor     esi, esi
                 push    esi
                 push    esi
                 push    esi
                 push    esi
                 mov     eax, offset loc_40D0ED
                 mov     dword ptr $L, eax ; "l"
                 jmp     loc_40D165
 ; ---------------------------------------------------------------------------

 loc_40D0ED:                             ; DATA XREF: sub_40D0C9+14o
<begin of replacment routine>
                 int     3               ; Trap to Debugger
                 mov     eax, [esp+4]
                 mov     dword_433868, eax
                 mov     eax, [esp+8]
                 mov     dword_43386C, eax
                 mov     eax, [esp+0Ch]
                 mov     dword_433870, eax
                 mov     eax, [esp+10h]
                 mov     dword_433874, eax
                 mov     eax, [esp+14h]
                 mov     dword_433878, eax
                 pusha
                 push    ebp
                 mov     ebp, esp
                 sub     esp, 14h        ; reseve some extra stack space (not needed here) 
                 push    dword_433878    ; int
                 mov     ebx, dword_433874
                 push    ebx             ; LPCSTR
                 push    dword_433870    ; int
                 push    dword_43386C    ; int
                 push    dword_433868    ; HDC
                 call    ds:TextOutA
                 call    sub_431274
                 add     esp, 14h
                 pop     ebp
                 popa
                 retn    14h

--------------------------------------------

 sub_431274      proc near               ; CODE XREF: sub_401AD7+1Dp
                                         ; sub_401B1A+26p ...
                 fldcw   cs:word_42BBF2  ; stack frame independant !!!
                 retn
 sub_431274      endp

this is pb9 output:

Code:

 sub_40D650      proc near               ; CODE XREF: LIBMAIN+4CDp
                                         ; DATA XREF: sub_40D650+Eo

 var_10          = word ptr -10h
 var_C           = dword ptr -0Ch

                 push    ebp
                 mov     ebp, esp
                 push    ebx
                 push    esi
                 push    edi
                 push    133Fh
                 sub     esp, 70h
                 push    offset sub_40D650
                 xor     esi, esi
                 push    esi
                 push    esi
                 push    esi
                 push    esi
                 mov     eax, offset loc_40D679
                 mov     dword ptr $JpoJsJzLahfLds+14h, eax
                 jmp     loc_40D6EF
 ; ---------------------------------------------------------------------------

 loc_40D679:                             ; DATA XREF: sub_40D650+19o
<begin of replacment routine>
                 int     3               ; Trap to Debugger
                 mov     eax, [esp+4]
                 mov     dword ptr $JpoJsJzLahfLds+18h, eax
                 mov     eax, [esp+8]
                 mov     dword ptr $JpoJsJzLahfLds+1Ch, eax
                 mov     eax, [esp+0Ch]
                 mov     dword ptr $JpoJsJzLahfLds+20h, eax
                 mov     eax, [esp+10h]
                 mov     dword ptr $JpoJsJzLahfLds+24h, eax
                 mov     eax, [esp+14h]
                 mov     dword ptr $JpoJsJzLahfLds+28h, eax
                 pusha
                 push    ebp
                 mov     ebp, esp
                 sub     esp, 14h        ; reseve some extra stack space (not needed here) 
                 push    dword ptr $JpoJsJzLahfLds+28h ; int
                 mov     ebx, dword ptr $JpoJsJzLahfLds+24h
                 push    ebx             ; LPCSTR
                 push    dword ptr $JpoJsJzLahfLds+20h ; int
                 push    dword ptr $JpoJsJzLahfLds+1Ch ; int
                 push    dword ptr $JpoJsJzLahfLds+18h ; HDC
                 call    ds:TextOutA
                 fldcw   [ebp+var_10]                  ; stack frame dependant !!! 
                 add     esp, 14h
                 pop     ebp
                 popa
                 retn    14h

well, the crucial difference is:

Code:

pb8:             fldcw   cs:word_42BBF2  ; stack frame independant !!!

pb9:             push    133Fh           ; referenced later as [ebp-10]
                 .
                 .
                 .
                 fldcw   [ebp+var_10]    ; stack frame dependant !!!

Summary:

the code produced by pb8 is stack frame independant concerning fldcw. As long as
i don´t reference local variables in my pb high level code i´m save. This is very
nice, because i can write native pb code - not forced to do it all in asm.

the code produced by pb9 is (!) stack frame dependant concerning fldcw, because it
references [epb-10h], which is a local variable of the current stack frame. But as
i´m playing not by the rule here, the stack frame of my replacement routine is not
the one pb set up for me. I´m in the stack frame of my host's function. So [ebp-10h]
is not where and what it should be. Sometimes this seems to make no difference -
sometimes i run into an unexpected exception later on ...

Solution:

Be a nice guy and setup a stack frame for pb code like this:
(don´t forget to clean up afterwards)

Code:

  .
  .
  .

  !  push ebp
  !  mov ebp, esp
  !  sub esp, 20

  !  mov ax, &H133F
  !  mov [ebp-&H10], ax
  .
  .  pb code here ...
  .

  !  add esp, 20
  !  pop ebp

I don´t use such dirty tricks all the time, so i can feel very relaxed for all my
other code to be compiled with pb9.

As far as i can remember this was my first thread i got a reply by Mr. Bob Zale - Wow.
I appreciate your work very much !

Thanks to all, comments, questions and bugreports (i don´t hope so) appreciated,

guenther

**Kev Peel** · 30 Nov 2008, 02:15 PM

In one of your code snippets you are calling TextOut() without restoring the register variables. You need to preserve EBX, ESI, EDI, ESP and EBP, and restore them before using any high-level PB statements (such as calling a function or accessing a variable). I'm not 100% but I recall PB8 and less did not use EBX (or it was not mentioned in PB8 help).

Also, if you want to handle the stack yourself, do not use "CALL" statement, but ASM CALL.

See the help file topic "Saving registers" for more info.

**Guest** · 1 Dec 2008, 12:25 PM

Kev,

that´s why i did a "pushad" before (save registers on the stack) and a
"popad" (restore registers) afterwards.

Of course i could do an asm call, but the point is: i can do a pb call
(not only one - many, as much as i like) here. So i have a generic method
of writing my replacement routine in native pb. Comes in very handy, if you
have to do heavy string manipulations, math or other things, which are
not very handy to code in asm!

Pb8 didn´t even reqiure to setup an extra stack frame for this as long as
you didn´t reference locals (globals would be ok).

Pb9 now requires an extra stack frame to be setup, otherwise you are
likely to run into "issues" as described above.

I´m aware, that what i´m doing here with my addon is a bit tricky. And it´s
been my fault running into trouble. My first guess of different compiler
action turned out to be right, but i had absolutly no clue, what to look for.
Therefore i started this thread to get ideas just like in a brainstorming
session. Reading John´s post it made "click" in my head ...

Thanks

guenther

**Kev Peel** · 1 Dec 2008, 01:24 PM

Of course it's tricky. My point was you shouldn't be messing with the stack if you want your code to be compatible with future versions of PB. If you need to work with the stack when calling a function, then use ASM CALL, it's really not hard to use and you won't encounter problems like this if and when PB change the way the stack is handled. All ASM CALL needs are a few more PUSHes.

Just me 2 pence, take it as you will

**Guest** · 1 Dec 2008, 04:35 PM

Kev,

only in my first level (stack frame) i´m in danger, as long as i don´t reconstruct what pb expects in terms of stack.

My failure was to rely on the fact pb wouldn´t change its
function framework. I don´t see a "compiler update save" way do to
what i did here. This is price i have to pay. If the compiler changes
the stack framework, i will possibly have to adapt my code.

- Well i could do an asm call to a pb routine, pass all necessary parameters
and do the real work here. Meaning the first level of my replacement
routine would be pure asm - no compiler surprises, no messy stack details.

I hope i got your point now and would be glad to here form you, this is the
way to go.

off topic:
as english is not my native tongue, what does

Just me 2 pence

mean?

Thanks for your interesting reply

guenther

**Kev Peel** · 1 Dec 2008, 06:00 PM

Yes! My advice if you need to make a CALL in the middle of some ASM would be to avoid reading values from PB's stack and handle passing all the parameters yourself. This way there is less room for mistakes

A call to a function using ASM is only a handful of instructions (usually only MOV, LEA, PUSH and CALL) and the stack is yours, but remember STDCALL convention uses right-to-left parameters and the called function handles the stack cleanup.

PS. It's an American (?) expression "just my 2 cents worth" which basically means "Just my opinion". The "two pence" is my British variation

**Guest** · 3 Dec 2008, 09:37 AM

Hi all,

after some testing, here is the new approach - likely to be more resistant to compiler
changes than before. Kev,i was so focused on my approach, that i didn´t see the obvious -
and at first i didn´t realize you were in fact one step ahead. Thanks for pointing this
out, it is a generic solution now.

disassembly of our targets code: (just a sample)

Code:

.
.
.
00442E70    call textout -> loc_textout = 00442E72 (!)
.
.
.

To make things easy, i use globals (in general i don´t mind using globals)
Of ourse you have to be part of our target process by beeing an addon, plugin,
whatever or by hooking into it...

Code:

GLOBAL loc_textout as DWORD

GLOBAL rc_hdc      AS DWORD
GLOBAL rc_x        AS DWORD
GLOBAL rc_y        AS DWORD
GLOBAL rc_txt      AS ASCIIZ PTR
GLOBAL rc_len      AS DWORD


.
.
.




SUB paintinit
'***********************************************************************************************
' init framework for own textout
'***********************************************************************************************
local old_protect as long


  CALL virtualprotect(loc_textout, 16, %Page_Execute_ReadWrite, old_protect)

  !  mov eax, loc_textout
  !  lea ebx, dopaint                  'get pointer to replacemant routine for textout and
  !  mov [eax], ebx                    'stroe at loc_textout


EXIT SUB


dopaint:                               'replacement routine for textout
'! int 3

  !  mov eax, [esp+4]                  ;retrieve parameters
  !  mov pt_hdc, eax                   ;get hdc
  !  mov eax, [esp+8]
  !  mov pt_x  , eax                   ;get x
  !  mov eax, [esp+&H0C]
  !  mov pt_y  , eax                   ;get y
  !  mov eax, [esp+&H10]
  !  mov pt_txt, eax                   ;get pointer to text
  !  mov eax, [esp+&H14]
  !  mov pt_len, eax                   ;get textlength

  !  pushad

  !  lea eax, pbpaint
  !  call eax                          ;call pb routine

  !  popad
  !  ret 20                            ;cleanup stack and return [5 parameters = 20 (decimal)]


END SUB



SUB pbpaint
'***********************************************************************************************
' do all the real work here - in native pb
'***********************************************************************************************


  CALL textout(pt_hdc, pt_x, pt_y, @pt_txt, pt_len)     'draw line
  .
  .  (other pb code here)
  .
  

END SUB

You could adapt this sample for different routines with different parameters.

Thanks for your help

guenther

Announcement

%exception_flt_inexact_result

%exception_flt_inexact_result

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment