Overflow in IMUL

[bf2]

I am trying to see how OF gets set in IMUL. I have this strange situation. I am multiplying two words, number1 and number2. The result should be 64,000 and should fit within AX, DX should not contain any significant bits and no overflow should occur.

For one combination of number1 and number2 (64,000 and 1), overflow is occurring. If you comment them out and use the other combination (6,400 and 10), there is no overflow.

The code is below:

Code Select Expand


include \masm32\include\masm32rt.inc
.data
caption byte "Result",0

; Overflow
number1 word 6400
number2 word 10

; Normal
;number1 word 64000
;number2 word 1

result1 byte "Overflow", 0
result2 byte "Normal", 0
.code
start:
mov edx, 0
mov ax, number1
imul number2
jo Overflow
invoke MessageBox, NULL, addr result2, addr caption, MB_OK
jmp Continue
Overflow:
invoke MessageBox, NULL, addr result1, addr caption, MB_OK
Continue:
invoke ExitProcess, NULL
end start

When running this in Olly I noticed that DX gets a different value in each case after the IMUL. How is this possible?

Thanks in advance.

[clive]

32-bit result for a 16 x 16-bit multiply goes into DX:AX, for 32-bit code that would be a 64-bit result in EDX:EAX

Plus 64000 would be treated as a negative signed number, whereas 6400 x 10 is going to be positive. Perhaps you want to be using an unsigned multiply?

[bf2]

Thanks for that.

So when multiplying what should be a standard procedure to follow? How should we string the two registers together into a variable to display?

Is there any sample code I can look at?

Thanks.

[bf2]

32-bit result for a 16 x 16-bit multiply goes into DX:AX, for 32-bit code that would be a 64-bit result in EDX:EAX

Plus 64000 would be treated as a negative signed number, whereas 6400 x 10 is going to be positive. Perhaps you want to be using an unsigned multiply?

I am not sure I entirely understand. I thought OF gets set based on the result of IMUL, not based on the individual operands. So the same resultant value should produce the same flag, regardless of how the result is arrived at, right?

[bf2]

OK, I got it. Thanks for pointing me to the right direction.

[clive]

How should we string the two registers together into a variable to display?

You could store the answer in this fashion

mov [si+0],ax
mov [si+2],dx

For printing. Well, you'd have to check if the number was negative first, printing a '-' and then negating. That was the conversion only has to handle positive numbers.

You can divide a 32-bit number in DX:AX to get AX = quotient, DX = remainder. Converting decimals you could use 10000 or 10 depending on the scale of the numbers, or write a more complex grouping of divides to achieve a 32-bit quotient.

Then again at this point I'm not sure why using the 16-bit instructions makes much sense.

[bf2]

I was using 16-bit numbers just to try out various aspects of large number multiplication. It's much easier to handle 16-bit large numbers than 32-bit large numbers.

[dedndave]

nahhhhh
32 bit is the bee's knees   :bg

[KeepingRealBusy]

nahhhhh
32 bit is the bee's knees   :bg

Dave,

You have been watching too many Geico commercials.

Dave.

[dedndave]

hiya Dave   :bg
i think that term has been around since before i was born - lol
i am sure the geico gecko is younger than i am   :P

[clive]

You have been watching too many Geico commercials.

Personally I'm preferring the AllState commercials
http://wn.com/Allstate_TV_Ad_Jogger_Mayhem

I was using 16-bit numbers just to try out various aspects of large number multiplication. It's much easier to handle 16-bit large numbers than 32-bit large numbers.

I can see that testing the corner/boundary conditions on a 16-bit arena is a lot more manageable than 32.  But in general use the 32-bit versions are the way to go, the 386 made life so much easier.