Most 8086 instructions come in a byte version and a word version, and the assembler must know which one to emit. Usually a register settles it: in MOV AL, [BX] the AL says byte. When no operand has a size, as in INC [BX] or MOV [SI], 0, MASM cannot choose and reports an error. type PTR supplies the size: INC BYTE PTR [BX] changes one byte, INC WORD PTR [BX] changes a word.

Prints 01.
MOV     BX, OFFSET CNT1  ; CNT1 = 00FFh
INC     BYTE PTR [BX]    ; low byte only: FFh -> 00h, no carry into the next
MOV     AL, [BX+1]       ; the high byte is still 0
ADD     AL, '0'          ; digit -> character
MOV     DL, AL
MOV     AH, 02h          ; DOS: print DL
INT     21h
MOV     WORD PTR [BX], 00FFh
INC     WORD PTR [BX]    ; the whole word: 00FFh -> 0100h
MOV     AL, [BX+1]       ; the high byte is now 1
ADD     AL, '0'          ; digit -> character
MOV     DL, AL
MOV     AH, 02h          ; DOS: print DL
INT     21h
 
CNT1    DW      00FFh

Overriding a declared type

A label defined with DB, DW or DD has a type, and MASM checks it against the other operand. MOV AL, W1 fails if W1 is a word; MOV AL, BYTE PTR W1 reads its first byte on purpose. In the same way WORD PTR [D1] and WORD PTR [D1+2] pick the two halves of a double word.

DWORD PTR

Four-byte operands appear with far pointers: LES DI, DWORD PTR [P1], and indirect far jumps and calls such as CALL DWORD PTR [VEC1]. For direct jumps MASM uses the related NEAR PTR and FAR PTR.

Pitfalls

PTR converts nothing. It only tells the assembler how many bytes the instruction should touch; WORD PTR on a byte variable simply reads that byte and the one after it. Choosing the wrong size is a quiet bug: MOV WORD PTR [FLAG1], 0 on a byte flag also clears the next variable.

Later CPUs

With the 80386, DWORD PTR also marks 32-bit data operands, as in INC DWORD PTR [BX]. The 8087 adds QWORD PTR and TBYTE PTR.