Am 03.07.2018 um 11:00 schrieb Philipp Klaus Krause: > Sincce I wondered how SDCC compares to other compilers, I did a quick > comparison of current compilers using Dhrystone on a C8051F120. I tried > to configure all compilers for the equivalent of the SDCC large memory > model, and enabled all optimizations except inlining. > > It turned out that for all compilers, there was not much of a difference > between optimizing for speed vs. optimizing for size, so I'll only > report the results when optimizing for speed. > > What mattered, however, was reentrancy (i.e. --stack-auto for SDCC), so > results with reentrancy are marked as (r). > > SDCC: 6613 Dhrystones / s, 10604 Bytes. > SDCC (r): 5973 Dhrystones / s, 12886 Bytes. > IAR (r): 10865 Dhrystones / 2, 10608 Bytes. > Keil: 12230 Dhrystones / s, 8838 Bytes. > Raisonance: 9711 Dhrystones / s, 9096 Bytes. > Raisonance (r): 10865 Dhrystones / s, 9736 Bytes. > > Philipp > > P.S.: I would have also wanted to report stdcbench results. But Keil > doesn't seem to have a global switch for reentrancy (stdcbench uses > recursion). For Raisonance, there seems to be no working way of > disabling the extended keywords, which conflict with stdcbench variable > names.
While SDCC seems to perform worst in terms of performance and code size, at a second look those numbers are not that bad: * Looking at the generated code, mostly the code generated by SDCC is on par or slightly better or worse than that of the other compilers. However, some other compilers place all data in XRAM, including string literals. That means they can generate more efficient code by assuming that any pointer can be accessed via dptr. But it comes at a substantial proce in RAM usage. SDCC uses code memory for constants, saving RAM at the expense of generating more complicated code. IMO, SDCC makes a reasonable trade-off here. * We only need to get code size down by about 10% to 20% to be competitive in code size. * Implementing few RFE (#574, #575, #576, #577) could do a lot to close the gap. * Dhrystone uses the string functions a lot, so the other compilers probably profit a lot from hand-optimized string functions (for the stm8 backend, SDCC went from lowest to highest Dhrystone scores, once it got hand-optimized string functions). * At least SDCC is on par with (IAR) or far ahead of (Raisonance, Keil) other compilers in standard compliance. Philipp ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
