Because the CLI type system regards interoperability with native code as an important goal, CLI consumers can expose their own component frameworks or unique features of an underlying operating system without compromise. Unlike execution environments that claim to provide “write once, run anywhere” facilities, the CLI was designed to augment existing system abstractions with its type system rather than fully duplicate such facilities in a new layer. To implement this approach, it follows that CLI types must not only be consistent among themselves, but must also be capable of representing the complete set of native constructs provided by the underlying system and microprocessor, and of using these constructs within its component model.
Built-in types are perhaps the simplest form of type interoperability to understand: they are directly understood by the CLI execution engine, and have obvious value type equivalents. For example, the built-in type
System.Int32 represents a 4-byte signed integer. These types are commonly mapped directly to types that the microprocessor implements in hardware by a given CLI implementation. In the ECMA specification, these mappings and the semantics associated with them are termed the “virtual execution system.”
The actual constants used to represent built-in types within the JIT compiler are shown in Example 3-21.
Example 3-21. The map used to convert abstract CLI types into processor-specific types (defined in clr/src/vm/jitinterface.cpp) ...