|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Pointless IL instructions?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 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 Nietzsche 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. Show quote "Ben R." wrote: > 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 Hi Peter,
Here's the code: Module Module1 Sub Main() Dim x As Integer = 6 Console.Write(x) End Sub End Module Thanks! -Ben Show quote "Peter Ritchie [C# MVP]" wrote: > 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# > > > "Ben R." wrote: > > > 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 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 Show quote "Ben R." wrote: > Hi Peter, > > Here's the code: > > Module Module1 > > Sub Main() > Dim x As Integer = 6 > > Console.Write(x) > End Sub > > End Module > > Thanks! > -Ben > > > "Peter Ritchie [C# MVP]" wrote: > > > 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# > > > > > > "Ben R." wrote: > > > > > 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 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. Show quote "Ben R." wrote: > 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 > > "Ben R." wrote: > > > Hi Peter, > > > > Here's the code: > > > > Module Module1 > > > > Sub Main() > > Dim x As Integer = 6 > > > > Console.Write(x) > > End Sub > > > > End Module > > > > Thanks! > > -Ben > > > > > > "Peter Ritchie [C# MVP]" wrote: > > > > > 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# > > > > > > > > > "Ben R." wrote: > > > > > > > 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 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 Show quote "Peter Ritchie [C# MVP]" <PRSoCo@newsgroups.nospam> wrote in message news:24FA51A8-308F-4449-BCA2-AA49B8FB00FC@microsoft.com... > 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# > > > "Ben R." wrote: > >> 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 >> >> "Ben R." wrote: >> >> > Hi Peter, >> > >> > Here's the code: >> > >> > Module Module1 >> > >> > Sub Main() >> > Dim x As Integer = 6 >> > >> > Console.Write(x) >> > End Sub >> > >> > End Module >> > >> > Thanks! >> > -Ben >> > >> > >> > "Peter Ritchie [C# MVP]" wrote: >> > >> > > 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# >> > > >> > > >> > > "Ben R." wrote: >> > > >> > > > 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 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? -- Show quoteBrowse http://connect.microsoft.com/VisualStudio/feedback/ and vote. http://www.peterRitchie.com/blog/ Microsoft MVP, Visual Developer - Visual C# "Greg Young" wrote: > 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 > "Peter Ritchie [C# MVP]" <PRSoCo@newsgroups.nospam> wrote in message > news:24FA51A8-308F-4449-BCA2-AA49B8FB00FC@microsoft.com... > > 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# > > > > > > "Ben R." wrote: > > > >> 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 > >> > >> "Ben R." wrote: > >> > >> > Hi Peter, > >> > > >> > Here's the code: > >> > > >> > Module Module1 > >> > > >> > Sub Main() > >> > Dim x As Integer = 6 > >> > > >> > Console.Write(x) > >> > End Sub > >> > > >> > End Module > >> > > >> > Thanks! > >> > -Ben > >> > > >> > > >> > "Peter Ritchie [C# MVP]" wrote: > >> > > >> > > 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# > >> > > > >> > > > >> > > "Ben R." wrote: > >> > > > >> > > > 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 > > > Yep sure are.
Show quote "Peter Ritchie [C# MVP]" <PRSoCo@newsgroups.nospam> wrote in message news:5EC5DDF4-F0D3-4753-BE6E-087B9A4425A5@microsoft.com... > 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# > > > "Greg Young" wrote: > >> 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 >> "Peter Ritchie [C# MVP]" <PRSoCo@newsgroups.nospam> wrote in message >> news:24FA51A8-308F-4449-BCA2-AA49B8FB00FC@microsoft.com... >> > 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# >> > >> > >> > "Ben R." wrote: >> > >> >> 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 >> >> >> >> "Ben R." wrote: >> >> >> >> > Hi Peter, >> >> > >> >> > Here's the code: >> >> > >> >> > Module Module1 >> >> > >> >> > Sub Main() >> >> > Dim x As Integer = 6 >> >> > >> >> > Console.Write(x) >> >> > End Sub >> >> > >> >> > End Module >> >> > >> >> > Thanks! >> >> > -Ben >> >> > >> >> > >> >> > "Peter Ritchie [C# MVP]" wrote: >> >> > >> >> > > 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# >> >> > > >> >> > > >> >> > > "Ben R." wrote: >> >> > > >> >> > > > 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 >> >> >>  |
|||||||||||||||||||||||
Other interesting topics