回复【4楼】avr-arm 光芒
lz杯具了，用好了iar你会发现他很爽，当然，现在版本还太低，有很多不足。

-----------------------------------------------------------------------

好的编译器，不需要你操太多的心
就如上面的 s>>8, s/2 之类，应该都能认出来

回复【8楼】stm8s103
cosmic不会用寄存器，
iar不会stm8指令，
---------------
从长远讲，cosmic可能一直悲剧下去。
iar提升空间应该还有很多。
-----------------------------------------------------------------------

但是，IAR的大方向应该定下来了：那就是我不喜欢、不看好的“虚拟寄存器”
只要它不放弃这点，我就不会用IAR
但是它应该不会改变架构了

回复【27楼】Cliff
-----------------------------------------------------------------------
但是，iar的大方向应该定下来了：那就是我不喜欢、不看好的“虚拟寄存器”
只要它不放弃这点，我就不会用iar
但是它应该不会改变架构了
-----------------------------------------------------------------------

楼上有偏见了。

虚拟寄存器不好的地方，只是中断的时候要保护虚拟寄存器，
但是优点也是显而易见的，解放通用寄存器，减少压栈出栈操作。

楼上玩OS吧，大概是认为iarstm8任务切换需要保护16个虚拟寄存器，浪费时间。
可以和AVR比较一下，
avr 一个push是两个时钟周期，32个寄存器要64个时钟周期，
stm8一个push是一个时钟周期，16个虚拟寄存器才16个周期，再加上9个通用寄存器入栈时间，总共25个时钟周期，
大大小于AVR寄存器保护时间。

AVR用OS都能用很好，stm8更不是问题。

回复【28楼】stm8s103
-----------------------------------------------------------------------

从你言谈中很能透露出对IAR的支持啊！

但是，现在几款STM8的C编译器都不尽如人意
IAR强大是强大，但是抛不开RISC的理念，却是一个硬伤。
不论是STM8的虚拟寄存器，还是AVR的虚拟（软件）堆栈，都很明显的露出了生搬硬套RISC C编译器的影子

所谓万事古难全，如果IAR不是致力于RISC，它也不可能为每一款MCU设计对它优化的编译器
Keil当年可以专注于51，但IAR不可专注于STM8、AVR……之内的一样

我的意思是，IAR的C编译器理念，并不是最理想的

现在就回到你所说的问题上来：
〉虚拟寄存器不好的地方，只是中断的时候要保护虚拟寄存器，
〉但是优点也是显而易见的，解放通用寄存器，减少压栈出栈操作。
我问你呀，是一系列的 PUSH/POP 快，还是 ADD SP, #$xx  SUB SP, #$xx 快呢？
虽然说，这个问题有些片面，有时候从全局考虑，用 IAR 的方式确实能更有效的减少代码量
但是，正如我以前曾说过（在IAR与Keil MDK编译器之争），IAR 是以近乎变态的方式来换取空间优化的
我这么说，不是否认IAR可能会成为STM8编译器的NO.1，但是，就算NO.1，在我看来也有不理想的地方存在的
因为，它不能专注

回复【30楼】cyberjok
楼上高手啊，有没有计划自己搞个编译器？

-----------------------------------------------------------------------

我觉着Cliff有这个实力。