Pointless IL instructions?

[Guest]

I've got a simple console app which just assigns 6 to an int and prints out
the value. The IL looks like:

..method public static void Main() cil managed
{
.entrypoint
.custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01
00 00 00 )
// Code size 12 (0xc)
.maxstack 1
.locals init ([0] int32 x)
IL_0000: nop
IL_0001: ldc.i4.6
IL_0002: stloc.0
IL_0003: ldloc.0
IL_0004: call void [mscorlib]System.Console::Write(int32)
IL_0009: nop
IL_000a: nop
IL_000b: ret
} // end of method Module1::Main

What is the point of these:
IL_0002: stloc.0
IL_0003: ldloc.0

Why store something in a variable just to put the exact thing right back on
the stack where it was? The proper value was on the stack before that anway,
right? Couldn't these two lines be taken out?

-Ben

 

[Michael Nemtsev]

Hello Ben R.,

Local valuables are created on the stack and IL creates its own variables
to init yours
stloc.0 just takes the value at the top of the stack and initializes the
first IL's variable. 0 means that it's the first variable
ldloc.0 just load IL's variable back to the stack, so that it is avaiable
to the Write method


B> I've got a simple console app which just assigns 6 to an int and
B> prints out the value. The IL looks like:
B>
B> .method public static void Main() cil managed
B> {
B> .entrypoint
B> .custom instance void [mscorlib]System.STAThreadAttribute::.ctor()
B> = ( 01
B> 00 00 00 )
B> // Code size 12 (0xc)
B> .maxstack 1
B> .locals init ([0] int32 x)
B> IL_0000: nop
B> IL_0001: ldc.i4.6
B> IL_0002: stloc.0
B> IL_0003: ldloc.0
B> IL_0004: call void [mscorlib]System.Console::Write(int32)
B> IL_0009: nop
B> IL_000a: nop
B> IL_000b: ret
B> } // end of method Module1::Main
B> What is the point of these:
B> IL_0002: stloc.0
B> IL_0003: ldloc.0
B> Why store something in a variable just to put the exact thing right
B> back on the stack where it was? The proper value was on the stack
B> before that anway, right? Couldn't these two lines be taken out?
B>
B> -Ben
B>
---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsch

 

[Guest]

What does the original code look like. We can't really make a reliable
judgement without knowing what the compiler was using as a basis for this IL
code. I'm assuming DEBUG mode which performs no optimization.

 

[Guest]

Hi Peter,

Here's the code:

Module Module1

Sub Main()
Dim x As Integer = 6

Console.Write(x)
End Sub

End Module

Thanks!
-Ben

What does the original code look like. We can't really make a reliable
judgement without knowing what the compiler was using as a basis for this IL
code. I'm assuming DEBUG mode which performs no optimization.

--
http://www.peterRitchie.com/blog/
Microsoft MVP, Visual Developer - Visual C#

I've got a simple console app which just assigns 6 to an int and prints out
the value. The IL looks like:

.method public static void Main() cil managed
{
.entrypoint
.custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01
00 00 00 )
// Code size 12 (0xc)
.maxstack 1
.locals init ([0] int32 x)
IL_0000: nop
IL_0001: ldc.i4.6
IL_0002: stloc.0
IL_0003: ldloc.0
IL_0004: call void [mscorlib]System.Console::Write(int32)
IL_0009: nop
IL_000a: nop
IL_000b: ret
} // end of method Module1::Main

What is the point of these:
IL_0002: stloc.0
IL_0003: ldloc.0

Why store something in a variable just to put the exact thing right back on
the stack where it was? The proper value was on the stack before that anway,
right? Couldn't these two lines be taken out?

-Ben

 

[Guest]

