Codes. Unaligned Field
Indicates that an address currently atop the evaluation stack might not be aligned to the natural size of the immediately following
public: static initonly System::Reflection::Emit::OpCode Unaligned;
public static readonly System.Reflection.Emit.OpCode Unaligned;
staticval mutable Unaligned : System.Reflection.Emit.OpCode
Public Shared ReadOnly Unaligned As OpCode
The following table lists the instruction's hexadecimal and Microsoft Intermediate Language (MSIL) assembly format, along with a brief reference summary:
|FE 12 <
||Indicates that the subsequent pointer instruction may be unaligned.|
The stack transitional behavior, in sequential order, is:
- An address is pushed onto the stack.
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
cpblk instruction. That is, for a Ldind_I4 instruction the alignment of the address may not be to a 4-byte boundary. For
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.
volatile prefixes can be combined in either order. They must immediately precede a
cpblk instruction. Only the Volatile prefix is allowed for the Ldsfld and Stsfld instructions.
The following Emit method overloads can use the