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
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
1D20 1A88 4641 4FEE 46E3 4F9D 5090 44E7 56C2 1AB8 // gp2266 sip
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?
----- Original Message -----
From: "Philipp Klaus Krause" <pkk@...>
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
>> Core2 Duo CPU T5800@... 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
>> 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
>> since the compile time is so long right now, I'd like to ask if there is
>> option update before I start.
>> ----- Original Message -----
>> From: "Philipp Klaus Krause" <pkk@...>
>> To: "Sdcc-User" <sdcc-user@...>
>> Cc: <z88dk-developers@...>
>> 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
>>> 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
>>> 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
>>> 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
>>> --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.
> 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.
> Sdcc-user mailing list