The following table lists the instruction's hexadecimal and Microsoft Intermediate Language (MSIL) assembly format, along with a brief reference summary:

FE 12 < unsigned int8 >	unaligned. alignment	Indicates that the subsequent pointer instruction may be unaligned.

The stack transitional behavior, in sequential order, is:

[The 'ordered' type of list has not been implemented in the ECMA stylesheet.]

Unaligned specifies that the address (an unmanaged pointer, native int) on the stack might not be aligned to the natural size of the immediately following ldind, stind, ldfld, stfld, ldobj, stobj, initblk, or cpblk instruction. That is, for a OpCodes.Ldind_I4 instruction the alignment of the address may not be to a 4-byte boundary. For initblk and cpblk the default alignment is architecture dependent (4-byte on 32-bit CPUs, 8-byte on 64-bit CPUs). Code generators that do not restrict their output to a 32-bit word size must use unaligned if the alignment is not known at compile time to be 8-byte.

The value of alignment must be 1, 2, or 4 and means that the generated code should assume that the address is byte, double-byte, or quad-byte aligned, respectively. Note that transient pointers (type *) are always aligned.

While the alignment for a cpblk instruction would logically require two numbers (one for the source and one for the destination), there is no noticeable impact on performance if only the lower number is specified.

The unaligned and volatile prefixes can be combined in either order. They must immediately precede a ldind, stind, ldfld, stfld, ldobj, stobj, initblk, or cpblk instruction. Only the OpCodes.Volatile prefix is allowed for the OpCodes.Ldsfld and OpCodes.Stsfld instructions.

The following ILGenerator.Emit(OpCode) method overloads can use the unaligned opcode:

• ILGenerator.Emit(OpCode, Label)

• ILGenerator.Emit(Opcode, Byte)

Namespace: System.Reflection.Emit
Assembly: mscorlib (in mscorlib.dll)
Assembly Versions: 1.0.5000.0, 2.0.0.0, 4.0.0.0