关于Keil C51中using关键字的使用心得

刚才看到一位很牛的师兄写的一篇日志中提到了Keil C51中using这个关键字的用法，粗心的我本来一直都没有留意它是用来干嘛的（因为我一般看见它都是在中断服务函数的定义开头处，好像没有了它也可以中断呀，所以才没怎么管），然而在日志中有看到这个关键字，所以也考究了一下，突然发现，原来这个东东和我最近在帮一个同学调的一个程序的时候突然遇到一个很怪的问题是有关系的，而且就是因为它才搞得程序莫明奇妙的出错（因为编译通过了，看起来也没什么错误，按C语言的逻辑分析也分析不出个什么所以然来，所以才怪）。

后来调试了好久，甚至到http://www.51hei.com/keil%CF%C2%D4%D8.html这里下载了好几个版本的keil,反汇编代码看了N次，基本各个版本出来的结果都差不多,不知情的情况下，推断出是Keil C51的编译器问题，以为Keil C51的编译器的变量空间分配出问题了，R7本来是用来作参数传递的，却也被编译器分配用来在主函数中被用来作循环变量，结果就是循环变量的汇编判断指令CJNE指令执行前，R7的值（也就是循环变量）被改变了，导致判断R7总是不能达到循环设置的值，就不断地在循环，也就致使按键扫描去抖动这个延时循环无法完成，就导致延时后的第二次判断无法进行，自然按键下来也就没反应了。后来尝试着关了定时器中断，又可以了，那就可以肯定是在执行CJNE前，R7的值被改变了，就是因为跳到了中断，然后中断函数执行的过程中，R7值被改变了（因为中断函数中还调用了其它的函数，而R7后来被分析反汇编代码时发现是被用作参数传递的），中断执行完后R7的值当然不正确啦！

得出推断后我的解决办法就是：让C51编译好之后手动修改汇编的指令，不要直接使用寄存器来作循环变量，而是使用能实现间接寻地址的R1进行间接寻址（指向0x77)的方式，终于把问题解决了，因为0x77在执行中断函数的过程中没被修改，CJNE语句能正常判断了，循环能完成了，按键也能扫下来了，问题也可以解决了。后来我又想到用_at_关键字直接指定循环变量的分配地址，这样的话就不用手动改汇编指令了，编译器直接就是编译成使用间接寻址的，这也算解决了。但还是有个疑问，为什么编译器会不够聪明地把R7的空间分配错了呢？一直在疑问。。。。。。奇怪，怎么编译器会出这种问题？

直到我刚才考究过了using的用法之后，才发现原来自己的推断是错的，结论的总方向还是对的，只是问题并不在编译器身上，真正的问题根源如下：

1.我的同学写的那个程序，用到了定时器0，它的中断服务函数定义是这样写的:

void t0(void) interrupt 1 using 0

{

........//一大串大代码，其中包括调用了其他函数，用到了R7作参数传递

}

这里就是加了个using 0，而问题就出在加了这个using 0，为什么？且听我的理解：

using关键字的作用就是指定某个函数在执行时切换寄存器组的：

51中有四个寄存器组,每个组有R0-R7这8个寄存器，用于CPU的数据处理，一般主函数main()默认使用第0组，因为PSW寄存器的初始值的第3、4位是00嘛，即默认指定了第0组。using 0就是指定在执行函数时切换为使用第0组，不加using关键字的话，一般都默认使用第0组，但这样的话在调用其他函数（包括中断服务函数）的时候，就会加入一些压栈指令以保护原来的R0-R7寄存器的（这样的话，程序执行会效率会低一点，因为会产生很多个指令是用来压栈出栈的），照这样说，只是加了using 0，使用的也是第0组又不是其它的组，程序就不应该有问题了吧，但是就是因为加了using 0，编译了一次，才发现在定时器中断函数t0()的入口中并没有发现把R0-R7的代码压入栈呀，就是说没有保护好R7呀，那当然就是在执行完之后回来R7不能回复原来的值啦，接下来的事情。。。。我就不说啦，这就是问题的根源，去掉using 0就可以了，编译器就自动帮你将R0-R7压栈，手动加了using 0，就是让编译器以为之前用的并不是第0组，而现在执行这个中断函数时就切换到第0组，而省去了将R0-R7这8个寄存器压入栈的指令了，这样虽然看起来是快了，然而对于这个程序来说却是致命的问题！！！因为根本没有保护好R0-R7，而没有保护R7并不是我预期发生的！！！这不是编译器的问题，是自己没有了解好、用好using的问题啊！还有，其实也可以在编译器选项里有选项来硬性规定编译器统一不直接使用寄存器而是使用间接寻址的办法来改变循环变量分配的地址的，或者使用

#pragma NOAREGS

定义函数
#pragma AREGS

来规定某个函数的是这样子。

当然，这样的规定和使用using本身并不冲突，只是使用了这个关键字后就可能