Hi Peter, I think I've solved my own question. Those steps were involved in
getting the info into the variable I declared. I guess I was wondering why it
didn't just optimize it such that the code was as though you just called
colsole.write(6) but I did ask it to put 6 in a variable and use that for the
write function. This makes sense. I wonder why there isn't a stloc op that
copies from the stack (doesn't pop after. This would avoid having to
immediately replace what you took off in this scenario.

-Ben

Hi Peter,

Here's the code:

Module Module1

Sub Main()
Dim x As Integer = 6

Console.Write(x)
End Sub

End Module

Thanks!
-Ben

What does the original code look like. We can't really make a reliable
judgement without knowing what the compiler was using as a basis for this IL
code. I'm assuming DEBUG mode which performs no optimization.

--
http://www.peterRitchie.com/blog/
Microsoft MVP, Visual Developer - Visual C#

I've got a simple console app which just assigns 6 to an int and prints out
the value. The IL looks like:

.method public static void Main() cil managed
{
.entrypoint
.custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01
00 00 00 )
// Code size 12 (0xc)
.maxstack 1
.locals init ([0] int32 x)
IL_0000: nop
IL_0001: ldc.i4.6
IL_0002: stloc.0
IL_0003: ldloc.0
IL_0004: call void [mscorlib]System.Console::Write(int32)
IL_0009: nop
IL_000a: nop
IL_000b: ret
} // end of method Module1::Main

What is the point of these:
IL_0002: stloc.0
IL_0003: ldloc.0

Why store something in a variable just to put the exact thing right back on
the stack where it was? The proper value was on the stack before that anway,
right? Couldn't these two lines be taken out?

-Ben

 

[Guest]

Greg Young describes how to configure a project to run and disassemble code
in DEBUG mode that is optimized to more closely evaluate your program based
on the code users would get
here:http://codebetter.com/blogs/gregyoung/archive/2006/06/09/146298.aspx

It's decidedly C#-skewed; but, I imagine most of it would apply VB 2005 as
well. He gets a slightly lower level (by debugging x86 assembly); but you
can ignore that stuff if you want and simply look at ildasm/Reflector results.

--
http://www.peterRitchie.com/blog/
Microsoft MVP, Visual Developer - Visual C#

Hi Peter, I think I've solved my own question. Those steps were involved in
getting the info into the variable I declared. I guess I was wondering why it
didn't just optimize it such that the code was as though you just called
colsole.write(6) but I did ask it to put 6 in a variable and use that for the
write function. This makes sense. I wonder why there isn't a stloc op that
copies from the stack (doesn't pop after. This would avoid having to
immediately replace what you took off in this scenario.

-Ben

Hi Peter,

Here's the code:

Module Module1

Sub Main()
Dim x As Integer = 6

Console.Write(x)
End Sub

End Module

Thanks!
-Ben

What does the original code look like. We can't really make a reliable
judgement without knowing what the compiler was using as a basis for this IL
code. I'm assuming DEBUG mode which performs no optimization.

--
http://www.peterRitchie.com/blog/
Microsoft MVP, Visual Developer - Visual C#


:

I've got a simple console app which just assigns 6 to an int and prints out
the value. The IL looks like:

.method public static void Main() cil managed
{
.entrypoint
.custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01
00 00 00 )
// Code size 12 (0xc)
.maxstack 1
.locals init ([0] int32 x)
IL_0000: nop
IL_0001: ldc.i4.6
IL_0002: stloc.0
IL_0003: ldloc.0
IL_0004: call void [mscorlib]System.Console::Write(int32)
IL_0009: nop
IL_000a: nop
IL_000b: ret
} // end of method Module1::Main

What is the point of these:
IL_0002: stloc.0
IL_0003: ldloc.0

Why store something in a variable just to put the exact thing right back on
the stack where it was? The proper value was on the stack before that anway,
right? Couldn't these two lines be taken out?

-Ben

 

[Greg Young]

Ah yes it was a bit C# skewed .. I will try to get some VB.NET appended to
it as it applies there as well.

Cheers,

Greg

