background image

Vol. 2A 1-5

ABOUT THIS MANUAL

1.3.2 

Reserved Bits and Software Compatibility

In many register and memory layout descriptions, certain bits are marked as reserved. When bits are marked as 
reserved, it is essential for compatibility with future processors that software treat these bits as having a future, 
though unknown, effect. The behavior of reserved bits should be regarded as not only undefined, but unpredict-
able. Software should follow these guidelines in dealing with reserved bits:

Do not depend on the states of any reserved bits when testing the values of registers which contain such bits. 
Mask out the reserved bits before testing.

Do not depend on the states of any reserved bits when storing to memory or to a register.

Do not depend on the ability to retain information written into any reserved bits.

When loading a register, always load the reserved bits with the values indicated in the documentation, if any, 
or reload them with values previously read from the same register.

NOTE

Avoid any software dependence upon the state of reserved bits in IA-32 registers. Depending upon 
the values of reserved register bits will make software dependent upon the unspecified manner in 
which the processor handles these bits. Programs that depend upon reserved values risk incompat-
ibility with future processors.

1.3.3 Instruction 

Operands

When instructions are represented symbolically, a subset of the IA-32 assembly language is used. In this subset, 
an instruction has the following format:

label: mnemonic argument1, argument2, argument3

where:

label is an identifier which is followed by a colon.

mnemonic is a reserved name for a class of instruction opcodes which have the same function.

The operands argument1argument2, and argument3 are optional. There may be from zero to three operands, 
depending on the opcode. When present, they take the form of either literals or identifiers for data items. 
Operand identifiers are either reserved names of registers or are assumed to be assigned to data items 
declared in another part of the program (which may not be shown in the example).

When two operands are present in an arithmetic or logical instruction, the right operand is the source and the left 
operand is the destination. 
For example:

LOADREG: MOV EAX, SUBTOTAL

In this example, LOADREG is a label, MOV is the mnemonic identifier of an opcode, EAX is the destination operand, 
and SUBTOTAL is the source operand. Some assembly languages put the source and destination in reverse order.

1.3.4 

Hexadecimal and Binary Numbers

Base 16 (hexadecimal) numbers are represented by a string of hexadecimal digits followed by the character H (for 
example, F82EH). A hexadecimal digit is a character from the following set: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, 
E, and F.
Base 2 (binary) numbers are represented by a string of 1s and 0s, sometimes followed by the character B (for 
example, 1010B). The “B” designation is only used in situations where confusion as to the type of number might 
arise.