IL Instructions

Chapter 10

IL Instructions

When a method is executed, three categories of local memory plus one category of external memory are involved. All of these categories represent typed data slots, not simply an address interval as is the case in the unmanaged world. The external memory manipulated from the method is the community of the fields the method accesses. The internal memory categories include an argument table, a local variable table, and an evaluation stack. The diagram shown in Figure 10-1 describes data transitions between these categories. As you can see, all IL instructions resulting in data transfer have the evaluation stack as a source or a destination, or both.

Figure 10-1 Method memory categories.

The number of slots in the argument table is inferred from the method signature at the call site (not from the method signature specified when the method is defined—remember vararg methods). The number of slots in the local variable table is inferred from the local variable signature whose token is specified in the method header. The number of slots in the evaluation stack is defined by the MaxStack value of the method header, specified in IL assembly language (ILAsm) by the .maxstack directive.

The slots of the argument and local variable tables have static types, which can be any of the types defined in the system. The slots of the evaluation stack have dynamic types, which change as the computations progress and the same stack slots are used for different values. The execution engine of the common language runtime implements a coarser type system for the evaluation stack: the only types a stack slot can have at a given moment are int32, native int, int64, Float (the current implementation uses 80-bit floating-point representation, which covers both float32 and float64 types), & (a managed pointer), or ObjectRef (an object reference, an instance pointer to an object).

The IL instruction sequences that make up the IL code of a method can be valid or verifiable, or both, or neither. The concept of validity is easy to grasp: invalid instruction sequences are rejected by the JIT (just-in-time) compiler, so nothing really bad can happen if you emit an invalid sequence—except that your code won’t run.

Verifiability of the code is a security issue, not a compilation issue. Because verifiable code is not capable of any malice or hidden hacks, you can download a verifiable component from a remote location and run it without fear. If the code is deemed unverifiable—that is, if the code contains segments that just might contain a hack—the runtime security system will not allow it to be run except from a local disk. (I’ll discuss the verifiability of IL code at the end of this chapter.) Generally, it’s a good idea to check your executables with the PEVerify utility, distributed with the Microsoft .NET Framework SDK. This utility provides metadata validation and IL code verification, which includes checking both aspects—code validity and verifiability.

IL instructions consist of an operation code (opcode), which for some instructions is followed by an instruction parameter. Opcodes are either 1 byte or 2 bytes long; in the latter case, the first byte of the opcode is always 0xFE. In later sections of this chapter, opcodes are specified in parentheses following the instruction specification. Some instructions have synonyms, which I’ve also listed in parentheses immediately after the principal instruction name.