SDCC Compiler User Guide

SDCC Compiler User Guide

Chapter 6


Here are a few guidelines that will help the compiler generate more efficient code, some of the tips are specific to this compiler others are generally good programming practice.

• Use the smallest data type to represent your data-value. If it is known in advance that the value is going to be less than 256 then use an ’unsigned char’ instead of a ’short’ or ’int’. Please note, that ANSI C requires both signed and unsigned chars to be promoted to ’signed int’ before doing any operation. This promotion can be omitted, if the result is the same. The effect of the promotion rules together with the sign-extension is often surprising: unsigned char uc = 0xfe; if (uc * uc < 0) /* this is true!




} uc * uc is evaluated as (int) uc * (int) uc = (int) 0xfe * (int) 0xfe = (int) 0xfc04 =



Another one:

(unsigned char) -12 / (signed char) -3 = ...

No, the result is not 4:

(int) (unsigned char) -12 / (int) (signed char) -3 =

(int) (unsigned char) 0xf4 / (int) (signed char) 0xfd =

(int) 0x00f4 / (int) 0xfffd =

(int) 0x00f4 / (int) 0xfffd =

(int) 244 / (int) -3 =

(int) -81 = (int) 0xffaf;

Don’t complain, that gcc gives you a different result. gcc uses 32 bit ints, while SDCC uses 16 bit ints.

Therefore the results are different.

From ”comp.lang.c FAQ”:

If well-defined overflow characteristics are important and negative values are not, or if you want to steer clear of sign-extension problems when manipulating bits or bytes, use one of the corresponding unsigned types. (Beware when mixing signed and unsigned values in expressions, though.)

Although character types (especially unsigned char) can be used as "tiny" integers, doing so is sometimes more trouble than it’s worth, due to unpredictable sign extension and increased code size.

• Use unsigned when it is known in advance that the value is not going to be negative. This helps especially if you are doing division or multiplication, bit-shifting or are using an array index.



• NEVER jump into a LOOP.

• Declare the variables to be local whenever possible, especially loop control variables (induction).

• Since the compiler does not always do implicit integral promotion, the programmer should do an explicit cast when integral promotion is required.

• Reducing the size of division, multiplication & modulus operations can reduce code size substantially. Take the following code for example.

foobar(unsigned int p1, unsigned char ch)

{ unsigned char ch1 = p1 % ch ;



For the modulus operation the variable ch will be promoted to unsigned int first then the modulus operation will be performed (this will lead to a call to support routine _moduint()), and the result will be casted to a char. If the code is changed to foobar(unsigned int p1, unsigned char ch)

{ unsigned char ch1 = (unsigned char)p1 % ch ;



It would substantially reduce the code generated (future versions of the compiler will be smart enough to detect such optimization opportunities).

• Have a look at the assembly listing to get a ”feeling” for the code generation.


Tools included in the distribution

Name uCsim


as-gbz80 as-z80 asx8051 sdcdb aslink link-z80 link-gbz80 packihx

Purpose Directory

Simulator for various architectures sdcc/sim/ucsim header file conversion sdcc/support/scripts header file conversion

Assembler sdcc/support/scripts sdcc/bin



Simulator sdcc/bin sdcc/bin sdcc/bin



Linker ihx packer sdcc/bin sdcc/bin sdcc/bin sdcc/bin


Documentation included in the distribution

Subject / Title Where to get / filename

SDCC Compiler User Guide

Changelog of SDCC

You’re reading it right now sdcc/Changelog

ASXXXX Assemblers and ASLINK Relocating Linker sdcc/as/doc/asxhtm.html

SDCC regression test sdcc/doc/test_suite_spec.pdf

Various notes

Notes on debugging with sdcdb

Software simulator for microcontrollers

Temporary notes on the pic16 port sdcc/doc/* sdcc/debugger/README sdcc/sim/ucsim/doc/index.html


SDCC internal documentation (debugging file format) sdcc/doc/cdbfileformat.pdf




Related open source tools

Name Purpose gpsim PIC simulator gputils GNU PIC utilities flP5 PIC programmer indent Formats C source - Master of the white spaces srecord Object file conversion, checksumming, ...

objdump Object file conversion, ...

doxygen Source code documentation system kdevelop IDE (has anyone tried integrating

SDCC & sdcdb? Unix only) splint Statically checks c sources (see



ddd Debugger, serves nicely as GUI to sdcdb (Unix only)

Where to get

Part of binutils (should be there anyway)


Related documentation / recommended reading

Name Subject / Title c-refcard.pdf

C Reference Card, 2 pages c-faq C-FAQ-list

Latest datasheet of the target CPU

Revision history of datasheet

S. S. Muchnick Advanced Compiler Design and


Where to get

vendor vendor bookstore (very dedicated, probably read other books first)


Some Questions

Some questions answered, some pointers given - it might be time to in turn ask you some questions:

• can you solve your project with the selected microcontroller? Would you find out early or rather late that your target is too small/slow/whatever? Can you switch to a slightly better device if it doesn’t fit?

• should you solve the problem with an 8 bit CPU? Or would a 16/32 bit CPU and/or another programming language be more adequate? Would an operating system on the target device help?

• if you solved the problem, will the marketing department be happy?

• if the marketing department is happy, will customers be happy?

• if you’re the project manager, marketing department and maybe even the customer in one person, have you tried to see the project from the outside?

• is the project done if you think it is done? Or is just that other interface/protocol/feature/configuration/option missing? How about website, manual(s), internationali(z|s)ation, packaging, labels, 2nd source for components, electromagnetic compatability/interference, documentation for production, production test software, update mechanism, patent issues?

• is your project adequately positioned in that magic triangle: fame, fortune, fun?

Maybe not all answers to these questions are known and some answers may even be no, nevertheless knowing these

questions may help you to avoid burnout


. Chances are you didn’t want to hear some of them...

1 burnout is bad for electronic devices, programmers and motorcycle tyres


Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF


Table of contents