Greg Young describes how to configure a project to run and disassemble
code
in DEBUG mode that is optimized to more closely evaluate your program
based
on the code users would get
here:http://codebetter.com/blogs/gregyoung/archive/2006/06/09/146298.aspx

It's decidedly C#-skewed; but, I imagine most of it would apply VB 2005 as
well. He gets a slightly lower level (by debugging x86 assembly); but you
can ignore that stuff if you want and simply look at ildasm/Reflector
results.

--
http://www.peterRitchie.com/blog/
Microsoft MVP, Visual Developer - Visual C#

Hi Peter, I think I've solved my own question. Those steps were involved
in
getting the info into the variable I declared. I guess I was wondering
why it
didn't just optimize it such that the code was as though you just called
colsole.write(6) but I did ask it to put 6 in a variable and use that for
the
write function. This makes sense. I wonder why there isn't a stloc op
that
copies from the stack (doesn't pop after. This would avoid having to
immediately replace what you took off in this scenario.

-Ben

Hi Peter,

Here's the code:

Module Module1

Sub Main()
Dim x As Integer = 6

Console.Write(x)
End Sub

End Module

Thanks!
-Ben


:

What does the original code look like. We can't really make a
reliable
judgement without knowing what the compiler was using as a basis for
this IL
code. I'm assuming DEBUG mode which performs no optimization.

--
http://www.peterRitchie.com/blog/
Microsoft MVP, Visual Developer - Visual C#


:

I've got a simple console app which just assigns 6 to an int and
prints out
the value. The IL looks like:

.method public static void Main() cil managed
{
.entrypoint
.custom instance void
[mscorlib]System.STAThreadAttribute::.ctor() = ( 01
00 00 00 )
// Code size 12 (0xc)
.maxstack 1
.locals init ([0] int32 x)
IL_0000: nop
IL_0001: ldc.i4.6
IL_0002: stloc.0
IL_0003: ldloc.0
IL_0004: call void [mscorlib]System.Console::Write(int32)
IL_0009: nop
IL_000a: nop
IL_000b: ret
} // end of method Module1::Main

What is the point of these:
IL_0002: stloc.0
IL_0003: ldloc.0

Why store something in a variable just to put the exact thing right
back on
the stack where it was? The proper value was on the stack before
that anway,
right? Couldn't these two lines be taken out?

-Ben

 

[Guest]

I'm too lazy to check (I didn't install VB on this computer but I have access
to one that does), all the configuration settings you detailed are identical
in VB, no?

--
Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote.
http://www.peterRitchie.com/blog/
Microsoft MVP, Visual Developer - Visual C#

Ah yes it was a bit C# skewed .. I will try to get some VB.NET appended to
it as it applies there as well.

Cheers,

Greg

Greg Young describes how to configure a project to run and disassemble
code
in DEBUG mode that is optimized to more closely evaluate your program
based
on the code users would get
here:http://codebetter.com/blogs/gregyoung/archive/2006/06/09/146298.aspx

It's decidedly C#-skewed; but, I imagine most of it would apply VB 2005 as
well. He gets a slightly lower level (by debugging x86 assembly); but you
can ignore that stuff if you want and simply look at ildasm/Reflector
results.

--
http://www.peterRitchie.com/blog/
Microsoft MVP, Visual Developer - Visual C#

