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:
raise
element.main()
method as the .entrypoint
.int
and native unsigned int
types directly.protected internal
is famorassem, but now allowed in C# 7.2 and VB 15.5)<Module>
class for defining global functions, or a module initializer.
vtfixup
(the equivalent of
extern
in C)
[2]modopt
or modreq
MSIL allows for overloads which differ only in return types because of
call void [mscorlib]System.Console::Write(string)
or
callvirt int32 ...
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.)
tail return
statement which would either yield a "tail return" instruction or refuse compilation when that would not be possible, than have a compiler try to auto-generate tail returns. If a piece of code would require use of tail return in order to run correctly, it should be impossible for that code to compile without using tail return. And if tail return isn't necessary, it would generally accomplish nothing. - supercat
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
{
.entrypoint
// 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
System.Object
and the special class <Module>
) shall extend one, and only one, other Class – so Extends
for a Class shall be non-null [ERROR]" (the word error here means: if this rule is not obeyed, an error must be raised). I think that pretty much sums it up why this cannot work. - Abel
TypeLoadException
). PEVerify returns: [MD]: Error: TypeDef that is not an Interface and not the Object class extends Nil token. - xanatos
It's possible to combine the protected
and internal
access modifiers. In C#, if you write protected internal
a member is accessible from the assembly and from derived classes. Via MSIL you can get a member which is accessible from derived classes within the assembly only. (I think that could be pretty useful!)
private protected
- Happypig375
Ooh, I didn't spot this at the time. (If you add the jon-skeet tag it's more likely, but I don't check it that often.)
It looks like you've got pretty good answers already. In addition:
object
in C#, these will sometimes work. See a
uint[]/int[] SO question
[2] for an example.I'll add to this if I think of anything else...
[1] http://msmvps.com/blogs/jon_skeet/archive/2008/12/10/value-types-and-parameterless-constructors.aspx<>a
as a name in C#... - Jon Skeet
The CLR supports generic co/contravariance already, but C# is not getting this feature until 4.0
In IL you can throw and catch any type at all, not just types derived from System.Exception
.
try
/catch
without parentheses in the catch-statement you will catch non-Exception-like exceptions too. Throwing, however, is indeed only possible when you inherit from Exception
. - Abel
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()
.
In a try/catch, you can re-enter the try block from its own catch block. So, you can do this:
.try {
// ...
MidTry:
// ...
leave.s RestOfMethod
}
catch [mscorlib]System.Exception {
leave.s MidTry // branching back into try block!
}
RestOfMethod:
// ...
AFAIK you can't do this in C# or VB
GOTO
- Basic
Catch
to its Try
. Run test code online here. - mbomb007
With IL and VB.NET you can add filters when catching exceptions, but C# v3 does not support this feature.
This VB.NET example is taken from http://blogs.msdn.com/clrteam/archive/2009/02/05/catch-rethrow-and-filters-why-you-should-care.aspx (note the When ShouldCatch(ex) = True
in the Catch clause):
Try
Foo()
Catch ex As CustomBaseException When ShouldCatch(ex)
Console.WriteLine("Caught exception!")
End Try
= True
, it's making my eyes bleed! - Konrad Rudolph
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.
<Module>
you can mess about with the class if you so desire (you can do this by reflection without needing IL)
.emitbyte
15.4.1.1 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]
.entrypoint
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 [1] I'm sure you'll find a few more.
[1] http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-335.pdf<Module>
is meant as special class for languages that accept global methods (like VB does), but indeed, C# cannot access it directly. - Abel
As far as I know, there's no way to make module initializers (static constructors for an entire module) directly in C#:
http://blogs.msdn.com/junfeng/archive/2005/11/19/494914.aspx
You can hack method override co/contra-variance, which C# doesn't allow (this is NOT the same as generic variance!). I've got more information on implementing this here [1], and parts 1 [2] and 2 [3]
[1] http://www.simple-talk.com/community/blogs/simonc/archive/2010/07/19/93562.aspxI 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.
Here's some more:
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 stackoverflow street credz to edit the question and add this to the list as #20, if someone else could that would be swell ;-)
Something obfuscators use - you can have a field/method/property/event all have the same name.
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 derive a class from System.Multicast delegate in IL, but you can't do this in C#:
// The following class definition is illegal:
public class YourCustomDelegate : MulticastDelegate { }
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.