Woody Home Page
 
   
每个人都会问愚蠢问题
  
2011年10月7日
自从2009年初我们开始PA6488方案开发后, AR1688上面的主要开发工作就停止了. 但是就在全世界包括Palmmicro的我们都认为8位控制器难以为继的时候, SDCC编译器的开发团队仍然在不停工作. 这样一来, 有关编译器的更新信息变成了我们的软件发布详情以及我的AR1688博客的重要内容.
目前主要的SDCC Z80开发人员Philipp在今年年初宣布了一个用于减少Z80代码大小的新寄存器分配方案设计. 几个月后他完成了. 我一直坚信更小的代码有利于所有AR1688用户, 于是在6月份开始测试. 经过几个错误报告和修改后, 7月份的时候我终于用新版本全程编译成功. 尽管它仍然有错误编译代码的问题, 让我最不舒服的却是它的编译时间. 在我带4G内存的Sony VGN-FW235J上, 编译一次全部AR1688软件的时间由原来的2分钟左右增加到了差不多半个小时.
9月份Borut宣布了64位Windows上的64位SDCC支持. 我作为第一个报告了结果的用户抢先做了测试, 希望能够减少编译时间. 但是结果令人失望, 在我64位Windows Vista上, 32位和64位的SDCC实际上并没有表现出明显的性能区别.
我在SDCC邮件列表上问, 64位的SDCC到底有什么好处呢? Philipp建议Try --max-allocs-per-node 100000000 (recommended: At least 64 GB of RAM) or even just --max-allocs-per-node 8000000 (recommended: At least 6GB of RAM). It won't work with the 32-bit version unless you use PAE.
我接着为我的机器问4GB内存下建议的--max-allocs-per-node参数是多少? 这次Philipp没有像往常那样立刻回答. 当天晚上梦中, 我才意识到我问了一个愚蠢的问题. 4G内存是32位系统能支持的最大值, 因此同样也不会有什么不同.
 
2011年10月17日更新
昨天Borut宣布将于2011-11-26发布SDCC 3.1.0版本, 以纪念C语言之父Dennis M. Ritchie. 我意识到要再次开始测试SDCC的问题了, 不然跟不上这些开发人员.
通常我都自我介绍是个软件工程师. 不过在过去的一年中, 对于AR1688和SDCC而言, 我做的大多都是测试工程师的工作. 而且这种测试甚至比PA6488方案的开发还要困难.
在连续10个小时的测试工作后我提交了编译器错误3424436, 而且最终我发现SDCC编译出问题的函数SipCallStep1跟差不多一年前我报告的编译器错误3122620中的是同一个函数.
事实上这不是第一次同一个函数编译出错了, 某些代码就是天生与众不同的难于编译. 在之前的错误报告3381400和3407632中, 我发现同一个函数_DspLoadFile被以不同的方式编译错误了2次. 为了避免下一个10小时的测试工作, 下次我打算从先抓老嫌疑犯开始!
 
2012年3月17日更新
去年SDCC开发团队发布了3.1.0版本, 在过了快5个月后, 它编译AR1688软件时仍然表现得一团糟.
当SDCC在2009年发布2.9.0的时候我们几乎没有碰到什么问题. 2010年的SDCC 3.0.0让我们花了2个星期追赶新版本. 至今的0.57测试版本仍然在沿用SDCC 3.0.1 #6078 (Dec 7 2010) (MINGW32).
SDCC 3.1.0则是一开始就不对头, 它正式发布的时候就没有解决我提交的第4个--max-allocs-per-node编译错误. 虽然我欣赏其中的新特性new register allocator in the z80 and gbz80 ports (optimal when using --opt-code-size and a sufficiently high value for --max-allocs-per-node for the z80 port), 我一直被Caught signal 11: SIGSEGV的程序崩溃困扰. 我在另外的地方读到Almost all signal 11 crashes (segment faults) are caused by a reference to the object of a null pointer, 我猜想新寄存器分配方案的实现中肯定还有不少潜在问题.
Philipp提供了另外一个选项--oldralloc来使用老的寄存器分配方案. 在很多次对新方案失望后, 我开始测试使用老分配方案的3.1.0版本, 没想到也是错误一堆. 在Philipp修改好我提交的2个--oldralloc编译错误后, 我想我终于找到了一个更新到3.1.0的方式.
昨天我开始编译全部的AR1688升级文件, 没想到的是, 原来有GB2312编码汉字的源程序居然全部不能编译了!
 
2012年8月13日更新
在Philipp的建议下, SDCC的开发人员提前了今年的3.2.0版本发布, 希望能有个稳定版本. 当时我在忙着学习Linux编程. 上周我完成AR1688 0.58软件发布的测试后, 想到的第一件事情就是测试SDCC的新版本.
刚开始我挺高兴, 3.1.0版本中2个让我恼火的问题, Caught signal 11: SIGSEGV--max-allocs-per-node, 居然都解决了. 但是测试了更多的AR1688设备后, 我又新发现了至少3个问题. 看来在相当一段时间内, 我们还要继续使用老的3.0.1 #6078版本.
下表中总结了测试结果. 代码大小和编译时间使用命令行mk ar168g sip us和标准编译器选项-mz80 -c --std-c99产生.
SDCC版本 额外的编译器选项 代码大小(字节) 编译时间(分钟) 已知问题
3.0.1 #6078 158073 2
3.2.1 #8062 156413 6 AR168M串口错误
3.2.1 #8062 --oldralloc 154871 3 AR168G键盘错误
3.2.1 #8062 --max-allocs-per-node 10000 152552 13 AR168R某SIP消息在VoIPtalk系统下错误
上面的编译时间都在我的老Sony VGN-FW235J上测试, 它运行的是Intel(R) Core(TM)2 Duo CPU T5800 @ 2.00GHz, 4GB DDR2内存和64位Windows Vista. 当在我新的Sony VPCEG, 运行Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz, 6GB DDR3内存和64位Windows 7上对比测试最长时间的情况后, 总时间从13分钟降到了6分钟. 在过去的2个月中我都一直没有意识到我的新电脑比老的快了这么多!
 
2012年8月14日更新
今天的测试显示SDCC 3.2.0正式版本没有AR168G键盘错误的问题(用--oldralloc编译选项).
 
2014年1月26日更新
有关Borut Ražem的坏消息.

本页面尚无任何评论.

更多选项? 请先登录或者注册. metropolitan-tundra