| |
|
|
|
| Stupid is as Stupid Does |
| | |
| Oct 7, 2011 |
We started PA6488 solution development in early 2009. Since then, the major development on AR1688 had stopped.
However, even when the whole world include us at Palmmicro believe 8-bit controller can not go any where further, the SDCC compiler development team never stopped.
So the compiler update information had become an important part of our software release note and my AR1688 blog post.
Philipp, the current major SDCC Z80 developer, announced a new register allocator design to reduce Z80 code size early this year. After several month he finished it.
I always believe smaller code size is better for all AR1688 users. I began to test it in Jun, after several bug reports and fixes, in Jul I was able to compiler our AR1688 code with the new register allocator.
However, while it still had code generating bugs, the most annoying about the new version was the compilation time.
The total AR1688 software compilation time had increased from 2 minutes to about 30 minutes on my Sony VGN-FW235J with 4G RAM.
In Sep, Borut announced the 64-bit SDCC support on 64-bit Windows. I tested it as the first reported-result user, hoping it can reduce the compilation time.
But the result was disappointing, the 32-bit and 64-bit SDCC actually had no obvious performance changes on my 64-bit Windows Vista.
In SDCC mailing list I asked what was the good for the 64-bit?
Philipp suggested 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.
Then I asked how much recommended --max-allocs-per-node with 4GB RAM for my own computer, this time Philipp did not reply as fast as he usually does.
During the dream of that night, I realized that I asked a stupid question, because 4G RAM is the max of 32-bit system can support, there is no difference too.
Updated on Oct 17, 2011
Yesterday Borut announced that SDCC 3.1.0 release was planned on 2011-11-26, and this release is dedicated to memory of Dennis M. Ritchie, father of the C programming language.
I realized that I must start my SDCC bugs tracking work again in order to keep up with those developers.
I usually introduce myself as a software engineer, but actually I am more of a test engineer for AR1688 and SDCC in this recent year. However, the test work is even more difficult than the PA6488 solution development.
After spending 10 continuous hours to track and report compiler bug 3424436, I finally found the function SipCallStep1 which SDCC compiled wrong was actually the same function I report in bug 3122620 almost a year ago.
Actually it was not the first time the same function compiled wrong, some code are born to be different and hard to compile. I reported _DspLoadFile function compiled wrong (in a different way) with both bug 3381400 and 3407632.
To avoid another 10 hours of bug tracking, I will round up the usual suspects first next time!
Updated on Mar 17, 2012
Last year SDCC team released 3.1.0 version. However, after nearly 5 months, it is still a mess when compiling AR1688 software.
We did not have much problem when SDCC 2.9.0 released on 2009. When SDCC 3.0.0 was released on 2010, it took us about 2 weeks to catch up with the new version.
With today's 0.57 test software, we are still using SDCC 3.0.1 #6078 (Dec 7 2010) (MINGW32).
It had a bad start as SDCC 3.1.0 was released with the 4th of my filed --max-allocs-per-node bug open.
Although I like the feature of 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),
I was haunted by Caught signal 11: SIGSEGV crash all the time.
I read Almost all signal 11 crashes (segment faults) are caused by a reference to the object of a null pointer somewhere else, and I guess there must be some more hidden bugs in the new register allocator implementation.
Philipp provided another option --oldralloc to use the old register allocator. After so many times of disappointment of the new one, I turned to test 3.1.0 with old allocator. However there were bugs too.
After Philipp fixed the 2 --oldralloc bugs I filed, I guessed that I had finally found a way to live with 3.1.0.
Yesterday I began to build all my AR1688 binary files, and was shocked to find that all our source files with GB2312 coded Chinese characters can not be compiled any more!
Updated on Aug 13, 2012
With suggestion from Philipp, SDCC team released 3.2.0 earlier than usual this year in the hope of a steady version. I was busy learning Linux programming when it was released.
After I finished the test of AR1688 software release 0.58 last week, the first thing in my mind was to test the new SDCC version.
At first I was very happy, the 2 annoying bugs in 3.1.0, Caught signal 11: SIGSEGV and --max-allocs-per-node, were gone. But more tests with different AR1688 devices showed at least 3 more bugs.
Seems that we have to continue to use old 3.0.1 #6078 for quite some time.
The table below summarizes the test results. Code size and compile time results are generated with command line mk ar168g sip us and standard compiler option -mz80 -c --std-c99.
|
| SDCC version |
Extra compile option |
Code size (bytes) |
Compile time (minutes) |
Known problem |
| 3.0.1 #6078 |
|
158073 |
2 |
|
| 3.2.1 #8062 |
|
156413 |
6 |
AR168M UART error |
| 3.2.1 #8062 |
--oldralloc |
154871 |
3 |
AR168G keypad error |
| 3.2.1 #8062 |
--max-allocs-per-node 10000 |
152552 |
13 |
AR168R SIP message error with VoIPtalk |
The above compile time were all measured on my old Sony VGN-FW235J with Intel(R) Core(TM)2 Duo CPU T5800 @ 2.00GHz, 4GB DDR2 RAM and 64-bits Windows Vista.
When I tried the slowest one on my new Sony VPCEG with Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz, 6GB DDR3 RAM and 64-bits Windows 7, the total time reduced to 6 minutes from 13 minutes.
I had not realized that my new computer was so much faster than the old one in the past 2 months!
Updated on Aug 14, 2012
Test on today showed that SDCC 3.2.0 release did not have the AR168G keypad error problem (with --oldralloc option).
Updated on Jan 26, 2014
Sad news about Borut Ražem.
|
No comments for this page yet.
|