Hi Peter, I think I've solved my own question. Those steps were involved
in
getting the info into the variable I declared. I guess I was wondering
why it
didn't just optimize it such that the code was as though you just called
colsole.write(6) but I did ask it to put 6 in a variable and use that for
the
write function. This makes sense. I wonder why there isn't a stloc op
that
copies from the stack (doesn't pop after. This would avoid having to
immediately replace what you took off in this scenario.

-Ben

:

Hi Peter,

Here's the code:

Module Module1

Sub Main()
Dim x As Integer = 6

Console.Write(x)
End Sub

End Module

Thanks!
-Ben


:

What does the original code look like. We can't really make a
reliable
judgement without knowing what the compiler was using as a basis for
this IL
code. I'm assuming DEBUG mode which performs no optimization.

--
http://www.peterRitchie.com/blog/
Microsoft MVP, Visual Developer - Visual C#


:

I've got a simple console app which just assigns 6 to an int and
prints out
the value. The IL looks like:

.method public static void Main() cil managed
{
.entrypoint
.custom instance void
[mscorlib]System.STAThreadAttribute::.ctor() = ( 01
00 00 00 )
// Code size 12 (0xc)
.maxstack 1
.locals init ([0] int32 x)
IL_0000: nop
IL_0001: ldc.i4.6
IL_0002: stloc.0
IL_0003: ldloc.0
IL_0004: call void [mscorlib]System.Console::Write(int32)
IL_0009: nop
IL_000a: nop
IL_000b: ret
} // end of method Module1::Main

What is the point of these:
IL_0002: stloc.0
IL_0003: ldloc.0

Why store something in a variable just to put the exact thing right
back on
the stack where it was? The proper value was on the stack before
that anway,
right? Couldn't these two lines be taken out?

-Ben

 

[Greg Young]

Yep sure are.

I'm too lazy to check (I didn't install VB on this computer but I have
access
to one that does), all the configuration settings you detailed are
identical
in VB, no?

--
Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote.
http://www.peterRitchie.com/blog/
Microsoft MVP, Visual Developer - Visual C#

Ah yes it was a bit C# skewed .. I will try to get some VB.NET appended
to
it as it applies there as well.

Cheers,

Greg

Greg Young describes how to configure a project to run and disassemble
code
in DEBUG mode that is optimized to more closely evaluate your program
based
on the code users would get
here:http://codebetter.com/blogs/gregyoung/archive/2006/06/09/146298.aspx

It's decidedly C#-skewed; but, I imagine most of it would apply VB 2005
as
well. He gets a slightly lower level (by debugging x86 assembly); but
you
can ignore that stuff if you want and simply look at ildasm/Reflector
results.

--
http://www.peterRitchie.com/blog/
Microsoft MVP, Visual Developer - Visual C#


:

Hi Peter, I think I've solved my own question. Those steps were
involved
in
getting the info into the variable I declared. I guess I was wondering
why it
didn't just optimize it such that the code was as though you just
called
colsole.write(6) but I did ask it to put 6 in a variable and use that
for
the
write function. This makes sense. I wonder why there isn't a stloc op
that
copies from the stack (doesn't pop after. This would avoid having to
immediately replace what you took off in this scenario.

-Ben

:

Hi Peter,

Here's the code:

Module Module1

Sub Main()
Dim x As Integer = 6

Console.Write(x)
End Sub

End Module

Thanks!
-Ben


:

What does the original code look like. We can't really make a
reliable
judgement without knowing what the compiler was using as a basis
for
this IL
code. I'm assuming DEBUG mode which performs no optimization.

--
http://www.peterRitchie.com/blog/
Microsoft MVP, Visual Developer - Visual C#


:

I've got a simple console app which just assigns 6 to an int and
prints out
the value. The IL looks like:

.method public static void Main() cil managed
{
.entrypoint
.custom instance void
[mscorlib]System.STAThreadAttribute::.ctor() = ( 01
00 00 00 )
// Code size 12 (0xc)
.maxstack 1
.locals init ([0] int32 x)
IL_0000: nop
IL_0001: ldc.i4.6
IL_0002: stloc.0
IL_0003: ldloc.0
IL_0004: call void
[mscorlib]System.Console::Write(int32)
IL_0009: nop
IL_000a: nop
IL_000b: ret
} // end of method Module1::Main

What is the point of these:
IL_0002: stloc.0
IL_0003: ldloc.0

Why store something in a variable just to put the exact thing
right
back on
the stack where it was? The proper value was on the stack before
that anway,
right? Couldn't these two lines be taken out?

-Ben