C:\sdcc\src>..\bin\sdcc -v SDCC : mcs51/gbz80/z80/ds390/pic16/pic14/TININative/ds400/hc08 3.0.4 #6720 (Aug 6 2011) (MINGW32) After those bug fixes in the past 4 weeks, finally this version can generate correct AR1688 SIP binary file now. Generally speaking 3.0.4 #6720 can generate smaller code compared with 3.0.1, no matter --oldralloc is used or not. To compare the new register alloc algorithm, here are the size difference in different part of my software: code0 data code1 code2 code3 code4 code5 code6 code7 code 1D70 1A88 4617 51B1 46F0 5055 5552 434C 552B 1B93 // gp2266 sip 0.53.017 1D20 1A88 4641 4FEE 46E3 4F9D 5090 44E7 56C2 1AB8 // gp2266 sip 0.53.018 0.53.017 result using command line like C:\SDCC\BIN\sdcc sipr.c -mz80 -c --oldralloc --std-c99 --codeseg CODE7 0.53.018 result using command line like C:\SDCC\BIN\sdcc sipr.c -mz80 -c --std-c99 --codeseg CODE7 "code5" which is mainly SIP/RTP send functions get 6% size reduction, while others are not so easy to predict. I noticed that the compile time is reduced a lot compared with 3.0.4 #6622, maybe I should try --max-allocs-per-node with some larger value?
Woody http://palmmicro.com/woody/ ----- Original Message ----- From: "Philipp Klaus Krause" <p...@spth.de> To: <sdcc-user@lists.sourceforge.net> Sent: Tuesday, July 12, 2011 6:39 PM Subject: Re: [Sdcc-user] Z80 code size reduction > Am 12.07.2011 07:27, schrieb Lin Rongrong: >> I tried 3.0.4 #6622 (Jul 11 2011) (MINGW32) version today. It took my >> Intel >> Core2 Duo CPU T5800@2GHz with 4GB RAM 34 minutes to build current AR1688 >> 0.53.012 SIP software. The previous 3.0.1 only need less than 2 minutes. > > What's the difference in code size? > I have some dieas about how to get a better compilation speed / code > size trade-off, but I don't want to implement them before the 3.1.0 > release. There's already enough new, potentially buggy stuff in sdcc > that needs more testing as is. > >> Although there is no compile problem now and the code size is indeed >> reduced >> a lot, the compiled result is bad. It can still boot up with DHCP ok, but >> major functions like software upgrade and SIP registration are broken. >> I guess I need to debug with the options mentioned in the following >> email, >> since the compile time is so long right now, I'd like to ask if there is >> any >> option update before I start. >> >> Woody >> >> http://palmmicro.com/woody/ >> >> ----- Original Message ----- >> From: "Philipp Klaus Krause" <p...@spth.de> >> To: "Sdcc-User" <sdcc-user@lists.sourceforge.net> >> Cc: <z88dk-develop...@lists.sourceforge.net> >> Sent: Wednesday, April 06, 2011 11:01 PM >> Subject: [Sdcc-user] Z80 code size reduction >> >> >>> Dear users of the Z80 port, >>> >>> I've been working on a new register allocator for some months. >>> >>> The current protoype already generates better code than current 'normal' >>> sdcc in most cases. A code size reduction of about 10% seems typical. >>> >>> A small benchmark can be found at >>> https://sourceforge.net/apps/trac/sdcc/wiki/Philipp%27s%20TODO%20list, >>> where the rightmost column gives the code sizes for the new allocator. >>> As you can see, with the new allocator sdcc in most cases generates >>> smaller code than all other compilers, including the last HITECH-C >>> compiler. >>> >>> You can download sdcc with the new allocator from >>> http://colecovision.eu/stuff/sdcc-or-2011-4-6.tar.gz. I have worked on >>> fixing bugs for about a week; all regression tests complete without >>> errors, and my own Z80 applications work when compiled with this >>> version. >>> >>> However it's likely that there are still lots of bugs, thus it needs >>> testing. Please test this version of sdcc on your code, and tell me >>> about any problems you encounter. >>> >>> A short description of the command line options you might want to try: >>> >>> --optralloc-exact-cost : Use an exact cost function. This should >>> generate slightly better code than without this option. > > This option has been removed. The exact cost function works so well, > that it is always used in the z80 port now. And since it was never > implemented in the gbz80 port, there's no need for the option there > either. > >>> >>> --max-allocs-per-node : Higher values result in better code, at the cost >>> of longer compile time (and higher memory usage during compilation). The >>> default value is 10000. > > Of course this can be used to speed up compilation, by setting it to a > value lower than 10000 as well. > >>> >>> --opt-code-size : Optimize for code size instead of speed. Currently has >>> a relatively small impact on the code generated. >>> >>> --no-peep : Disables the peephole optimizer. When there's a problem that >>> goes away when using --no-peep it's most likely a bug in the peephole >>> optimizer or the peephole rules. > > I recommend to use this early in testing: Peephole rule bugs seem > relatively common and tend to be easy to track down and fix. > > There's --oldralloc now as well, which uses the old register allocator. > This is probably useful to track problems down to a single source file. > > Philipp > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Sdcc-user mailing list > Sdcc-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sdcc-user ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
