不明白为什么VS2k5编译for的时候……

今天在做一个实验，突然发现一个不寻常的地方：VS2k5 C# 在编译for循环的时候，IL代码跟以前的方式不一样：

      L_0029: ldloc.1
      L_002a: ldc.i4 100000000
      L_002f: clt
      L_0031: stloc.s flag1
      L_0033: ldloc.s flag1
      L_0035: brtrue.s L_0018

这个for循环的C#语句大致为
for (num1 = 0; num1 < 100000000; num1++)

上面IL里面所显示的正是比较num1是否小于100000000的片断，如果在VS2k3里面，则应该编译成：
      L_0029: ldloc.1
      L_002a: ldc.i4 100000000
      L_002f: blt.s L_0018

仔细再研究一下，发现这个变化只在Debug模式里面出现，也就是说这个变化并不是为了效率考虑的。但是原来的方式也能够比较容易的进行调试跟踪，实在搞不清楚为什么要用clt的方式。更加奇怪的是，在clt比较得出结果之后，还要弦弹出来保存到一个flag1的本地变量里面，然后再重新压栈。想了想，可能还是为了“更”方便的进行调适吧：比如说在IL级别进行调试的时候，可能看堆栈是不方便的，同时看两个变量的关系也是让人眼花的（n位数字比较，光是对齐数字就头痛了）。通过这样的IL变化，我们可以简单的看看flag1到底是什么结果。如果发现不对了，还可以在跳转之前把当前执行语句移到其他地方，或者修改转移条件，甚至不需要修改循环变量。这些在以前估计是不可能的，因为blt直接就判断并跳走了，就算可以修改转移条件，也必然影响循环变量i。如果考虑的更深入一点，我们可以简单的修改一条IL指令，使得flag恒为true或者false，强制控制流按照我们希望的方式去走，但是又不影响所有源代码里面的变量，这样子也许能够轻易的进行全覆盖的单元测试。不过这么强的能力目前好像还没有看到C#里面有相应的操作项，所以一切都只是猜测。真正的原因也许需要查找更多的资料，或者问问C#项目组的人员才知道了。

顺便说一下，最新版本的Reflector好像有点奇怪，在同一个函数里面IL结构完全一样的两个循环，前面一个会被翻译成while，后面一个会被翻译成for，也不知道是从什么时候开始的。因为这个是在看VS2k5 C#的Release模式编译出来的程序发现的，我一开始还以为这是VS2k5的优化成果呢……