CODEWITHSUNDEEP
assemblyx86twos-complementsigned-integer
Hai Vaknin
Hai Vaknin

Reputation: 37

Assembly imul signed

thx for help my question is about ax value received from code below?

mov al,22h
mov cl,0fdh
imul cl

The first number is 22h so its 34 decimal its already unsigned the second number is fd in binary its goes like 11111101 so its signed that mean its like -3

so 22* -3 its 66; and -66 on signed 9a

so why there is ff at the beginning

Upvotes: 2

Views: 497

Answers (2)

kabanus
kabanus

Reputation: 25895

This is just expected behavior in twos complement. Starting from the full representation of 102 (the absolute value of the decimal result of your two operands, 34 and -3) we have in 16 bits:

0000 0000 0110 0110
1111 1111 1001 1001 #Flip bits
1111 1111 1001 1010 #Add 1
  f    f    9    a

I'm guessing you just ignored the upper byte, since you properly converted the lower one. Remember the result and output register is a set size, and you can't ignore any part of it in the arithmetic.

Upvotes: 2

Peter Cordes
Peter Cordes

Reputation: 363942

imul cl does AX = AL * CL, producing a full 16-bit signed product from 8-bit signed inputs.

Why did you expect the upper byte to be zero? That makes no sense for signed or unsigned.

0x009a as a signed 2's complement 16-bit integer represents +154.

0xff9a as a signed 2's complement 16-bit integer represents 0xff9a - 0x10000 = -102. This is the correct result for -3 * 34. The number is in the -128..127 range for 8-bit signed, so the upper 8 bits (0xff) are just the 2's complement sign extension of the lower 8 bits.

its already unsigned

No, it's signed positive. signed vs. unsigned is a question of how you interpret the bits. In a signed interpretation, a number can be positive, negative, or zero. A number with the sign bit = 0 is non-negative, though.

Upvotes: 4

Related Questions