News:

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

Main Menu

Negative number

Started by shankle, February 21, 2015, 04:34:36 AM

Previous topic - Next topic

shankle

     
             2-20-2015

   Math problem in a 64-bit GoAsm program
   
   Field A  dd  0 ; BSTA
   Field B  dd  0 ; GTotalAccum1
   
        mov eax,[BSTA]              (A)
        add [GTotalAccum1],eax  (B)
   
   BSTA contains 177,136,020
   GTotalAccim1 contains 1,980,760,000
   
   These 2 fields are added and the result is a negative
        number -    -2,137,071,076
        Max size for DD is 4,294,967,295
   
        The fields are presented using a messagebox.
        Is it possible that the messagebox is dropping zeros and
        the fields are bigger than shown in the messagebox?

        Your insight would be appreciated.   
          

qWord

Your conversion method is wrong.
MREAL macros - when you need floating point arithmetic while assembling!

dedndave

to be more precise....

if the intended result is an unsigned value
and you display it using a signed conversion routine,
the results can be incorrect

some time ago, i reported a problem with the ustr$ macro
if that is what you are using....

http://masm32.com/board/index.php?topic=1811.msg33372#msg33372

if you want to get going without rebuilding the masm32 library, just use
        invoke  crt__ultoa,number,ADDR buffer,10
use a buffer of 40 characters

shankle

The intended result is unsigned. This program works in Masm32.
I am unfamiliar with Floating Point.
No macros are used.
I am not converting anything to my knowledge.
Just a simple addition. The code worked fine for the 1st
half dozen additions.

dedndave

it's not floating point

it's two's compliment integer math
a 32-bit value (or any size, for that matter) may be either signed or unsigned, at the programmers discretion
in order to display the number, you must first convert it to an ASCII string
so, you are using something to convert
we can't tell what it is because you haven't shown us the code   :P

dedndave

let me expand on that a bit

if we choose to treat a 32-bit value as signed, the high bit is the "sign flag"
so, the range of values is -2147483648 to +2147483647

if we choose to treat a 32-bit value as unsigned, there is no sign flag bit
so, the range of values is 0 to 4294967295

dedndave

if you take an unsigned number greater than 2147483647,
and display it using a signed conversion routine, it will come out negative   :t

dedndave

it displays as -2137071076

in hexadecimal, it is actually 809EE21Ch (notice that bit 31 = 1)

as an unsigned number, it would be 2157896220

rrr314159

dedndave is (of course) right. But the total of the two numbers shankle gave is 2157896020. Therefore I suspect one of shankle's numbers is mistaken, off by 200. For instance BSTA perhaps should be 177,136,220? If so, everything makes sense: the (unsigned) numbers are correctly added but displayed as a signed number, with the correct value.
I am NaN ;)

shankle

#9
PROBLEM HAS BEEN SOLVED I THINK!!!!

Yes Dave and Nan. You are correct.
What puzzles me is the same figures are working in a Masm32 program without
going into the two's compliment hassle.

Changing  "DWTOA/ATODW"  to a 64-bit version in a 64-bit program worked.
I also have programs where the "DWTOA/ATODW" work using a 32-bit version
in a 64-bit program. My guess is, it has to do with how big the numbers one
has to use to make them work.

I'm no GoAsm expert yet......
Thanks guys for the help :biggrin: