BOUND instruction (General-purpose)

BOUND checks an array index against two bounds: the index is a signed number in a register, the bounds a pair of signed numbers of the same size in memory, the lower first. When the index lies below the lower bound or above the upper one, BOUND raises #BR, vector 5; within them, both ends included, nothing changes, no flag either. The forms are 16 and 32 bits, m16&16 and m32&32; the second operand must be memory, and a register there raises #UD.

#BR is a fault: the saved return address is that of BOUND itself, so a handler that returns without changing the index or the bounds runs the same check again. Keeping the bounds just before the array lets one register address both, the arrangement both manuals suggest.

One wording in Intel’s manual

Intel’s description says the index must be at most the upper bound plus the operand size in bytes, but its pseudocode raises #BR for any index above the upper bound itself, as AMD’s Volume 3 does. The Operation section follows the pseudocode.

Not in 64-bit mode

In 64-bit mode 62 starts an EVEX prefix, and BOUND does not exist, so the fixture has no case for it: the probe runs there and lists both forms as not run. EVEX fits 32-bit code the way VEX does beside LDS: its second byte always has the top two bits set, a ModRM byte with a register operand, which was never a valid BOUND. Compiled bounds checks use a compare and a branch instead: in our builds with -m32, if (i < 0 || i > n) __builtin_trap(); becomes a TEST and a JS, a CMP and a JG and a UD2 in GCC 14 at -O2. MPX’s BNDCL and BNDCU, which checked a pointer against bounds in registers, are gone too. AMD’s Zen 5 guide lists BOUND as microcoded, without a latency.

Forms

Every encoding of BOUND that Intel XED knows, one row per XED instruction form (iform). How to read the notation.

Instruction	Encoding	Requires
`BOUND r16, m16&16` not in 64-bit mode BOUND_GPR16_MEMa16	`66 62 /r`	Base instruction set
`BOUND r32, m32&32` not in 64-bit mode BOUND_GPR32_MEMa32	`62 /r`	Base instruction set

Operation

What the forms do, in pseudocode that our tests run against results recorded on real processors. How to read.

v = bounds.read()                # two signed numbers of OSIZE bits:
lo = low(v, OSIZE)               # the lower bound, then the upper
hi = v >> OSIZE
if lo >> (OSIZE - 1):
    lo -= 1 << OSIZE             # negative
if hi >> (OSIZE - 1):
    hi -= 1 << OSIZE
i = signed(index)
if i < lo or i > hi:
    fault(BR)                    # a fault: the handler returns to
                                 # BOUND itself
# within the bounds nothing changes. With a register operand (ModRM
# mod 11), 62 is no BOUND: it starts an EVEX instruction on a
# processor with AVX-512, and raises #UD on an older one

Not run on a processor: BOUND does not exist in 64-bit mode, where the probe runs; its opcode, 62, is EVEX's first byte there.

Operands

What each form reads and writes, as Intel XED records it: the operands of its syntax, in order, and the implicit ones that the syntax does not name. How to read.

Operand	Kind	Action
`BOUND r16, m16&16` not in 64-bit mode `BOUND r32, m32&32` not in 64-bit mode
`r16/32`	explicit	read
`m16&16, m32&32`	explicit	read

Flags

None: XED records no flag that the forms test or change.

CPUID and processors

Each form belongs to an XED ISA set. A form can be used when the processor reports every CPUID bit of one of its ISA set's alternatives.

CPUID requirements and processors of the XED ISA sets above. Alternatives are separated by “or”; processors follow XED’s chip model, whose AMD processors end with Zen 2, and the CPU data of this site for Zen 3 to Zen 6.

ISA set	CPUID	Processors
`I186` General-purpose	No CPUID bit: part of the base instruction set.	Every x86-64 processor in XED’s model and Zen 3 to Zen 6

More General-purpose instructions

All 109 General-purpose instructions

One wording in Intel’s manual#

Not in 64-bit mode#