Last time we explored IL (well, CIL, but most people know it as just IL) we were introduced to OpCodes and their meaning by going through a really simple method. Today, I want to look at two common statements we use in programming, conditional statements (if
and switch
) and loops (for
, foreach
, etc.). We’ll also look at something that we skipped from the last post, the difference between Debug
and Release
builds (well, building with or without compiler optimisations).
If Statements
Let’s take the following F# function:
let ifStatement a =
if a = 1 then
Console.WriteLine "one"
else
Console.WriteLine "not one"
I’m using Console.WriteLine
rather than the F# Core.Printf
module and printfn
as it makes less verbose code. Normally in F# I’d use printfn
though.
This will generate the following IL:
IL_0000: ldarg.0
IL_0001: ldc.i4.1
IL_0002: bne.un.s IL_0006
IL_0004: br.s IL_0008
IL_0006: br.s IL_0013
IL_0008: ldstr "one"
IL_000d: call void [mscorlib]System.Console::WriteLine(string)
IL_0012: ret
IL_0013: ldstr "not one"
IL_0018: call void [mscorlib]System.Console::WriteLine(string)
IL_001d: ret
There are a few OpCodes which are familiar but we’re also meeting a some new ones. The first two in our output are responsible for loading the value of the argument (a
in our code) onto the stack and then pushing the int32
value 1
onto the stack. Now we’re getting to a new OpCode and we’re also going to need to understand a bit more about the piece that is to the left of the :
(that we ignored last time), which is called the instruction prefix.
An instruction in IL can be made up of two pieces of information in the format of prefix: instruction
. Let’s take the following line:
IL_0002: bne.un.s IL_0006
Here we have a prefix of IL_0002
and the instruction for that line is bne.un.s IL_0006
which is define here. To quote the documentation for the instruction for bne.un.s
:
Transfers control to a target instruction (short form) when two unsigned integer values or unordered float values are not equal.
That’s interesting, it’s a not equal operation whereas our code was if a = 1 then
, so the IL represents the inverse of what our code represented. To understand why we need to look at the rest of the instruction, and the rest of the IL, since there’s another bit of information passed to bne.un.s
, IL_0006
, which represents the target instruction to transfer control to. Effectively what this says is “if the two values don’t match the next line to execute is IL_0006
”.
Here’s where that sits in the IL:
IL_0004: br.s IL_0008
IL_0006: br.s IL_0013
You’ll notice that IL_0006
is after IL_0004
, so we’re skipping IL_0004
, essentially using a goto
statement!
Just an aside, F# doesn’t have a goto
statement, C# does!
Both IL_0004
and IL_0006
use br.s
which again transfers control to another instruction:
IL_0008: ldstr "one"
IL_000d: call void [mscorlib]System.Console::WriteLine(string)
IL_0012: ret
IL_0013: ldstr "not one"
IL_0018: call void [mscorlib]System.Console::WriteLine(string)
IL_001d: ret
Both of these blocks are pretty similar, IL_0008
is the start of the truthy branch of our if
statement, loading a string onto the stack then calling Console.WriteLine
before issuing a ret
to end the method. IL_0013
is the falsey branch and using the control transfer we skip over the truthy block.
So if we break it down, an if
statement is a series of GOTO calls to jump over blocks we don’t want to execute.
If Statements in C#
Out of curiosity, I decided to create the same example in C#:
public void IfStatements(int a)
{
if (a == 1)
{
Console.WriteLine("One");
}
else
{
Console.WriteLine("Not One");
}
}
And what I found is that it generates different IL!
IL_0000: nop
IL_0001: ldarg.1
IL_0002: ldc.i4.1
IL_0003: ceq
IL_0005: stloc.0
IL_0006: ldloc.0
IL_0007: brfalse.s IL_0018
IL_0009: nop
IL_000a: ldstr "One"
IL_000f: call void [mscorlib]System.Console::WriteLine(string)
IL_0014: nop
IL_0015: nop
IL_0016: br.s IL_0025
IL_0018: nop
IL_0019: ldstr "Not One"
IL_001e: call void [mscorlib]System.Console::WriteLine(string)
IL_0023: nop
IL_0024: nop
IL_0025: ret
What’s interesting here is that in the C# version it uses ceq
and combines it with brfalse.s
. ceq
does an equality test on two values and if they are equal it pushes 1
onto the stack, otherwise 0
, and then brfalse.s
transfers control to an instruction, IL_0018
in our case, if the value on the stack is false, null
or 0.
You’ll also notice the use of br.s
when the truthy block finishes skipping over the falsey block and land on ret
, whereas F# just inlined the ret
.
This makes the C# version a little more verbose than the F# version when achieving the same thing.
Debug vs Release
Both of the above examples are compiled using “Debug mode”, so there are no compiler optimisations enabled. But that’s not what you’re going to deploy to production (right? RIGHT!) so again I was interested to see the differences there. Here’s the F# one compiled with optimisations:
IL_0000: ldarg.0
IL_0001: ldc.i4.1
IL_0002: bne.un.s IL_000f
IL_0004: ldstr "one"
IL_0009: call void [mscorlib]System.Console::WriteLine(string)
IL_000e: ret
IL_000f: ldstr "not one"
IL_0014: call void [mscorlib]System.Console::WriteLine(string)
IL_0019: ret
And here’s C#:
IL_0000: ldarg.1
IL_0001: ldc.i4.1
IL_0002: bne.un.s IL_000f
IL_0004: ldstr "One"
IL_0009: call void [mscorlib]System.Console::WriteLine(string)
IL_000e: ret
IL_000f: ldstr "Not One"
IL_0014: call void [mscorlib]System.Console::WriteLine(string)
IL_0019: ret
Well, they look very similar don’t they, in fact, they are identical (I had to check a few times that yes, I was copying different ones!). They both resemble the unoptimised F# output, but with the minor difference of a few less br.s
instructions around the place.
For Loops
When it comes to loops I tend to use the for
loop most commonly, so we’ll use that for our exploration today. Starting with a simple F# function:
let forLoop() =
for i in 0 .. 99 do
Console.WriteLine i
Which results in the following IL:
IL_0000: ldc.i4.0
IL_0001: stloc.0
IL_0002: br.s IL_000e
// loop start (head: IL_000e)
IL_0004: ldloc.0
IL_0005: call void [mscorlib]System.Console::WriteLine(int32)
IL_000a: ldloc.0
IL_000b: ldc.i4.1
IL_000c: add
IL_000d: stloc.0
IL_000e: ldloc.0
IL_000f: ldc.i4.1
IL_0010: ldc.i4.s 99
IL_0012: add
IL_0013: blt.s IL_0004
// end loop
IL_0015: ret
I’ve left some indentations and comments that IL Spy generated for me to help visualise the IL a bit better.
We start by pushing the initial value of i
onto the stack with ldc.i4.0
and then ensure the stack is at the right location with stloc.0
before using br.s
to move down to IL_000e
. This is the start of our equality test to ensure that we’re still in the loop range:
IL_000e: ldloc.0
IL_000f: ldc.i4.1
IL_0010: ldc.i4.s 99
IL_0012: add
IL_0013: blt.s IL_0004
Location 0 is loaded on the stack (which is our i
value) then the values of 1
and 99
are pushed onto the stack with ldc.i4.1
and ldc.i4.s
respectively (ldc.i4.1
is shorthand for ldc.i4.s 1
, and likely optimised by your runtime) before add
is called which pushes the value of 100
onto the stack. Finally blt.s
is called and if the value in stack position 0
is less than the result of add
we’ll transfer control higher up in the instruction list, specifically to IL_0004
. Now we’ve ended up with this block:
IL_0004: ldloc.0
IL_0005: call void [mscorlib]System.Console::WriteLine(int32)
IL_000a: ldloc.0
IL_000b: ldc.i4.1
IL_000c: add
IL_000d: stloc.0
We grab the value from stack position 0
, hand it to Console.WriteLine
, get it again, add 1
to it and fall through to IL_000e
since there’s no control transfer.
I find this order quite interesting, the output IL is in reverse order to what I expected it to be, the conditional test is at the end of the instruction list, but upon dissection it makes a lot of sense. If the conditional test was at the top you’d always have to use a br.s
to transfer control back up to the top when the loop body finishes and then have a control transfer test (a brtrue.s
) if the range was exceeded. This would be inefficient as you’d always execute a control transfer and then have a second potental control transfer, whereas having it in reverse you only have 1 control transfer and it’s conditional.
For Loops in C#
Again we’ll look at a C# implementation:
public void ForLoop()
{
for (var i = 0; i < 100; i++)
{
Console.WriteLine(i);
}
}
Resulting in the following IL:
IL_0000: nop
IL_0001: ldc.i4.0
IL_0002: stloc.0
IL_0003: br.s IL_0012
// loop start (head: IL_0012)
IL_0005: nop
IL_0006: ldloc.0
IL_0007: call void [mscorlib]System.Console::WriteLine(int32)
IL_000c: nop
IL_000d: nop
IL_000e: ldloc.0
IL_000f: ldc.i4.1
IL_0010: add
IL_0011: stloc.0
IL_0012: ldloc.0
IL_0013: ldc.i4.s 100
IL_0015: clt
IL_0017: stloc.1
IL_0018: ldloc.1
IL_0019: brtrue.s IL_0005
// end loop
IL_001b: ret
It’s pretty similar to the F# version (ignoring the nop
instructions) except how the equality test is done. In our F# version, like with the if
statement, the equality test was combined with the control transfer using blt.s
whereas C# uses clt
and brtrue.s
to compare the values and then transfer control.
The other major difference is that the C# version loads 100 onto the stack for the clt
test but F# pushes 1 and 99, then adds them together, meaning it’s equality test is more akin to i < 1 + 99
rather than C#’s i < 100
.
Debug vs Release
It’s time to compare what happens when we enable compiler optimisations, starting with F#:
IL_0000: ldc.i4.0
IL_0001: stloc.0
IL_0002: br.s IL_000e
// loop start (head: IL_000e)
IL_0004: ldloc.0
IL_0005: call void [mscorlib]System.Console::WriteLine(int32)
IL_000a: ldloc.0
IL_000b: ldc.i4.1
IL_000c: add
IL_000d: stloc.0
IL_000e: ldloc.0
IL_000f: ldc.i4.s 100
IL_0011: blt.s IL_0004
// end loop
IL_0013: ret
And now C#:
IL_0000: ldc.i4.0
IL_0001: stloc.0
IL_0002: br.s IL_000e
// loop start (head: IL_000e)
IL_0004: ldloc.0
IL_0005: call void [mscorlib]System.Console::WriteLine(int32)
IL_000a: ldloc.0
IL_000b: ldc.i4.1
IL_000c: add
IL_000d: stloc.0
IL_000e: ldloc.0
IL_000f: ldc.i4.s 100
IL_0011: blt.s IL_0004
// end loop
IL_0013: ret
This time we’ve got identical IL (F# even uses 100 rather than doing an addition!), good to know, but also interesting to see just how different the output can be when you enable compiler optimisations.
Conclusion
Now we’ve seen some of the nity gritty parts of IL and that everything is just a GOTO statement at the end of the day! 🤣
Understanding how control is transfered around within our IL helps us understand how the compiler makes optimisations and why we should write code in a particular way.
I’ll leave you with the output of a switch
statement, see if you can work out the C# that it was generated from:
IL_0000: ldarg.1
IL_0001: ldc.i4.1
IL_0002: beq.s IL_000a
IL_0004: ldarg.1
IL_0005: ldc.i4.2
IL_0006: beq.s IL_0015
IL_0008: br.s IL_0021
IL_000a: ldstr "One"
IL_000f: call void [mscorlib]System.Console::WriteLine(string)
IL_0014: ret
IL_0015: ldstr "Two"
IL_001a: call void [mscorlib]System.Console::WriteLine(string)
IL_001f: br.s IL_000a
IL_0021: ldstr "Default"
IL_0026: call void [mscorlib]System.Console::WriteLine(string)
IL_002b: ret
Good luck!
Top comments (2)
You may have noticed by the Twitter, LinkedIn, and Dev.to follows, but I really like this article. Thank you for taking time to write about CLR and IL matters. It's always interesting to look at that level of code and it's also good to remind folks of the way the framework actually works.
I've been patiently waiting for a new, updated version of "CLR via C#", but this fills that void. Always interesting to read low-level .Net stuff.