From: RONGRONG L. <wo...@pa...> - 2012-08-13 15:57:28
|
http://palmmicro.com/woody/blog/ar1688/20120813.php *Testing SDCC 3.2.1* 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 <../entertainment/20120719.php> when it was released. After I finished the test of AR1688 software release 0.58 <../../../ar1688/software/sw058.html> 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 <20120317.php>, /Caught signal 11/ and /max-allocs-per-node/, were gone. But more tests with different AR1688 <../../../ar1688/index.html> devices showed at least 3 more bugs. Seems that we have to continue to use old 3.0.1 #6078 <20101208.php> 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 <../../../ar1688/module.html> UART error 3.2.1 #8062 --oldralloc 154871 3 AR168G <../../../ar1688/user/gp1266.html> keypad error 3.2.1 #8062 --max-allocs-per-node 10000 152552 13 AR168R <../../../ar1688/roip.html> SIP message error with VoIPtalk <../../../res/voiptalk.html> The above compile time were all measured on my old Sony VGN-FW235J <../pa6488/20090808.php> 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 did not realized that my new computer was so much faster than the old one in the past 2 months! -- Woody http://palmmicro.com/woody/ |
From: Philipp K. K. <pk...@sp...> - 2012-08-13 17:08:09
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 1) After the 3.2.0 release the smallopts and lospre branches have been merged, which are naturally not tested as much as the older work in trunk was at the time of the 3.2.0 release. Thus you might want to try 3.2.0, too, when looking for the most bug-free version. 2) Can you track these bugs you discovered down to the point where you can make bug reports at sourceforge for them? 3) You might want to try the --no-peep option to check if this is a peephole issue, and the --nolospre option (in case it is a bug that got introduced after the 3.2.0 release) to check if the bug is due to the merge of the lospre branch. 4) I am happy to see that code size has gone down for you, even though the difference is far less than what I see in my testcases. Philipp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlApNGsACgkQbtUV+xsoLpqhOwCdF9as0iyHVylvHpev4tvI75tk bdkAnjTRCjr4kKbImggHAOk2/m9WB3Ol =oHpN -----END PGP SIGNATURE----- |
From: RONGRONG L. <wo...@pa...> - 2012-08-13 18:17:56
|
Great news. 3.2.0 release does not have the "AR168G keypad error" problem (with "--oldralloc" option). When I tried --nolospre option with 3.2.1 #8062, I got the old familiar error: C:\SDCC\BIN\sdcc menu.c -mz80 -c --std-c99 --oldralloc --nolospre --codeseg CODE4 menu.asm:3274: Error: <a> machine specific addressing or addressing mode error removing menu.rel ..\bin\make: *** [menu.rel] Error 1 where line 3274 in menu.asm is "jr 00107$" I do not have the hardware of the other 2 bugs in hand, will try 3.2.0 release on those tomorrow. Woody http://palmmicro.com/woody/ On 8/14/2012 1:07 AM, Philipp Klaus Krause wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 1) After the 3.2.0 release the smallopts and lospre branches have been > merged, which are naturally not tested as much as the older work in > trunk was at the time of the 3.2.0 release. Thus you might want to try > 3.2.0, too, when looking for the most bug-free version. > > 2) Can you track these bugs you discovered down to the point where you > can make bug reports at sourceforge for them? > > 3) You might want to try the --no-peep option to check if this is a > peephole issue, and the --nolospre option (in case it is a bug that > got introduced after the 3.2.0 release) to check if the bug is due to > the merge of the lospre branch. > > 4) I am happy to see that code size has gone down for you, even though > the difference is far less than what I see in my testcases. > > Philipp > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAlApNGsACgkQbtUV+xsoLpqhOwCdF9as0iyHVylvHpev4tvI75tk > bdkAnjTRCjr4kKbImggHAOk2/m9WB3Ol > =oHpN > -----END PGP SIGNATURE----- > |