What can you do in MSIL that you cannot do in C# or VB.NET?

9 Answers

Most .Net languages including C# and VB do not use the tail recursion feature of MSIL code.

Tail recursion is an optimization that is common in functional languages. It occurs when a method A ends by returning the value of method B such that method A's stack can be deallocated once the call to method B is made.

MSIL code supports tail recursion explicitly, and for some algorithms this could be a important optimization to make. But since C# and VB do not generate the instructions to do this, it must be done manually (or using F# or some other language).

Here is an example of how tail-recursion may be implemented manually in C#:

private static int RecursiveMethod(int myParameter)
    // Body of recursive method
    if (BaseCase(details))
        return result;
    // ...

    return RecursiveMethod(modifiedParameter);

// Is transformed into:

private static int RecursiveMethod(int myParameter)
    while (true)
        // Body of recursive method
        if (BaseCase(details))
            return result;
        // ...

        myParameter = modifiedParameter;

It is common practice to remove recursion by moving the local data from the hardware stack onto a heap-allocated stack data structure. In the tail-call recursion elimination as shown above, the stack is eliminated completely, which is a pretty good optimization. Also, the return value does not have to walk up a long call-chain, but it is returned directly.

But, anyway, the CIL provides this feature as part of the language, but with C# or VB it has to be implemented manually. (The jitter is also free to make this optimization on its own, but that is a whole other issue.)


All code written in .NET languages compiles to MSIL, but are there specific tasks / operations that you can do only using MSIL directly?

Let us also have things done easier in MSIL than C#, VB.NET, F#, j# or any other .NET language.

So far we have this:

  1. Tail recursion
  2. Generic Co/Contravariance
  3. Overloads which differ only in return types
  4. Override access modifiers
  5. Have a class which cannot inherit from System.Object
  6. Filtered exceptions (can be done in vb.net)
  7. Calling a virtual method of the current static class type.
  8. Get a handle on the boxed version of a value type.
  9. Do a try/fault.
  10. Usage of forbidden names.
  11. Define your own parameterless constructors for value types.
  12. Define events with a raise element.
  13. Some conversions allowed by the CLR but not by C#.
  14. Make a non main() method as the .entrypoint.
  15. work with the native int and native unsigned int types directly.
  16. Play with transient pointers
  17. emitbyte directive in MethodBodyItem
  18. Throw and catch non System.Exception types
  19. Inherit Enums (Unverified)
  20. You can treat an array of bytes as a (4x smaller) array of ints.
  21. You can have a field/method/property/event all have the same name(Unverified).
  22. You can branch back into a try block from its own catch block.
  23. You have access to the famandassem access specifier (protected internal is famorassem)
  24. Direct access to the <Module> class for defining global functions, or a module initializer.

20) You can treat an array of bytes as a (4x smaller) array of ints.

I used this recently to do a fast XOR implementation, since the CLR xor function operates on ints and I needed to do XOR on a byte stream.

The resulting code measured to be ~10x faster than the equivalent done in C# (doing XOR on each byte).


I don't have enough street credz to edit the question and add this to the list as #20, if someone else could that would be swell ;-)

In MSIL, you can have a class which cannot inherit from System.Object.

Sample code: compile it with ilasm.exe UPDATE: You must use "/NOAUTOINHERIT" to prevent assembler from auto inheriting.

// Metadata version: v2.0.50215
.assembly extern mscorlib
  .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )                         // .z\V.4..
  .ver 2:0:0:0
.assembly sample
  .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilationRelaxationsAttribute::.ctor(int32) = ( 01 00 08 00 00 00 00 00 ) 
  .hash algorithm 0x00008004
  .ver 0:0:0:0
.module sample.exe
// MVID: {A224F460-A049-4A03-9E71-80A36DBBBCD3}
.imagebase 0x00400000
.file alignment 0x00000200
.stackreserve 0x00100000
.subsystem 0x0003       // WINDOWS_CUI
.corflags 0x00000001    //  ILONLY
// Image base: 0x02F20000

// =============== CLASS MEMBERS DECLARATION ===================

.class public auto ansi beforefieldinit Hello
  .method public hidebysig static void  Main(string[] args) cil managed
    // Code size       13 (0xd)
    .maxstack  8
    IL_0000:  nop
    IL_0001:  ldstr      "Hello World!"
    IL_0006:  call       void [mscorlib]System.Console::WriteLine(string)
    IL_000b:  nop
    IL_000c:  ret
  } // end of method Hello::Main
} // end of class Hello

Native types
You can work with the native int and native unsigned int types directly (in c# you can only work on an IntPtr which is not the same.

Transient Pointers
You can play with transient pointers, which are pointers to managed types but guaranteed not to move in memory since they are not in the managed heap. Not entirely sure how you could usefully use this without messing with unmanaged code but it's not exposed to the other languages directly only through things like stackalloc.

you can mess about with the class if you so desire (you can do this by reflection without needing IL)

.emitbyte The .emitbyte directive MethodBodyItem ::= … | .emitbyte Int32 This directive causes an unsigned 8-bit value to be emitted directly into the CIL stream of the method, at the point at which the directive appears. [Note: The .emitbyte directive is used for generating tests. It is not required in generating regular programs. end note]

You have a bit more flexibility on this, you can apply it to methods not called Main for example.

have a read of the spec I'm sure you'll find a few more.

IL has the distinction between call and callvirt for virtual method calls. By using the former you can force calling a virtual method of the current static class type instead of the virtual function in the dynamic class type.

C# has no way of doing this:

abstract class Foo {
    public void F() {
        Console.WriteLine(ToString()); // Always a virtual call!

    public override string ToString() { System.Diagnostics.Debug.Assert(false); }

sealed class Bar : Foo {
    public override string ToString() { return "I'm called!"; }

VB, like IL, can issue nonvirtual calls by using the MyClass.Method() syntax. In the above, this would be MyClass.ToString().

Enum inheritance is not really possible:

You can inherit from an Enum class. But the result doesn't behave like an Enum in particular. It behaves not even like a value type, but like an ordinary class. The srange thing is: IsEnum:True, IsValueType:True, IsClass:False

But thats not particulary useful (unless you want to confuse a person or the runtime itself.)

You can also define module-level (aka global) methods in IL, and C#, in contrast, only allows you to define methods as long as they are attached to at least one type.

I think the one I kept wishing for (with entirely the wrong reasons) was inheritance in Enums. It doesn't seem like a hard thing to do in SMIL (since Enums are just classes) but it's not something the C# syntax wants you to do.



c# c#   .net .net   clr   cil