Compact Framework OpCode Support in a Nutshell

While the stated goal of this blog is to address issues that affect the day-to-day work of most developers, from time to time I'll publish something for the propeller-heads in the audience. This is one of those times.

Introduction

The instruction set for a CLI compliant execution engine is described by ECMA's CLI Partition III (CIL Instruction Set). The Compact Framework execution engine implementation supports most, but not all, of these instructions. In general, the decision to support an opcode was based on whether it could be generated by one of the compilers supported by CF (C# and Visual Basic, at this time).

Unsupported instructions for v2

An unsupported instruction or prefix is one that will cause an InvalidProgramException if it is encountered by the execution engine. This is in contrast to an instruction or prefix that is simply ignored by the execution engine. CF 1.x had 7 unsupported instructions and 3 unsupported prefixes. CF 2.0 has 7 unsupported instructions and 2 unsupported prefixes. In addition, CF 2.0 has 1 new instruction and 3 new prefixes.

The unsupported instructions in CF 2.0 fall into four categories:

[Edited to fix table layout]

The calli, arglist, mkrefany, refanyval, and refanytype instructions are used to support features of Managed C++. calli supports the closely coupled native/managed interop done by managed C++. The other four instructions are primarily used in the MC++ varargs implementation. Since CF doesn't support MC++, these instructions were left out.

The localloc instruction is used to allocate bytes from the local memory pool. It's use is similar to that of the standard C runtime alloca() function. It wasn't implemented because, while it can be generated by the C# compiler, it isn't widely used and can be easily avoided.

The unaligned. and tail. prefixes were omitted because CF doesn't have any customer scenarios that require them.

New instructions for v2

The unbox.any instruction and the constrained. and readonly. prefixes were added to support generics. unbox.any extracts the value contained in a boxed type and is the equivalent of an unbox followed by ldobj. readonly. optimizes access to elements of a generic array by avoiding a type check when fetching an array element by guaranteeing that the element has not been modified. constrained. was introduced to allow the callvirt instruction to work in a uniform way with both value types and references types.

The no. prefix indicates that the execution engine need not check for type, range, and/or null exceptions when the next instruction is executed. CF 2.0 ignores this instruction because it is designated as optional in the ECMA specification.

Conclusion

A quick trip through any subject must naturally leave out a lot of information. If you have questions about opcode specifications, the ECMA spec is the place to start. If you want to see how the compiler translates high-level code into IL opcodes, use ILDasm.exe to disassemble your executable. You can find a tutorial here. Most of what I know about IL, I've learned from ILDasm. If you still have questions, feel free to ask.

~Dan

• Legend
• yes: instruction is supported in given version
• no: instruction is not supported in given version
• X: instruction did not exist in given version

[Edited to fix table layout]

Comments

• Anonymous
  September 27, 2006
  Dan Elliott recently posted about the IL OpCodes supported by the .NET Compact Framework.  This...
• Anonymous
  October 05, 2006
  The comment has been removed
• Anonymous
  October 05, 2006
  Dan Elliott recently posted about the IL OpCodes supported by the .NET Compact Framework . This got me
• Anonymous
  February 07, 2007
  PingBack from http://blog.deanoc.com/?p=72