8086 MUL vs. IMUL: Unsigned and Signed Multiplication, Results, and Flags

Maintained layer, checked 2026-09-01. This guide is deliberately limited to the original 8086’s one-operand forms. The complete 2017 post, last modified in 2023, is preserved at the end. Its Answers.com URL remains only inside that archive as provenance; the maintained explanation relies on Intel documentation.

Short Answer

On the 8086, MUL performs unsigned multiplication and IMUL performs signed two’s-complement multiplication. Both take one explicit register-or-memory source operand, use AL or AX as the implicit other input, and return the complete double-width product:

  • byte source: AL × r/m8 → AX;
  • word source: AX × r/m16 → DX:AX.

The destination layout is therefore the same, but the numeric interpretation is not. The flags also ask different fit questions: MUL tests whether the upper half is zero, whereas IMUL tests whether the upper half is merely the sign extension of the lower half.

Exact 8086 Forms

The 8086 has these four multiplication encodings. Here, r/m means that the explicit source can be a register or a memory operand.

Source width MUL IMUL Complete result
8 bits F6 /4, unsigned AL × r/m8 F6 /5, signed AL × r/m8 AX (AH high, AL low)
16 bits F7 /4, unsigned AX × r/m16 F7 /5, signed AX × r/m16 DX:AX (DX high, AX low)

In Intel/NASM-style syntax, the destination registers are implicit:

mul bl          ; unsigned AL × BL -> AX
imul bl         ; signed AL × BL -> AX
mul word [n]    ; unsigned AX × word [n] -> DX:AX
imul word [n]   ; signed AX × word [n] -> DX:AX

The one-operand instructions do not discard the upper half. Even when CF and OF report that the product does not fit in the lower half alone, the complete 16- or 32-bit result is still available in the documented register pair.

Same Bits, Different Numbers

Reset AL = 02h and the byte source to FFh before each instruction. The source bits are identical, but FFh means 255 as an unsigned byte and −1 as a signed two’s-complement byte.

Instruction Mathematical operation Full result in AX CF and OF
MUL 2 × 255 = 510 01FEh 1, because AH = 01h is nonzero
IMUL 2 × (−1) = −2 FFFEh 0, because AH = FFh is the sign extension of AL = FEh

This is why “the algorithm is the same” is not a sufficient programming rule. Register placement is parallel, but signed interpretation changes both the mathematical product and the overflow test.

What CF and OF Actually Mean

After either original 8086 multiplication form, CF and OF have the same value:

  • For byte MUL, they are 0 exactly when AH = 00h; for word MUL, exactly when DX = 0000h. Otherwise both are 1.
  • For byte IMUL, they are 0 exactly when AH is the sign extension of AL; for word IMUL, exactly when DX is the sign extension of AX. Otherwise both are 1.

Thus, cleared CF/OF means the product fits in the lower 8 or 16 bits under the instruction’s own unsigned or signed interpretation. It does not mean that the upper half of every signed product is zero.

The 8086 manual and current Intel reference both mark SF, ZF, AF, and PF as undefined after these instructions. Do not use those flags to classify the product; explicitly test the result if more conditions are needed.

Executable 8-Bit Reference Model

This small Python model reproduces the 02h × FFh arithmetic and documented CF/OF rules:

def signed8(value):
    return value - 0x100 if value & 0x80 else value


al, src = 0x02, 0xFF

mul_bits = al * src
mul_cf_of = int((mul_bits >> 8) != 0)

imul_value = signed8(al) * signed8(src)
imul_bits = imul_value & 0xFFFF
imul_low = imul_bits & 0xFF
imul_high = imul_bits >> 8
expected_high = 0xFF if imul_low & 0x80 else 0x00
imul_cf_of = int(imul_high != expected_high)

print(f"MUL  AX={mul_bits:04X}h CF=OF={mul_cf_of}")
print(f"IMUL AX={imul_bits:04X}h CF=OF={imul_cf_of}")

Expected output:

MUL  AX=01FEh CF=OF=1
IMUL AX=FFFEh CF=OF=0

This is an arithmetic reference model, not an 8086 emulator: it does not model instruction decoding, exceptions, execution timing, or the undefined flags.

Do Not Confuse Later IMUL Forms with 8086 Code

Intel’s current x86 reference documents one-, two-, and three-operand forms together because the architecture grew after the 8086. The October 1979 8086 manual’s instruction table and decoding guide list only the accumulator-based one-operand forms above.

imul bx          ; original 8086: signed AX × BX -> DX:AX

imul cx, bx      ; later two-operand form: not an original 8086 encoding
imul cx, bx, 10  ; later three-operand form: not an original 8086 encoding

A modern assembler may accept all three unless its CPU target is constrained. When writing genuine 8086 code, check the selected target and inspect the emitted opcodes; do not infer historical availability merely because a current manual calls an instruction valid in legacy mode.

Practical Checklist

  1. Decide whether the bit patterns represent unsigned values (MUL) or signed two’s-complement values (IMUL).
  2. Remember the implicit input: AL for a byte source, AX for a word source.
  3. Read the full product from AX or DX:AX, not just the lower register.
  4. Use CF/OF only with the rule for the chosen instruction; treat SF, ZF, AF, and PF as undefined.
  5. For an 8086 target, use only the one-operand forms and verify the generated encoding.

Primary Sources

—

Original 2017 Archive (Last Modified 2023, Verbatim)

The following is the complete visible body from the WordPress export. Only invisible trailing whitespace has been normalized for repository formatting. The external link and the broad “same algorithm” wording are retained as historical provenance, not endorsed as current authority.


Reference Link:
 http://www.answers.com/Q/What_is_the_basic_difference_between_MUL_and_IMUL_instruction_in_8086_microprocessor

mul is used for unsigned multiplication whereas imul is used for signed multiplication. Algorithm for both are same, which is as follows:
 when operand is a byte:
 AX = AL * operand.
 when operand is a word:
 (DX AX) = AX * operand.

Leave a Reply