LDS instruction (General-purpose)

LDS loads a far pointer from memory: the offset into a general-purpose register and the 16-bit selector after it into DS. The pointer is m16:32, six bytes, at the 32-bit operand size, and m16:16, four bytes, at the 16-bit one. In protected mode the selector is checked against its descriptor as a MOV to DS would check it, and DS’s hidden base, limit and rights come from that descriptor; a null selector, 0 to 3, loads without a fault, and the first access through DS then raises #GP. In real mode the selector is simply loaded, its base being 16 times its value. LES does the same for ES, and LFS, LGS and LSS for the other three segment registers.

C5 became VEX

LDS needs a memory operand, so C5 followed by a ModRM byte with mod = 11b was never a valid LDS. The two-byte VEX prefix uses exactly those bytes in 32-bit code: Intel’s manual says that bit 7 of the byte after C5, VEX.R stored inverted, must be 1 there, otherwise the instruction is LDS. That bit selects registers 8 to 15, which 32-bit code does not have, so it is always 1 there anyway. In 64-bit mode C5 is always VEX, and LDS does not exist; LES lost C4 to the three-byte VEX prefix the same way.

Not in 64-bit mode

The fixture has no case for LDS: the probe runs in 64-bit mode, where C5 starts a VEX instruction, and lists the form as not run. GNU as 2.44 and Clang 23 refuse lds in 64-bit code. A flat 32-bit or 64-bit program has no use for it, DS covering all of memory, and LFS, LGS and LSS keep the far-pointer load in 64-bit mode. AMD’s Zen 5 guide lists LDS as microcoded, without a latency.

Forms

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

Instruction	Encoding	Requires
`LDS r16/32, m16:16/32` not in 64-bit mode LDS_GPRz_MEMp	`C5 /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 = src.read()                   # m16:16 or m16:32
load_segment(ds, v >> OSIZE)     # checks the descriptor it names
dest.write(v)                    # the offset: the low OSIZE bits

Not run on a processor: LDS does not exist in 64-bit mode, where the probe runs: C5 starts a VEX prefix 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
`LDS r16/32, m16:16/32` not in 64-bit mode
`r16/32`	explicit	write
`m16:16/32`	explicit	read
`DS`	implicit	write

Flags

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

Attributes

What else XED records about the forms. How to read.

All forms: may abort a TSX transaction

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
`I86` General-purpose System	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

C5 became VEX#

Not in 64-bit mode#