本帖最后由 Jim12345 于 2016-6-12 17:21 编辑
laoxu 发表于 2016-6-12 17:00
2.这个从V2开始，PSW及70-7F的RAM都是这样处理的；
------------------------------------------------ ...
2 PSW等关键寄存器所有V1/V2版本都不用切换的。如KF8F213的00-7F只有一个bank，则所有使用00-7F的特殊寄存器都不用切换bank。
RAM是从V2开始才有公共区域。
3.硬件上所有版本都支持，只是没有做库。标准的指令实现查表只能查8位，要查16位要用库模式，这种查表模式类似外设读的方式实现的。
Jim12345 发表于 2016-6-12 16:19
配置项选择release模式（不要选择debug模式），开O3优化，如图
找到了！
打开看了一下， 里面已经设置成 O3优化了。
选择release模式，再 全部构建，程序短了近一半。
另外，不能 重新全部构建的原因也找到了，要到 “项目-->清理” 点一下，即可。
时个小BUG, 建议下一版本，在 “全部构建” 时，先执行 自动 “清理项目” 。
哪位朋友能 解释一下，指令集中没有的 MOVZ R0, 0x8e的执行的动作吗？
和 指令 MOV R0, 0x8e 有啥区别？
是否 MOVZ R0, 0x8e 指令，相当于执行 MOV R0, 0x8e； BANKSEL0x00(切换到第0页); 这两条指令？
MOVZ应该是对标志位有影响，不影响banksel
MOV对标志位没有影响
Jim12345 发表于 2016-6-12 16:19
配置项选择release模式（不要选择debug模式），开O3优化，如图
选择release模式，编译显示：1280(31.4%) ，比原 2439(59.8%) 减少了近一半。
但通过查看 LST文件，发现此显示数据 1280(31.4%) 不正确！！！
实际占用程序内存约为 0- 0x7a3 ，0xe00 - 0xfe3, 2444字（里面有几个空位没挑出），等于优化无效，不知何故？
重建新文件，只单选 release模式，编译显示：1280(31.4%) 。
通过查看 LST文件，发现实际占用程序内存约为 0- 0x500 ,正确！！！
因此，编译程序还是有小BUG, 手动 执行“清理项目” ，清理的不够彻底，保留debug部分程序。 建议下一版本，在 “全部构建” 时，要先彻彻底底的 执行 自动 “清理项目” ，做到初始化格式化。
laoxu 发表于 2016-6-12 18:01
重建新文件，只单选 release模式，编译显示：1280(31.4%) 。
通过查看 LST文件，发现实际占用程序内存约为 ...
目前确实要手动 清理项目。
Jim12345 发表于 2016-6-12 18:13
目前确实要手动 清理项目。
还有一个问题，在 “全部构建” 时，不会将修改后的文件自动存盘，要手动存盘后，编译结果才会正确。
建议下一版本改正。
大家都是做产品的，如果一个芯片就需要这么折腾，那这个芯片的意义何在？
我从来就是什么好用用什么。
本帖最后由 laoxu 于 2016-6-14 07:23 编辑
好像 ChipON 不支持 C和汇编 混合编译，希望插入汇编能支持标号，否则这插入汇编用途不大，如下：
void abc()
{ char Ca;
intIa;
__asm
MOV R0, Ca ；将Ca装入R0
MOV R1, Ia ；将Ia装入R1,R2
MOV R2, Ia+1
__endasm;
}
dongshan 发表于 2016-6-13 08:35
大家都是做产品的，如果一个芯片就需要这么折腾，那这个芯片的意义何在？
我从来就是什么好用用什么。 ...
我的观点和你相反，个人认为，ChipON还是有些实力的。
市场上的芯片一大堆，从海尔到台系，几乎都是抄欧美的东西，改改弄弄的，真真自成一系（从C编译器到芯片）的，少的可怜。
相反，或许ChipON 实力较强，走自主创新的道路，正因为自主创新，被俺一试用，就试出问题了，什么问题？经验不足考虑不周呀。
人家做了几十年的东西，积累了丰富的经验，不是一天二天就能搞清楚弄明白的，总要付点学费吧。
既然ChipON 开了这个头，只要公司能生存下去，用不了几年，我相信ChipON 会越做越好越完善的。
laoxu 发表于 2016-6-12 16:52
配置项选择release模式，第一次程序能编译，现在又不能编译了（程序没变）。
这个不是不能编译的问题，是程序没有做任何改动的情况下，系统默认不会做重复编译的事情。表示已经编译过了，编译器此时什么都没做。
从楼主抓图上来看，应该是用的eclipse，对于build的时候，没有修改则不编译，是eclipse的问题。
eclipse集文本编辑器、工程管理、编译器于一身的IDE。
Build All的时候不修改则不动作，此功能不属于 C Compiler。
还有就是按照惯例，O0优化等级太低，一般不用，除非调试。O2 speed模式是正式产品用的（你的产品flash这么小，可能要size模式）。O3仅仅用来测试，一般不要用。你的项目小是无所谓的。像几十M以上的项目，GCC一般是不敢用O3的。
linqing171 发表于 2016-6-13 13:54
还有就是按照惯例，O0优化等级太低，一般不用，除非调试。O2 speed模式是正式产品用的（你的产品flash这么 ...
确实，IDE是基于eclipse的，习惯了就会发现他的功能比较强，尤其是编辑等功能。
ChipONCC不是基于GCC的，所以开的优化方式不完全一样。但对于用户来说优化等级实际是不用管的（毕竟系统小），只需要记住调试时用debug模式，代码生成是用release模式。
linqing171 发表于 2016-6-13 13:54
还有就是按照惯例，O0优化等级太低，一般不用，除非调试。O2 speed模式是正式产品用的（你的产品flash这么 ...
本例中，没优化的编译，实际内设O2级优化。我试过，和O0，O1级优化，代码量基本相同。
只有上O3级优化，代码量才显著下降。
应该是编译器对ChipON的数据结构未合理分配及库函数质量不佳造成的。
Jim12345 发表于 2016-6-13 14:12
确实，IDE是基于eclipse的，习惯了就会发现他的功能比较强，尤其是编辑等功能。
ChipONCC不是基于GCC的， ...
ROM容量偏小，不优化节约点用，没写多少程序就ALL了。
本帖最后由 Jim12345 于 2016-6-13 14:45 编辑
laoxu 发表于 2016-6-13 08:54
我的观点和你相反，个人认为，ChipON还是有些实力的。
市场上的芯片一大堆，从海尔到台系，几乎都是抄欧 ...
laoxu楼主还是很赞的，目前阶段我认为ChipON的工具还是有瑕疵的，是需要进一步改进，最大的问题是使用习惯还不一样，不过工具是基于eclipse的，用过JAVA的人就很容易上手。当然，熟悉了我们的工具，用JAVA也是很容易的。
认同楼主的观点，在MCU领域我们还是要有一定的自主创新，只有这样，我们在后续的发展中才能跟得上节奏，甚至某种程度上实现超越，后续我们的8位新内核、32位DSP内核无不体现了这一思想，这也是我们内核采用KungFu命名的原因。
ChipON MCU的特点在于行业针对性比较强，外设非常丰富，尤其是模拟外设，精度较高，另外就是抗干扰能力和低功耗能力，这两点对每一个产品型号来说都是要时间磨的。KF系列的MCU经过六七年的时间量产，性能上得到了保证。目前每月有大批量在量产，而且部分客户是国内/国际一流客户。
后续确实需要的是时间，只有时间才能让我们精益求精。也希望楼主和其他朋友继续不吝赐教。
再分析一下楼主编译的代码可以看到：
主程序生成150条指令+115条banksel指令，banksel优化后只有4条，实际为154条指令。
其余的*、/、%都由库生成。
对这个程序来说，编译器的效率还算可以的，只是库的精炼度还需提高。
laoxu 发表于 2016-6-13 08:54
我的观点和你相反，个人认为，ChipON还是有些实力的。
市场上的芯片一大堆，从海尔到台系，几乎都是抄欧 ...
自主个毛线，就是PIC的。