Sdccman
Sdccman
Sdccman
SDCC 4.2.2
$Date:: 2022-05-02 #$
$Revision: 13425 $
Contents
1 Introduction 7
1.1 About SDCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 SDCC Suite Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Typographic conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Compatibility with previous versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.7 Other Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Installing SDCC 13
2.1 Configure Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Install paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Search Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Building SDCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.1 Building SDCC on Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.2 Building SDCC on Mac OS X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.3 Cross compiling SDCC on Linux for Windows . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.4 Building SDCC using Cygwin and Mingw32 . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.5 Building SDCC Using Microsoft Visual C++ 2010 (MSVC) . . . . . . . . . . . . . . . . 20
2.4.6 Windows Install Using a ZIP Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.7 Windows Install Using the Setup Program . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.8 VPATH feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5 Building the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6 Reading the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.7 Testing the SDCC Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.8 Install Trouble-shooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.8.1 If SDCC does not build correctly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.8.2 What the ”./configure” does . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.8.3 What the ”make” does . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.8.4 What the ”make install” command does. . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.9 Components of SDCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.9.1 sdcc - The Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.9.2 sdcpp - The C-Preprocessor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.9.3 sdas, sdld - The Assemblers and Linkage Editors . . . . . . . . . . . . . . . . . . . . . . 25
2.9.4 s51, sz80, shc08, sstm8 - The Simulators . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.9.5 sdcdb - Source Level Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3 Using SDCC 26
3.1 Standard-Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.1 ISO C90 and ANSI C89 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.2 ISO C95 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.3 ISO C99 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.4 ISO C11 and ISO C17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.5 ISO C2X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.6 Embedded C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1
CONTENTS CONTENTS
2
CONTENTS CONTENTS
3
CONTENTS CONTENTS
4
CONTENTS CONTENTS
5 Debugging 94
5.1 Debugging with SDCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.1.1 Compiling for Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.1.2 How the Debugger Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.1.3 Starting the Debugger SDCDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.1.4 SDCDB Command Line Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.1.5 SDCDB Debugger Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.1.6 Interfacing SDCDB with DDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.1.7 Interfacing SDCDB with XEmacs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.2 Debugging with other debuggers (e.g. GDB): ELF / DWARF . . . . . . . . . . . . . . . . . . . . 99
6 TIPS 100
6.1 Porting code from or to other compilers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.2 Tools included in the distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.3 Documentation included in the distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.4 Communication online at SourceForge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.5 Related open source tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.6 Related documentation / recommended reading . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.7 Application notes specifically for SDCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.8 Some Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5
CONTENTS CONTENTS
7 Support 105
7.1 Reporting Bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.2 Requesting Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.3 Submitting patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.4 Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.5 ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.6 Subversion Source Code Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.7 Release policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.8 Quality control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.9 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
7.10 Use of SDCC in Education . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
10 Acknowledgments 126
6
Chapter 1
Introduction
In addition to the MCU specific optimizations SDCC also does a host of standard optimizations like:
• copy propagation,
• dead code elimination
• jump tables for switch statements.
For the back-end SDCC uses a global register allocation scheme which should be well suited for other 8 bit MCUs.
The peep hole optimizer uses a rule based substitution mechanism which is MCU independent.
7
1.2. SDCC SUITE LICENSES CHAPTER 1. INTRODUCTION
SDCC also provides an option (--cyclomatic) to report the relative complexity of a function. These func-
tions can then be further optimized, or hand coded in assembly if needed.
SDCC also comes with a companion source level debugger SDCDB. The debugger currently uses ucSim, a
free open source simulator for 8051 and other micro-controllers.
• executables:
– sdcc compiler:
sdcc compiler is licensed under the GPLv2 (GPLv3 might apply depending on the libraries used when
building).
The code or object files generated by SDCC suite are not licensed, so they can be used in FLOSS or
proprietary (closed source) applications.
– sdcpp preprocessor:
derived from GCC cpp preprocessor http://gcc.gnu.org/; GPLv3 license
– sdas assemblers and sdld linker:
derived from ASXXXX https://shop-pdp.net/ashtml/; GPLv3 license
– SDCC run-time libraries:
The great majority of SDCC run-time libraries are licensed under the GPLv2+LE which allows linking
of SDCC run-time libraries with proprietary (closed source) applications.
A possible exception are pic device libraries and header files which are generated from Microchip
header (.inc) and linker script (.lkr) files. Microchip requires that "The header files should state that
they are only to be used with authentic Microchip devices" which makes them incompatible with the
GPL, if Microchip has any copyright in them (which might depend on local copyright laws). Pic device
libraries and header files are located at non-free/lib and non-free/include directories respectively. SDCC
should be run with the --use-non-free command line option in order to include non-free header files and
libraries.
– sdbinutils utilities (sdar, sdranlib, sdnm, sdobjcopy):
derived from GNU Binutils http://www.gnu.org/software/binutils/; GPLv3 license
1 Incomplete support in the pic14 and pic16 backends.
2 Only supported in the mcs51, ds390, ds400 backends.
3 Obviously this has pros and cons
8
1.3. DOCUMENTATION CHAPTER 1. INTRODUCTION
– ucsim simulators:
GPLv2 license
– sdcdb debugger:
GPLv2 license
– gcc-test regression tests:
derived from gcc-testsuite; no license explicitely specified, but since it is a part of GCC is probably
GPLv3 licensed
– packihx:
public domain
– makebin:
zlib/libpng License
– pic libraries in device/non-free:
Microchip Technology Inc. claims to have copyrights on this, and their term are non-free. However,
a more common opinion is that Microchip Technology Inc. is just claiming a copyright on uncopy-
rightable facts.
• libraries:
– dbuf library:
zlib/libpng License
– Boost C++ libraries:
http://www.boost.org/; Boost Software License 1.0 (BSL-1.0)
Links to licenses:
• GPLv2 license: http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
• LGPLv2.1 license: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html
• GPLv3 license: http://www.gnu.org/licenses/gpl.html
• zlib/libpng License: http://www.opensource.org/licenses/Zlib
• Boost Software License 1.0 (BSL-1.0): http://www.opensource.org/licenses/BSL-1.0
1.3 Documentation
This documentation is maintained using a free open source word processor (LYX) http://www.lyx.org/.
9
1.5. COMPATIBILITY WITH PREVIOUS VERSIONS CHAPTER 1. INTRODUCTION
• char type parameters to vararg functions are casted to int unless explicitly casted and neither of the --std-c89,
--std-c99, --std-c11 or --std-c2x command line options is used, e.g.:
char a=3;
printf ("%d %c\n", a, (char)a);
will push a as an int and as a char resp if none of the above command line options are not defined,
will push a as two ints if none of the above command line option is defined.
• pointer type parameters to vararg functions are casted to generic pointers on Harvard architectures (e.g.
mcs51, ds390) unless explicitly casted and neither of the --std-c89, --std-c99, --std-c11 or --std-c2x com-
mand line options is used.
• option --regextend has been removed.
• option --noregparms has been removed.
• option --stack-after-data has been removed.
• __bit and __sbit types now consistently behave like the C99 _Bool type with respect to type conversion. The
most common incompatibility resulting from this change is related to bit toggling idioms, e.g.:
__bit b;
b = ~b; /* equivalent to b=1 instead of toggling b */
b = !b; /* toggles b */
In previous versions, both forms would have toggled the bit.
• in older versions, the preprocessor was always called with --std-c99 regardless of the --std-xxx setting. This
is no longer true, and can cause compilation failures on code built with --std-c89 but using c99 preprocessor
features, such as one-line (//) comments
• in versions older than 2.8.4 the pic16 *printf() and printf_tiny() library functions supported undocumented
and not standard compliant ’b’ binary format specifier ("%b", "%hb" and "%lb"). The ’b’ specifier
is now disabled by default. It can be enabled by defining BINARY_SPECIFIER macro in files de-
vice/lib/pic16/libc/stdio/vfprintf.c and device/lib/pic16/libc/stdio/printf_tiny.c and recompiling the library.
• in versions older then 2.8.5 the unnamed bit-field structure members participated in initialization, which is
not conforming with ISO/IEC 9899:1999 standard (see section Section 6.7.8 Initialization, clause 9)
New behaviour:
struct {
int a : 2;
char : 2;
int b : 2;
} s = {1, 2};
/* s.a = 1, s.b = 2 */
• In 2.9.0 libraries included in SDCC packages, are in ar format. See section 3.2.5.
• In 3.0.0 targets for xa51 and avr are disabled by default.
• In 3.0.0 sdldgb and sdldz80 don’t support generation of Game Boy binary image format. The makebin utility
can be used to convert Intel Hex format to Game Boy binary image format.
• In 3.0.0 sdldgb and sdldz80 don’t support generation of rrgb (Game Boy simulator) map file and no$gmb
symbol file formats. The as2gbmap utility can be used to convert sdld map format to rrgb and no$gmb file
formats.
10
1.5. COMPATIBILITY WITH PREVIOUS VERSIONS CHAPTER 1. INTRODUCTION
• In 3.2.0 new compiler macros for processor definition were introduced for pic14 and pic16 targets:
-D__SDCC_PIC16XXXX and -D__SDCC_PIC18FXXX respectively. The pic16 macro definition
-D__18fXXX is deprecated. It was obsoleted (removed) after the 3.4.0 release.
• In 3.2.0 pragma config for pic16 target was introduced. See section 4.7.6
• In 3.7.0, the prototype for getchar() changed from char getchar(void) to int getchar(void).
• In 3.8.6, the deprecated sdcclib was removed.
• In 4.0.3, _itoa, _uitoa, _ltoa, _ultoa were renamed to __itoa, __uitoa, __ltoa, __ultoa.
• In 4.1.11, the minimum Z80N Core version for the z80n port has been raised from 1.0 to 2.0.
• In 4.1.12, the default calling convention switched from __sdccall(0) to __sdccall(1) for z80, z180 and z80n.
• In 4.1.12, support for –profile has been removed for z80, z180, z80n.
• In 4.1.13, support for –profile has been removed.
11
1.6. SYSTEM REQUIREMENTS CHAPTER 1. INTRODUCTION
12
Chapter 2
Installing SDCC
For most users it is sufficient to skip to either section 2.4.1 (Unix) or section 2.4.7 (Windows). More detailed
instructions follow below.
13
2.1. CONFIGURE OPTIONS CHAPTER 2. INSTALLING SDCC
These configure options are compiled into the binaries, and can only be changed by rerunning ’configure’
and recompiling SDCC. The configure options are written in italics to distinguish them from run time environment
variables (see section search paths).
The settings for ”Win32 builds” are used by the SDCC team to build the official Win32 binaries. The
SDCC team uses Mingw32 to build the official Windows binaries, because it’s
1. open source,
2. a gcc compiler and last but not least
3. the binaries can be built by cross compiling on SDCC Distributed Compile Farm.
See the examples, how to pass the Win32 settings to ’configure’. The other Win32 builds using VC or whatever
don’t use ’configure’, but a header file sdcc_vc.h.in is the same as sdccconf.h built by ’configure’ for Win32.
14
2.2. INSTALL PATHS CHAPTER 2. INSTALLING SDCC
’configure’ also computes relative paths. This is needed for full relocatability of a binary package and to complete
search paths (see section search paths below):
Examples:
./configure
./configure --prefix=”/usr/bin” --datarootdir=”/usr/share”
./configure --disable-avr-port --disable-xa51-port
./configure \
CC=”i586-mingw32msvc-gcc” CXX=”i586-mingw32msvc-g++” \
RANLIB=”i586-mingw32msvc-ranlib” \
STRIP=”i586-mingw32msvc-strip” \
--prefix=”/sdcc” \
--datarootdir=”/sdcc” \
docdir=”\${datarootdir}/doc” \
include_dir_suffix=”include” \
non_free_include_dir_suffix=”non-free/include” \
lib_dir_suffix=”lib” \
non_free_lib_dir_suffix=”non-free/lib” \
sdccconf_h_dir_separator=”\\\\” \
--disable-device-lib\
--host=i586-mingw32msvc\
--build=unknown-unknown-linux-gnu
./configure -C \
--prefix=”/sdcc” \
--datarootdir=”/sdcc” \
docdir=”\${datarootdir}/doc” \
include_dir_suffix=”include” \
non_free_include_dir_suffix=”non-free/include” \
lib_dir_suffix=”lib” \
non_free_lib_dir_suffix=”non-free/lib” \
sdccconf_h_dir_separator=”\\\\” \
CC=”gcc -mno-cygwin” \
CXX=”g++ -mno-cygwin”
’configure’ is quite slow on Cygwin (at least on windows before Win2000/XP). The option ’--C’ turns on caching,
which gives a little bit extra speed. However if options are changed, it can be necessary to delete the config.cache
file.
15
2.3. SEARCH PATHS CHAPTER 2. INSTALLING SDCC
The install paths can still be changed during ‘make install’ with e.g.:
Of course this doesn’t change the search paths compiled into the binaries.
2. Include files
16
2.3. SEARCH PATHS CHAPTER 2. INSTALLING SDCC
The option --nostdinc disables all search paths except #1 and #2.
3. Library files
With the exception of ”--L dir” the model is auto-appended by the compiler (e.g. small, large, z80, ds390 etc.).
17
2.4. BUILDING SDCC CHAPTER 2. INSTALLING SDCC
The option --nostdlib disables all search paths except #1 and #2.
5. Type "./configure". This configures the package for compilation on your system. When the treedec library
is available, it should be found and used automatically (improving the compilation time / code quality trade-
off). As of SDCC 3.7.0, the current develop branch from https://github.com/freetdi/tdlib is a suitable version
of treedec.
6. Type "make". All of the source packages will compile, this can take a while.
18
2.4. BUILDING SDCC CHAPTER 2. INSTALLING SDCC
7. Type "make install" as root. This copies the binary executables, the include files, the libraries and the
documentation to the install directories. Proceed with section 2.7.
On Mac OS X 10.2.x it was reported, that the default gcc (version 3.1 20020420 (prerelease)) fails to com-
pile SDCC. Fortunately there’s also gcc 2.9.x installed, which works fine. This compiler can be selected by running
’configure’ with:
Universal (ppc and i386) binaries can be produced on Mac OS X 10.4.x with Xcode. Run ’configure’ with:
./configure \
LDFLAGS="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc" \
CXXFLAGS = "-O2 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc" \
CFLAGS = "-O2 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
On Cygwin a ”native” Win32-binary can be built, which will not need the Cygwin-DLL. For the necessary
’configure’ options see section ’configure options’ or the script ’sdcc/support/scripts/sdcc_cygwin_mingw32’.
• flex
• bison
• gcc ; version 3.x is fine, no need to use the old 2.9x
• man ; not really needed for building SDCC, but you’ll miss it sooner or later
• less ; not really needed for building SDCC, but you’ll miss it sooner or later
• svn ; only if you use Subversion access
19
2.4. BUILDING SDCC CHAPTER 2. INSTALLING SDCC
bash --login -i
Text selected with the mouse is automatically copied to the clipboard, pasting works with shift-insert.
The other good tip is to make sure you have no //c/-style paths anywhere, use /cygdrive/c/ instead. Using //
invokes a network lookup which is very slow. If you think ”cygdrive” is too long, you can change it with e.g.
mount -s -u -c /mnt
SDCC sources use the unix line ending LF. Life is much easier, if you store the source tree on a drive which is
mounted in binary mode. And use an editor which can handle LF-only line endings. Make sure not to commit files
with windows line endings. The tabulator spacing used in the project is 8. Although a tabulator spacing of 8 is a
sensible choice for programmers (it’s a power of 2 and allows to display 8/16 bit signed variables without loosing
columns) the plan is to move towards using only spaces in the source.
Apart from the SDCC sources you also need to have the BOOST libraries installed for MSVC. Get it here
http://www.boost.org/
In order to build SDCC with MSVC you need win32 executables of bison.exe, flex.exe, and gawk.exe. One
good place to get them is here http://unxutils.sourceforge.net
Download the file UnxUtils.zip. Now you have to install the utilities and setup MSVC so it can locate the
required programs. Here there are two alternatives (choose one!):
a) Extract UnxUtils.zip to your C:\ hard disk PRESERVING the original paths, otherwise bison won’t work.
(If you are using WinZip make certain that ’Use folder names’ is selected)
(As a side effect, you get a bunch of Unix utilities that could be useful, such as diff and patch.)
2. A more compact way:
This one avoids extracting a bunch of files you may not use, but requires some extra work:
20
2.4. BUILDING SDCC CHAPTER 2. INSTALLING SDCC
a) Create a directory were to put the tools needed, or use a directory already present. Say for exam-
ple ’C:\util’.
b) Extract ’bison.exe’, ’bison.hairy’, ’bison.simple’, ’flex.exe’, and gawk.exe to such directory WITHOUT
preserving the original paths. (If you are using WinZip make certain that ’Use folder names’ is not selected)
Steps ’c’ and ’d’ are needed because bison requires by default that the files ’bison.simple’ and ’bi-
son.hairy’ reside in some weird Unix directory, ’/usr/local/share/’ I think. So it is necessary to tell bison
where those files are located if they are not in such directory. That is the function of the environment
variables BISON_SIMPLE and BISON_HAIRY.
e) Add ’C:\util’ to VC++ Directories / Executable Directories. Note that you can use any other path
instead of ’C:\util’, even the path where the Visual C++ tools are, probably: ’C:\Program Files\Microsoft
Visual Studio\Common\Tools’. So you don’t have to execute step ’e’ :)
That is it. Open ’sdcc.sln’ in Visual Studio, click ’build all’, when it finishes copy the executables from sdcc\bin_vc
to sdcc\bin, and you can compile using SDCC.
21
2.5. BUILDING THE DOCUMENTATION CHAPTER 2. INSTALLING SDCC
• The installation section and the section about the debugger is intimidating.
• There are still lots of typos and there are more different writing styles than pictures.
Make sure the compiler works on a very simple example. Type in the following test.c program using your
favorite ASCII editor:
1 If you should know why please drop us a note
22
2.8. INSTALL TROUBLE-SHOOTING CHAPTER 2. INSTALLING SDCC
char test;
void main(void) {
test=0;
}
Compile this using the following command: "sdcc -c test.c". If all goes well, the compiler will generate a
test.asm and test.rel file. Congratulations, you’ve just compiled your first program with SDCC. We used the -c
option to tell SDCC not to link the generated code, just to keep things simple for this step.
The next step is to try it with the linker. Type in "sdcc test.c". If all goes well the compiler will link
with the libraries and produce a test.ihx output file. If this step fails (no test.ihx, and the linker generates warnings),
then the problem is most likely that SDCC cannot find the /usr/local/share/sdcc/lib directory (see section 2.8 Install
trouble-shooting for suggestions).
The final test is to ensure SDCC can use the standard header files and libraries. Edit test.c and change it to
the following:
#include <string.h>
char str1[10];
void main(void) {
strcpy(str1, "testing");
}
Compile this by typing "sdcc test.c". This should generate a test.ihx output file, and it should give no warnings
such as not finding the string.h file. If it cannot find the string.h file, then the problem is that SDCC cannot find
the /usr/local/share/sdcc/include directory (see the section 2.8 Install trouble-shooting section for suggestions). Use
option --print-search-dirs to find exactly where SDCC is looking for the include and lib files.
If anything goes wrong, you can review the log files to locate the problem. Or a relevant part of this can
be attached to an email that could be helpful when requesting help from the mailing list.
23
2.9. COMPONENTS OF SDCC CHAPTER 2. INSTALLING SDCC
You might want to look at the files which are installed in <installdir>. At the time of this writing, we find
the following programs for gcc-builds:
In <installdir>/bin:
• sdcc - The compiler.
• sdcpp - The C preprocessor.
• makebin - A tool to convert Intel Hex file to a binary and GameBoy binary image file format.
In <installdir>/share/sdcc/include
• the include files
In <installdir>/share/sdcc/non-free/include
• the non-free include files
In <installdir>/share/sdcc/lib
24
2.9. COMPONENTS OF SDCC CHAPTER 2. INSTALLING SDCC
• the documentation
25
Chapter 3
Using SDCC
3.1 Standard-Compliance
SDCC aims to be a conforming freestanding implementation of the C programming language.
struct s { ... };
struct s foo1 (struct s parms) /* invalid in SDCC although allowed
in ANSI */
{
struct s rets;
...
return rets; /* is invalid in SDCC although allowed in ANSI
*/
}
• ’double’ precision floating point not supported. Instead a warning is emitted, and float is used instead. long
double is not supported.
26
3.1. STANDARD-COMPLIANCE CHAPTER 3. USING SDCC
• Functions are not reentrant unless explicitly declared as such or --stack-auto is specified in the mcs51,
ds390, hc08, s08, pdk13, pdk14, pdk15 and mos6502 ports.
• struct and union can not be used as parameters or return values in the hc08, s08, ds390, mos6502, pic14 and
pic16 ports.
• Compound literals.
• Variable-length arrays.
Some features of this standard are not supported in some ports:
• There is no support for data types long long, unsigned long long, int_fast64_t, int_least64_t, int64_t,
uint_fast64_t, uint_least64_t, uint64_t in the pic14 and pic16 ports.
3.1.6 Embedded C
SDCC supports named address spaces. The support for fixed-point math in SDCC is inconsistent with the standard.
Other parts of the standard are not supported.
3.1.7.2 Environment
• See SDCC source (and your own code if you use a custom crt0 for a target that supports it) for any information
on the environment.
3.1.7.3 Identifiers
• See the compiler and assembler source for information on characters that may appear in identifiers and on
the number of significant initial characters.
27
3.1. STANDARD-COMPLIANCE CHAPTER 3. USING SDCC
3.1.7.4 Characters
• There are 8 bits in a byte.
• unsigned char has the same range, representation and behavior as ”plain” char.
• See the SDCC source for further information on character sets.
3.1.7.5 Integers
• There are no extended integer types.
3.1.7.8 Hints
• The extend to which suggestions made by register are effective depends on the target.
• SDCC will inline functions if and only if they are declared using inline and do not have variable arguments.
• There are no allowed bit-field types other than _Bool, signed int and unsigned int.
• Atomic types are not permitted for bit-fields.
• If a bit-fields does not fit into the same byte as the previous bit-fields, it starts on the next byte.
• bit-fields are allocated in the same order as they appear in the source.
• Non-bit-field members of structures are aligned on byte boundaries (i.e. there are no padding bytes).
• For the integer types compatible with enum types see the SDCC source code.
3.1.7.10 Qualifiers
• SDCC shall preserve all volatile reads and writes, but does not guarantee them to be atomic (except for atomic
types and volatile sig_atomic_t).
28
3.2. COMPILING CHAPTER 3. USING SDCC
3.1.7.13 Architecture
• See the respective library headers for the values or expressions for macros specified in float.h, limits.h,
stdint.h.
• Multithreading is not supported.
• The number of bytes in any object is the minimum allowed (except for some padding bits on bit-fields), byte
order depends on the target.
• No extended alignments are supported.
• There are no valid alignments other than those returned by _Alignof.
• sizeof always returns the smallest value allowed assuming an 8-bit char. _Alignof always returns 0.
3.2 Compiling
3.2.1 Single Source File Projects
For single source file 8051 projects the process is very simple. Compile your programs with the following command
"sdcc sourcefile.c". This will compile, assemble and link your source file. Output files are as follows:
• sourcefile.asm - Assembler source file created by the compiler
• sourcefile.lst - Assembler listing file created by the Assembler
• sourcefile.rst - Assembler listing file updated with linkedit information, created by linkage editor
• sourcefile.sym - symbol listing for the sourcefile, created by the assembler
• sourcefile.rel - Object file created by the assembler, input to Linkage editor
• sourcefile.map - The memory map for the load module, created by the Linker
• sourcefile.mem - A file with a summary of the memory usage
• sourcefile.ihx - The load module in Intel hex format (you can select the Motorola S19 format with --out-fmt-
s19. If you need another format you might want to use objdump or srecord - see also section 3.2.2 on the
following page). Both formats are documented in the documentation of srecord
29
3.2. COMPILING CHAPTER 3. USING SDCC
• sourcefile.adb - An intermediate file containing debug information needed to create the .cdb file (with --
debug)
• sourcefile.cdb - An optional file (with --debug) containing debug information. The format is documented in
cdbfileformat.pdf
• sourcefile.omf - An optional AOMF or AOMF51 file containing debug information (generated with option
--debug). The (Intel) absolute object module f ormat is a subformat of the OMF51 format and is commonly
used by third party tools (debuggers, simulators, emulators).
• sourcefile.dump* - Dump file to debug the compiler it self (generated with option --dumpall) (see section
3.3.12 and section 9.1 ”Anatomy of the compiler”).
The separately available srecord package additionally allows to set undefined locations to a predefined value, to
insert checksums of various flavours (crc, add, xor) and to perform other manipulations (convert, split, crop, offset,
...).
srec_cat sourcefile.ihx -intel -fill 0x12 0x0000 0xfffe -little-endian-checksum-negative 0xfffe 0x02 0x02 -o source-
file.hex -intel
The first two files will need to be compiled separately with the commands:
sdcc -c foo1.c
sdcc -c foo2.c
Then compile the source file containing the main() function and link the files together with the following command:
sdcc -c foomain.c
1 the command backfills unused memory with 0x12 and the overall 16 bit sum of the complete 64 kByte block is zero. If the program counter
on an mcs51 runs wild the backfill pattern 0x12 will be interpreted as an lcall to address 0x1212 (where an emergency routine could sit).
30
3.3. COMMAND LINE OPTIONS CHAPTER 3. USING SDCC
The file containing the main() function MUST be the FIRST file specified in the command line, since the
linkage editor processes file in the order they are presented to it. The linker is invoked from SDCC using a script
file with extension .lnk. You can view this file to troubleshoot linking problems such as those arising from missing
libraries.
The most efficient way to use libraries is to keep separate modules in separate source files. The lib file
now should name all the modules.rel files. For an example see the standard library file libsdcc.lib in the directory
<installdir>/share/lib/small.
Both the GNU and BSD ar format variants are supported by sdld linkers.
To create a library containing sdas object files, you should use the following sequence:
31
3.3. COMMAND LINE OPTIONS CHAPTER 3. USING SDCC
-mez80_z80 Generate code for the Zilog eZ80 processor in Z80 mode.
-mstm8 Generate code for the STMicroelectronics STM8 family of processors.
-mpdk13 Generate code for Padauk processors with 13 bit wide program memory.
-mpdk14 Generate code for Padauk processors with 14 bit wide program memory.
-mpdk15 Generate code for Padauk processors with 15 bit wide program memory.
-mpic14 Generate code for the Microchip PIC 14-bit processors (p16f84 and variants. In development, not
complete).
-mpic16 Generate code for the Microchip PIC 16-bit processors (p18f452 and variants. In development, not
complete).
SDCC inspects the program name it was called with so the processor family can also be selected by renaming the
sdcc binary (to f.e. z80-sdcc) or by calling SDCC from a suitable link. Option -m has higher priority than setting
from program name.
-MM Like ‘-M’ but the output mentions only the user header files included with ‘#include “file"’. System
header files included with ‘#include <file>’ are omitted.
-Aquestion(answer) Assert the answer answer for question, in case it is tested with a preprocessor conditional
such as ‘#if #question(answer)’. ‘-A-’ disables the standard assertions that normally describe the target
machine.
-Umacro Undefine macro macro. ‘-U’ options are evaluated after all ‘-D’ options, but before any ‘-include’ and
‘-imacros’ options.
-dM Tell the preprocessor to output only a list of the macro definitions that are in effect at the end of
preprocessing. Used with the ‘-E’ option.
-dD Tell the preprocessor to pass all macro definitions into the output, in their proper sequence in the rest
of the output.
-dN Like ‘-dD’ except that the macro arguments and contents are omitted. Only ‘#define name’ is included
in the output.
-pedantic-parse-number Pedantic parse numbers so that situations like 0xfe-LO_B(3) are parsed properly and the
macro LO_B(3) gets expanded. See also #pragma pedantic_parse_number on page 61 in section3.16
Note: this functionality is not in conformance with C99 standard!
-Wp preprocessorOption[,preprocessorOption]... Pass the preprocessorOption to the preprocessor sdcpp.
32
3.3. COMMAND LINE OPTIONS CHAPTER 3. USING SDCC
--peep-file <filename> This option can be used to use additional rules to be used by the peep hole optimizer. See
section 8.1.16 Peep Hole optimizations for details on how to write these rules.
--peep-asm Pass the inline assembler code through the peep hole optimizer. This can cause unexpected changes
to inline assembler code, please go through the peephole optimizer rules defined in the source file tree
’<target>/peeph.def’ before using this option.
--peep-return Let the peep hole optimizer do return optimizations. This is the default without --debug.
--no-peep-return Do not let the peep hole optimizer do return optimizations. This is the default with --debug.
--opt-code-speed The compiler will optimize code generation towards fast code, possibly at the expense of code
size.
--opt-code-size The compiler will optimize code generation towards compact code, possibly at the expense of code
speed.
--fomit-frame-pointer Frame pointer will be omitted when the function uses no local variables. On the z80-related
ports this option will result in the frame pointer always being omitted.
--max-allocs-per-node Setting this to a high value will result in increased compilation time (and increased memory
use during compilation) and more optimized code being generated. Setting it to lower values speeds
up compilation, but does not optimize as much. The default value is 3000. This option currently does
not affect the mcs51, ds390, pic14 and pic16 ports.
--nolospre Disable lospre. lospre is an advanced redundancy elimination technique, essentially an improved vari-
ant of global subexpression elimination.
--allow-unsafe-read Allow optimizations to generate unsafe reads. This will enable additional optimizations, but
can result in spurious reads from undefined memory addresses, which can be harmful if the target
system uses certain ways of doing memory-mapped I/O.
33
3.3. COMMAND LINE OPTIONS CHAPTER 3. USING SDCC
34
3.3. COMMAND LINE OPTIONS CHAPTER 3. USING SDCC
--fsigned-char By default char is unsigned. To set the signess for characters to signed, use the option --fsigned-
char. If this option is set and no signedness keyword (unsigned/signed) is given, a char will be unsigned.
All other types are unaffected.
--nostdinc This will prevent the compiler from passing on the default include path to the preprocessor.
--nostdlib This will prevent the compiler from passing on the default library path to the linker.
--no-peep-comments Don’t include peep-hole comments in the generated asm files even if --fverbose-asm option
is specified.
--i-code-in-asm Include i-codes in the asm file. Sounds like noise but is helpful for debugging the compiler itself.
--less-pedantic Disable some of the more pedantic warnings. For more details, see the less_pedantic pragma on
page 60.
--disable-warning <nnnn> Disable specific warning with number <nnnn>.
--Werror Treat all warnings as errors.
-Wa asmOption[,asmOption]... Pass the asmOption to the assembler. See file sdcc/sdas/doc/asmlnk.txt for as-
sembler options.cd
--std-sdcc89 Generally follow the ANSI C89 / ISO C90 standard, but allow some SDCC behaviour that conflicts
with the standard.
--std-sdcc11 Generally follow the ISO C11 standard, but allow some SDCC behaviour that conflicts with the
standard (default).
--std-c11 Follow the ISO C11 standard.
--std-sdcc2x Generally follow the ISO C2X standard, but allow some SDCC behaviour that conflicts with the
standard (default).
--std-c2x Follow the ISO C2X standard.
--codeseg <Name> The name to be used for the code segment, default CSEG. This is useful if you need to tell the
compiler to put the code in a special segment so you can later on tell the linker to put this segment in
a special place in memory. Can be used for instance when using bank switching to put the code in a
bank.
35
3.3. COMMAND LINE OPTIONS CHAPTER 3. USING SDCC
--constseg <Name> The name to be used for the const segment, default CONST. This is useful if you need to tell
the compiler to put the const data in a special segment so you can later on tell the linker to put this
segment in a special place in memory. Can be used for instance when using bank switching to put the
const data in a bank.
--fdollars-in-identifiers Permit ’$’ as an identifier character.
--more-pedantic Actually this is not a SDCC compiler option but if you want more warnings you can use a sepa-
rate tool dedicated to syntax checking like splint http://www.splint.org. To make your source
files parseable by splint you will have to include lint.h in your source file and add brackets around ex-
tended keywords (like ”__at (0xab)” and ”__interrupt (2)”).
Splint has an excellent on line manual at http://www.splint.org/manual/ and it’s capabili-
ties go beyond pure syntax checking. You’ll need to tell splint the location of SDCC’s include files so
a typical command line could look like this:
splint -I /usr/local/share/sdcc/include/mcs51/ myprogram.c
--use-non-free Search / include non-free licensed libraries and header files, located under the non-free directory -
see section 2.3
--code-loc <Value> The start location of the code segment, default value 0. Note when this option is used the
interrupt vector table is also relocated to the given address. The value entered can be in Hexadecimal
or Decimal format, e.g.: --code-loc 0x8000 or --code-loc 32768.
--stack-loc <Value> The value entered can be in Hexadecimal or Decimal format, e.g. --stack-loc 0x20 or --stack-
loc 32.
For stm8, by default the stack is placed at the device-specific reset value. By using this option, the stack
can be placed anywhere in the lower 16-bits of the stm8 memory space. This is particularly useful for
working around the stack roll-over antifeature present in some stm8 devices.
--xstack-loc <Value> By default the external stack is placed after the __pdata segment. Using this option the
xstack can be placed anywhere in the external memory space of the 8051. The value entered can be in
Hexadecimal or Decimal format, e.g. --xstack-loc 0x8000 or --xstack-loc 32768. The provided value
should not overlap any other memory areas such as the pdata or xdata segment and with enough space
for the current application.
--data-loc <Value> The start location of the internal ram data segment. The value entered can be in Hexadecimal
or Decimal format, eg. --data-loc 0x20 or --data-loc 32. (By default, the start location of the internal
ram data segment is set as low as possible in memory, taking into account the used register banks and
the bit segment at address 0x20. For example if register banks 0 and 1 are used without bit variables,
the data segment will be set, if --data-loc is not used, to location 0x10.)
--idata-loc <Value> The start location of the indirectly addressable internal ram of the 8051, default value is 0x80.
The value entered can be in Hexadecimal or Decimal format, eg. --idata-loc 0x88 or --idata-loc 136.
--bit-loc <Value> The start location of the bit addressable internal ram of the 8051. This is not implemented yet.
Instead an option can be passed directly to the linker: -Wl -bBSEG=<Value>.
--out-fmt-ihx The linker output (final object code) is in Intel Hex format. This is the default option. The format
itself is documented in the documentation of srecord.
36
3.3. COMMAND LINE OPTIONS CHAPTER 3. USING SDCC
--out-fmt-s19 The linker output (final object code) is in Motorola S19 format. The format itself is documented in
the documentation of srecord.
--out-fmt-elf The linker output (final object code) is in ELF format. (Currently only supported for the HC08, S08
and STM8 processors). When used with –debug, the debug info is in DWARF format instead of CDB.
-Wl linkOption[,linkOption]... Pass the linkOption to the linker. If a bootloader is used an option like ”-Wl -
bCSEG=0x1000” would be typical to set the start of the code segment. Either use the double quotes
around this option or use no space (e.g. -Wl-bCSEG=0x1000). See also #pragma constseg and
#pragma codeseg in section3.16. File sdcc/sdas/doc/asmlnk.txt has more on linker options.
37
3.3. COMMAND LINE OPTIONS CHAPTER 3. USING SDCC
principle, this should work with the --stack-auto option, but that has not been tested. It is incompatible
with the --xstack option. It also only makes sense if the processor is in 24 bit contiguous addressing
mode (see the --model-flat24 option).
--stack-probe insert call to function __stack_probe at each function prologue.
--tini-libid <nnnn> LibraryID used in -mTININative.
--use-accelerator generate code for DS390 Arithmetic Accelerator.
3.3.8 Options common to all z80-related ports (z80, z180, r2k, r3ka, sm83, tlcs90,
ez80_z80)
--no-std-crt0 When linking, skip the standard crt0.rel object file. You must provide your own crt0.rel for your
system when linking.
--callee-saves-bc Force a called function to always save BC.
--codeseg <Value> Use <Value> for the code segment name.
--constseg <Value> Use <Value> for the const segment name.
3.3.9 Z80 Options (apply to z80, z180, r2k, r3ka, tlcs90, ez80_z80)
--portmode=<Value> Determinate PORT I/O mode (<Value> is z80 or z180).
--asm=<Value> Define assembler name (<Value> is rgbds, sdasz80, isas or z80asm).
--reserve-regs-iy This option tells the compiler that it is not allowed to use register pair iy. The option can be useful
for systems where iy is reserved for the OS. This option is incompatible with --fomit-frame-pointer.
--fno-omit-frame-pointer Never omit the frame pointer.
38
3.4. ENVIRONMENT VARIABLES CHAPTER 3. USING SDCC
SDCC_LEAVE_SIGNALS SDCC installs a signal handler to be able to delete temporary files after an user break
(^C) or an exception. If this environment variable is set, SDCC won’t install the signal handler in order
to be able to debug SDCC.
TMP, TEMP, TMPDIR Path, where temporary files will be created. The order of the variables is the search order.
In a standard *nix environment these variables are not set, and there’s no need to set them. On Windows
it’s recommended to set one of them.
SDCC_HOME Path, see section 2.2 ” Install Paths”.
SDCC_INCLUDE Path, see section 2.3 ”Search Paths”.
39
3.5. SDCC LANGUAGE EXTENSIONS CHAPTER 3. USING SDCC
3.5.1.3 __idata
Variables in this address space will be allocated into the indirectly addressable portion of the internal ram of a 8051,
e.g.:
__idata unsigned char test_idata;
Writing 0x01 to this variable generates the assembly code:
3.5.1.4 __pdata
Paged xdata access is just as straightforward as using the other addressing modes of a 8051. It is typically located
at the start of xdata and has a maximum size of 256 bytes. The following example writes 0x01 to the pdata variable.
Please note, pdata access physically accesses xdata memory. The high byte of the address is determined by port
P2 (or in case of some 8051 variants by a separate Special Function Register, see section 4.1). This is the default
(generic) address space for the Medium Memory model, e.g.:
__pdata unsigned char test_pdata;
Writing 0x01 to this variable generates the assembly code:
78r00 mov r0,#_test_pdata
74 01 mov a,#0x01
F2 movx @r0,a
If the --xstack option is used the pdata memory area is followed by the xstack memory area and the sum of their
sizes is limited to 256 bytes.
40
3.5. SDCC LANGUAGE EXTENSIONS CHAPTER 3. USING SDCC
3.5.1.5 __code
’Variables’ in this address space will be placed in the code memory:
__code unsigned char test_code;
Read access to this variable generates the assembly code:
90s00r6F mov dptr,#_test_code
E4 clr a
93 movc a,@a+dptr
char indexed arrays of characters in code memory can be accessed efficiently:
__code char test_array[] = {’c’,’h’,’e’,’a’,’p’};
Read access to this array using an 8-bit unsigned index generates the assembly code:
E5*00 mov a,_index
90s00r41 mov dptr,#_test_array
93 movc a,@a+dptr
3.5.1.6 __bit
This is a data-type and an address space. When a variable is declared as a bit, it is allocated into the bit addressable
memory of 8051, e.g.:
__bit test_bit;
Writing 1 to this variable generates the assembly code:
D2*00 setb _test_bit
The bit addressable memory consists of 128 bits which are located from 0x20 to 0x2f in data memory.
Apart from this 8051 specific intrinsic named address space most architectures support ANSI-C bit-fields3 . In
accordance with ISO/IEC 9899 bits and bitfields without an explicit signed modifier are implemented as unsigned.
Please note, if you use a header file which was written for another compiler then the __sfr / __sfr16 / __sfr32
/ __sbit intrinsic named address spaces will most likely be not compatible. Specifically the syntax sfr P0 =
0x80; is compiled without warning by SDCC to an assignment of 0x80 to a variable called P0. Nevertheless
with the file compiler.h it is possible to write header files which can be shared among different compilers
(see section 6.1).
3 Not really meant as examples, but nevertheless showing what bit-fields are about: device/include/mc68hc908qy.h and sup-
port/regression/tests/bitfields.c
41
3.5. SDCC LANGUAGE EXTENSIONS CHAPTER 3. USING SDCC
All unqualified pointers are treated as 3-byte (4-byte for the ds390) generic pointers.
The highest order byte of the generic pointers contains the data space information. Assembler support rou-
tines are called whenever data is stored or retrieved using generic pointers. These are useful for developing
reusable library routines. Explicitly specifying the pointer type will generate the most efficient code.
Additionally some members of the MCS51 family may have up to 128 bytes of additional, indirectly address-
able, internal RAM memory (__idata). Furthermore, some chips may have some built in external memory (__xdata)
which should not be confused with the internal, directly addressable RAM memory (__data). Sometimes this built
in __xdata memory has to be activated before using it (you can probably find this information on the datasheet of
the microcontroller your are using, see also section 4.1.4 Startup-Code).
Normally SDCC will only use the first bank of registers (register bank 0), but it is possible to specify that
other banks of registers (keyword __using ) should be used for example in interrupt routines. By default, the
42
3.5. SDCC LANGUAGE EXTENSIONS CHAPTER 3. USING SDCC
compiler will place the stack after the last byte of allocated memory for variables. For example, if the first
2 banks of registers are used, and only four bytes are used for data variables, it will position the base of the
internal stack at address 20 (0x14). This implies that as the stack grows, it will use up the remaining register
banks, and the 16 bytes used by the 128 bit variables, and 80 bytes for general purpose use. If any bit variables
are used, the data variables will be placed in unused register banks and after the byte holding the last bit
variable. For example, if register banks 0 and 1 are used, and there are 9 bit variables (two bytes used), data
variables will be placed starting from address 0x10 to 0x20 and continue at address 0x22. You can also use --data-
loc to specify the start address of the data and --iram-size to specify the size of the total internal RAM (data+idata).
By default the 8051 linker will place the stack after the last byte of (i)data variables. Option --stack-loc allows
you to specify the start of the stack, i.e. you could start it after any data in the general purpose area. If your
microcontroller has additional indirectly addressable internal RAM (idata) you can place the stack on it. You may
also need to use --xdata-loc to set the start address of the external RAM (xdata) and --xram-size to specify its size.
Same goes for the code memory, using --code-loc and --code-size. If in doubt, don’t specify any options and see if
the resulting memory layout is appropriate, then you can adjust it.
The linker generates two files with memory allocation information. The first, with extension .map shows all the
variables and segments. The second with extension .mem shows the final memory layout. The linker will complain
either if memory segments overlap, there is not enough memory, or there is not enough space for stack. If you get
any linking warnings and/or errors related to stack or segments allocation, take a look at either the .map or .mem
files to find out what the problem is. The .mem file may even suggest a solution to the problem.
43
3.5. SDCC LANGUAGE EXTENSIONS CHAPTER 3. USING SDCC
3.5.3.2 __xdata
Variables in the address space__xdata can reside anywhere in memory. This is the default (generic address space).
__sfr __at 0x18 gpcc; /* define a var in I/O space at 18h called
gpcc */
3.5.4.2 __sfr16
The Padauk family has a 16-bit timer accessed with special instructions.
44
3.5. SDCC LANGUAGE EXTENSIONS CHAPTER 3. USING SDCC
45
3.6. PARAMETERS AND LOCAL VARIABLES CHAPTER 3. USING SDCC
3.5.10 Omitting promotion on arguments of vararg function (does not apply to pdk13,
pdk14, pdk15)
Arguments to vararg functions are not promoted when explicitly cast. This feature is only enabled when the com-
piler is invoked using --std-sdccxx. This breaks compability with the C standards, so linking code compiled
with --std-sdccxx with code compiled using --std-cxx can result in failing programs when arguments to
vararg functions are explicitly cast. Note: xx is a placeholder for the desired version of the C standard.
They can be placed on the stack by using the --stack-auto option, by using #pragma stackauto or by using
the __reentrant keyword in the function declaration, e.g.:
unsigned char foo(char i) __reentrant
{
...
}
Since stack space on 8051 is limited, and accessing the stack is slow for the Padauk, the __reentrant keyword or
the --stack-auto option should be used sparingly. Note that the __reentrant keyword just means that the parameters
& local variables will be allocated to the stack, it does not mean that the function is register bank independent.
Local variables can be assigned intrinsic named address spaces and absolute addresses, e.g.:
46
3.7. OVERLAYING CHAPTER 3. USING SDCC
3.7 Overlaying
For non-reentrant functions SDCC will try to reduce internal ram space usage by overlaying parameters and local
variables of a function (if possible). Parameters and local variables of a function will be allocated to an overlayable
segment if the function has no other function calls and the function is non-reentrant and the memory model is small.
If an explicit intrinsic named address space is specified for a local variable, it will NOT be overlaid.
Note that the compiler (not the linkage editor) makes the decision for overlaying the data items. Functions that
are called from an interrupt service routine should be preceded by a #pragma nooverlay if they are not reentrant. !
Also note that the compiler does not do any processing of inline assembler code, so the compiler might incor-
rectly assign local variables and parameters of a function into the overlay segment if the inline assembler code calls
other c-functions that might use the overlay. In that case the #pragma nooverlay should be used.
Parameters and local variables of functions that contain 16 or 32 bit multiplication or division will NOT be
overlaid since these are implemented using external functions, e.g.:
#pragma save
#pragma nooverlay
void set_error(unsigned char errcd)
{
P3 = errcd;
}
#pragma restore
In the above example the parameter errcd for the function set_error would be assigned to the overlayable segment
if the #pragma nooverlay was not present, this could cause unpredictable runtime behaviour when called from an
interrupt service routine. The #pragma nooverlay ensures that the parameters and local variables for the function
are NOT overlaid.
47
3.8. INTERRUPT SERVICE ROUTINES CHAPTER 3. USING SDCC
...
}
The optional number following the __interrupt keyword is the interrupt number this routine will service. When
present, the compiler will insert a call to this routine in the interrupt vector table for the interrupt number specified.
If you have multiple source files in your project, interrupt service routines can be present in any of them, but a
prototype of the isr MUST be present or included in the file that contains the function main. The optional (8051
specific) keyword __using can be used to tell the compiler to use the specified register bank when generating code
for this function.
Interrupt service routines open the door for some very interesting bugs:
48
3.8. INTERRUPT SERVICE ROUTINES CHAPTER 3. USING SDCC
If the interrupt service routine is defined without __using a register bank or with register bank 0 (__using 0), the
compiler will save the registers used by itself on the stack upon entry and restore them at exit, however if such an
interrupt service routine calls another function then the entire register bank will be saved on the stack. This scheme
may be advantageous for small interrupt service routines which have low register usage.
If the interrupt service routine is defined to be using a specific register bank then only a, b, dptr & psw are saved
and restored, if such an interrupt service routine calls another function (using another register bank) then the entire
register bank of the called function will be saved on the stack. This scheme is recommended for larger interrupt
service routines.
49
3.9. ENABLING AND DISABLING INTERRUPTS CHAPTER 3. USING SDCC
The critical attribute maybe used with other attributes like reentrant.
The keyword __critical may also be used to disable interrupts more locally:
__critical{ i++; }
More than one statement could have been included in the block.
50
3.10. FUNCTIONS USING PRIVATE REGISTER BANKS (MCS51/DS390) CHAPTER 3. USING SDCC
On other architectures which have separate opcodes for enabling and disabling interrupts you might want to make
use of defines with inline assembly (HC08):
#define CLI __asm cli __endasm;
#define SEI __asm sei __endasm;
or for SDCC version 3.2.0 or newer:
#define CLI asm (”cli”);
#define SEI asm (”sei”);
Note: it is sometimes sufficient to disable only a specific interrupt source like f.e. a timer or serial interrupt by
manipulating an interrupt mask register.
Usually the time during which interrupts are disabled should be kept as short as possible. This minimizes both
interrupt latency (the time between the occurrence of the interrupt and the execution of the first code in the interrupt
routine) and interrupt jitter (the difference between the shortest and the longest interrupt latency). These really are
something different, f.e. a serial interrupt has to be served before its buffer overruns so it cares for the maximum
interrupt latency, whereas it does not care about jitter. On a loudspeaker driven via a digital to analog converter
which is fed by an interrupt a latency of a few milliseconds might be tolerable, whereas a much smaller jitter will
be very audible.
You can re-enable interrupts within an interrupt routine and on some architectures you can make use of two
(or more) levels of interrupt priorities. On some architectures which don’t support interrupt priorities these can
be implemented by manipulating the interrupt mask and re-enabling interrupts within the interrupt routine. Check
there is sufficient space on the stack and don’t add complexity unless you have to.
if (resource_is_free)
{
resource_is_free=0;
...
resource_is_free=1;
}
Note, mcs51 and ds390 support only an atomic bit test and clear instruction (as opposed to atomic bit test and set).
attribute as the calling ’interrupt’ functions. For instance, if you have several ISRs using bank one, and all of them call memcpy(), it might make
sense to create a specialized version of memcpy() ’using 1’, since this would prevent the ISR from having to save bank zero to the stack on entry
and switch to bank zero before calling the function
51
3.11. INLINE ASSEMBLER CODE CHAPTER 3. USING SDCC
An interrupt function using a non-zero bank will assume that it can trash that register bank, and will not save
it. Since high-priority interrupts can interrupt low-priority ones on the 8051 and friends, this means that if a high-
priority ISR using a particular bank occurs while processing a low-priority ISR using the same bank, terrible and
bad things can happen. To prevent this, no single register bank should be used by both a high priority and a low
priority ISR. This is probably most easily done by having all high priority ISRs use one bank and all low priority
ISRs use another. If you have an ISR which can change priority at runtime, you’re on your own: I suggest using
the default bank zero and taking the small performance hit.
It is most efficient if your ISR calls no other functions. If your ISR must call other functions, it is most efficient
if those functions use the same bank as the ISR (see note 1 below); the next best is if the called functions use bank
zero. It is very inefficient to call a function using a different, non-zero bank from an ISR.
If the code snippet (assume it is saved in buffer.c) is compiled with SDCC then a corresponding buffer.asm file is
generated. We define a new function to_buffer_asm() in file buffer.c in which we cut and paste the generated
code, removing unwanted comments and some ’:’. Then add ”__asm” and ”__endasm;”5 to the beginning and the
end of the function body:
5 Note, that the single underscore form (_asm and _endasm) are not C99 compatible, and for C99 compatibility, the double-underscore form
(__asm and __endasm) has to be used. The latter is also used in the library functions.
52
3.11. INLINE ASSEMBLER CODE CHAPTER 3. USING SDCC
/* With a cut and paste from the .asm file, we have something to start with.
The function is not yet OK! (registers aren’t saved) */
void to_buffer_asm( unsigned char c )
{
__asm
mov r2,dpl
;buffer.c if( head != (unsigned char)(tail-1) ) /* cast needed to avoid promotion to
integer */
mov a,_tail
dec a
mov r3,a
mov a,_head
cjne a,ar3,00106$
ret
00106$:
;buffer.c buf[ head++ ] = c; /* access to a 256 byte aligned array */
mov r3,_head
inc _head
mov dpl,r3
mov dph,#(_buf >> 8)
mov a,r2
movx @dptr,a
00103$:
ret
__endasm;
}
The new file buffer.c should compile with only one warning about the unreferenced function argument ’c’. Now
we hand-optimize the assembly code and insert an #define USE_ASSEMBLY (1) and finally have:
unsigned char __far __at(0x7f00) buf[0x100];
unsigned char head, tail;
#define USE_ASSEMBLY (1)
#if !USE_ASSEMBLY
#else
53
3.11. INLINE ASSEMBLER CODE CHAPTER 3. USING SDCC
The inline assembler code can contain any valid code understood by the assembler, this includes any assembler
directives and comment lines. The assembler does not like some characters like ’:’ or ”’ in comments. You’ll
find an 100+ pages assembler manual in sdcc/sdas/doc/asmlnk.txt or online at http://svn.code.sf.net/
p/sdcc/code/trunk/sdcc/sdas/doc/asmlnk.txt.
The compiler does not do any validation of the code within the __asm ... __endasm; keyword pair.
Specifically it will not know which registers are used and thus register pushing/popping has to be done manually.
It is required that each assembly instruction be placed on a separate line. This is also recommended for labels (as
the example shows). This is especially important to note when the inline assembler is placed in a C preprocessor
macro as the preprocessor will normally put all replacing code on a single line. Only when the macro has each
assembly instruction on a single line that ends with a line continuation character will it be placed as separate lines
in the resulting .asm file.
#define DELAY \
__asm \
nop \
nop \
__endasm
When the --peep-asm command line option is used, the inline assembler code will be passed through the peephole
optimizer. There are only a few (if any) cases where this option makes sense, it might cause some unexpected
changes in the inline assembler code. Please go through the peephole optimizer rules defined in file peeph.def
before using this option.
54
3.11. INLINE ASSEMBLER CODE CHAPTER 3. USING SDCC
_simpleInterrupt:
push acc
push b
push dpl
push dph
push psw
mov psw,#0x00
inc _counter
pop psw
pop dph
pop dpl
pop b
pop acc
reti
whereas nakedInterrupt looks like:
_nakedInterrupt:
inc _counter ; does not change flags, no need to save psw
reti ; MUST explicitly include ret or reti in _naked
function
The related directive #pragma exclude allows a more fine grained control over pushing & popping the registers.
While there is nothing preventing you from writing C code inside a _naked function, there are many ways to
shoot yourself in the foot doing this, and it is recommended that you stick to inline assembler.
labels in the assembler, locality of which is confined within two labels of the standard form. The compiler uses the same form for labels within
a function (but starting from nnnnn=00100); and places always a standard label at the beginning of a function, thus limiting the locality of labels
within the scope of the function. So, if the inline assembler part would be embedded into C-code, an improperly placed non-local label in the
assembler would break up the reference space for labels created by the compiler for the C-code, leading to an assembling error.
The numeric part of local labels does not need to have 5 digits (although this is the form of labels output by the compiler), any valid integer
will do. Please refer to the assemblers documentation for further details.
55
3.12. SUPPORT ROUTINES FOR INTEGER MULTIPLICATIVE OPERATORS CHAPTER 3. USING SDCC
In other words inline assembly code can access labels defined in inline assembly within the scope of the function.
The same goes the other way, i.e. labels defines in inline assembly can not be accessed by C statements.
Function Description
_mulint.c 16 bit multiplication
_divsint.c signed 16 bit division (calls _divuint)
_divuint.c unsigned 16 bit division
_modsint.c signed 16 bit modulus (calls _moduint)
_moduint.c unsigned 16 bit modulus
_mullong.c 32 bit multiplication
_divslong.c signed 32 division (calls _divulong)
_divulong.c unsigned 32 division
_modslong.c signed 32 bit modulus (calls _modulong)
_modulong.c unsigned 32 bit modulus
In the mcs51, ds390, hc08, s08, pdk13, pdk14, pdk15, pic14 and pic16 backends they are by default compiled
as non-reentrant; when targeting on of these architectures, interrupt service routines should not do any of the above
operations. If this is unavoidable then the above routines will need to be compiled with the --stack-auto option,
after which the source program will have to be compiled with --int-long-reent option. Notice that you don’t have to
call these routines directly. The compiler will use them automatically every time an integer operation is required.
7 Here, the C-label clabel is translated by the compiler into a local label, so the locality of labels within the function is not broken.
56
3.14. LIBRARY ROUTINES CHAPTER 3. USING SDCC
Function Description
_fsadd.c add floating point numbers
_fssub.c subtract floating point numbers
_fsdiv.c divide floating point numbers
_fsmul.c multiply floating point numbers
_fs2uchar.c convert floating point to unsigned char
_fs2char.c convert floating point to signed char
_fs2uint.c convert floating point to unsigned int
_fs2int.c convert floating point to signed int
_fs2ulong.c convert floating point to unsigned long
_fs2long.c convert floating point to signed long
_uchar2fs.c convert unsigned char to floating point
_char2fs.c convert char to floating point number
_uint2fs.c convert unsigned int to floating point
_int2fs.c convert int to floating point numbers
_ulong2fs.c convert unsigned long to floating point number
_long2fs.c convert long to floating point number
printf() The default printf() implementation in printf_large.c does not support float (except on
ds390), only <NO FLOAT> will be printed instead of the value. To enable floating point output, recompile it
with the option -DUSE_FLOATS=1 on the command line. Use --model-large for the mcs51 port, since this uses a
lot of memory. To enable float support for the pic16 targets, see 4.7.9.
If you’re short on code memory you might want to use printf_small() instead of printf(). For the
mcs51 there additionally are assembly versions printf_tiny() (subset of printf using less than 270 bytes)
and printf_fast() and printf_fast_f() (floating-point aware version of printf_fast) which should fit
the requirements of many embedded systems (printf_fast() can be customized by unsetting #defines to not support
long variables and field widths). Be sure to use only one of these printf options within a project.
57
3.14. LIBRARY ROUTINES CHAPTER 3. USING SDCC
3.14.2.2 <malloc.h>
As of SDCC 2.6.2 you no longer need to call an initialization routine before using dynamic memory allocation and
a default heap space of 1024 bytes is provided for malloc to allocate memory from. If you need a different heap
size you need to recompile _heap.c with the required size defined in HEAP_SIZE. It is recommended to make a
copy of this file into your project directory and compile it there with:
58
3.15. MEMORY MODELS CHAPTER 3. USING SDCC
Note that the compiler does not generate any code to place the processor into 24 bit mode (although tinibios in the
ds390 libraries will do that for you). If you don’t use tinibios, the boot loader or similar code must ensure that the
processor is in 24 bit contiguous addressing mode before calling the SDCC startup code.
59
3.16. PRAGMAS CHAPTER 3. USING SDCC
Like the --model-large option, variables will by default be placed into the XDATA segment.
Segments may be placed anywhere in the 4 meg address space using the usual --*-loc options. Note that if
any segments are located above 64K, the -r flag must be passed to the linker to generate the proper segment
relocations, and the Intel HEX output format must be used. The -r flag can be passed to the linker by using the
option -Wl-r on the SDCC command line. However, currently the linker can not handle code segments > 64k.
3.16 Pragmas
Pragmas are used to turn on and/or off certain compiler options. Some of them are closely related to corresponding
command-line options (see section 3.3 on page 31).
Pragmas should be placed before and/or after a function, placing pragmas inside a function body could have
unpredictable results.
• callee_saves function1[,function2[,function3...]] - The compiler by default uses a caller saves convention for
register saving across function calls, however this can cause unnecessary register pushing and popping when
calling small functions from larger functions. This option can be used to switch off the register saving con-
vention for the function names specified. The compiler will not save registers when calling these functions,
extra code need to be manually inserted at the entry and exit for these functions to save and restore the regis-
ters used by these functions, this can SUBSTANTIALLY reduce code and improve run time performance of
the generated code. In the future the compiler (with inter procedural analysis) may be able to determine the
appropriate scheme to use for each function call. If --callee-saves command line option is used (see page on
page 34), the function names specified in #pragma callee_saves is appended to the list of functions specified
in the command line.
• exclude none | {acc[,b[,dpl[,dph[,bits]]]]} - The exclude pragma disables the generation of pairs of push/pop
instructions in Interrupt Service Routines. The directive should be placed immediately before the ISR func-
tion definition and it affects ALL ISR functions following it. To enable the normal register saving for ISR
functions use #pragma exclude none. See also the related keyword __naked.
• less_pedantic - the compiler will not warn you anymore for obvious mistakes, you’re on your own now ;-(.
See also the command line option --less-pedantic on page 35.
More specifically, the following warnings will be disabled: comparison is always [true/false] due to limited
range of data type (94); overflow in implicit constant conversion (158); [the (in)famous] conditional flow
changed by optimizer: so said EVELYN the modified DOG (110); function ’[function name]’ must return
60
3.16. PRAGMAS CHAPTER 3. USING SDCC
value (59).
Furthermore, warnings of less importance (of PEDANTIC and INFO warning level) are disabled, too,
namely: constant value ’[]’, out of range (81); [left/right] shifting more than size of object changed to zero
(116); unreachable code (126); integer overflow in expression (165); unmatched #pragma save and #pragma
restore (170); comparison of ’signed char’ with ’unsigned char’ requires promotion to int (185); ISO C90
does not support flexible array members (187); extended stack by [number] bytes for compiler temp(s) :in
function ’[function name]’: [] (114); function ’[function name]’, # edges [number] , # nodes [number] ,
cyclomatic complexity [number] (121).
• disable_warning <nnnn> - the compiler will not warn you anymore about warning number <nnnn>.
• nogcse - will stop global common subexpression elimination.
• noinduction - will stop loop induction optimizations.
• noinvariant - will not do loop invariant optimizations. For more details see Loop Invariants in section8.1.4.
• noiv - Do not generate interrupt vector table entries for all ISR functions defined after the pragma. This
is useful in cases where the interrupt vector table must be defined manually, or when there is a secondary,
manually defined interrupt vector table (e.g. for the autovector feature of the Cypress EZ-USB FX2). More
elegantly this can be achieved by omitting the optional interrupt number after the __interrupt keyword, see
section 3.8 about interrupts.
• noloopreverse - Will not do loop reversal optimization
• nooverlay - the compiler will not overlay the parameters and local variables of a function.
• stackauto- See option --stack-auto and section 3.6 Parameters and Local Variables.
• opt_code_speed - The compiler will optimize code generation towards fast code, possibly at the expense of
code size.
• opt_code_size - The compiler will optimize code generation towards compact code, possibly at the expense
of code speed.
• opt_code_balanced - The compiler will attempt to generate code that is both compact and fast, as long as
meeting one goal is not a detriment to the other (this is the default).
• std_sdcc89 - Generally follow the C89 standard, but allow SDCC features that conflict with the standard.
• std_c89 - Follow the C89 standard and disable SDCC features that conflict with the standard.
• std_sdcc99 - Generally follow the C99 standard, but allow SDCC features that conflict with the standard.
• std_c99 - Follow the C99 standard and disable SDCC features that conflict with the standard.
• codeseg <name>- Use this name (max. 8 characters) for the code segment. See option --codeseg.
• constseg <name>- Use this name (max. 8 characters) for the const segment. See option --constseg.
The preprocessor SDCPP supports the following #pragma directives:
• pedantic_parse_number (+ | -) - Pedantic parse numbers so that situations like 0xfe-LO_B(3) are parsed
properly and the macro LO_B(3) gets expanded. Default is off. See also the --pedantic-parse-number com-
mand line option on page 32.
Below is an example on how to use this pragma. Note: this functionality is not in conformance with standard!
#pragma pedantic_parse_number +
61
3.16. PRAGMAS CHAPTER 3. USING SDCC
return c;
}
• preproc_asm (+ | -) - switch the __asm __endasm block preprocessing on / off. Default is on. Below is an
example on how to use this pragma.
#pragma preproc_asm -
/* this is a c code nop */
#define NOP ;
#pragma preproc_asm +
#pragma sdcc_hash +
#define ROMCALL(x) \
mov R6_B3, #(x & 0xff) \
mov R7_B3, #((x >> 8) & 0xff) \
lcall __romcall
62
3.17. DEFINES CREATED BY THE COMPILER CHAPTER 3. USING SDCC
...
__asm
ROMCALL(72)
__endasm;
...
Some of the pragmas are intended to be used to turn-on or off certain optimizations which might cause the compiler
to generate extra stack and/or data space to store compiler generated temporary variables. This usually happens
in large functions. Pragma directives should be used as shown in the following example, they are used to control
options and optimizations for a given function.
#pragma save /* save the current settings */
#pragma nogcse /* turnoff global subexpression elimination */
#pragma noinduction /* turn off induction optimizations */
int foo ()
{
...
/* large code */
...
}
#pragma restore /* turn the optimizations back on */
The compiler will generate a warning message when extra space is allocated. It is strongly recommended that the
save and restore pragmas be used when changing options for a function.
63
3.17. DEFINES CREATED BY THE COMPILER CHAPTER 3. USING SDCC
#define Description
__SDCC Always defined. Version number string (e.g.
SDCC_3_2_0 for sdcc 3.2.0).
SDCC OBSOLETE. WILL BE REMOVED IN THE
FUTURE. CURRENTLY Only defined for the mcs51
backend (and only if –std-cXX is not used). This
macro has been available since SDCC 2.5.6 and is the
version number as an int (ex. 256). PLEASE USE
OTHER VERSION MACROS INSTEAD!
__SDCC_mcs51 or __SDCC_ds390 or __SDCC_z80, depending on the model used (e.g.: -mds390). Older
etc. versions used SDCC_mcs51, etc instead.
__SDCC_STACK_AUTO when --stack-auto option is used
__SDCC_MODEL_SMALL when --model-small is used
__SDCC_MODEL_MEDIUM when --model-medium is used
__SDCC_MODEL_LARGE when --model-large is used
__SDCC_MODEL_HUGE when --model-huge is used
__SDCC_USE_XSTACK when --xstack option is used
__SDCC_STACK_TENBIT when -mds390 is used
__SDCC_MODEL_FLAT24 when -mds390 is used
__SDCC_VERSION_MAJOR Always defined. SDCC major version number. E.g. 3
for SDCC 3.5.0
__SDCC_VERSION_MINOR Always defined. SDCC minor version number. E.g. 5
for SDCC 3.5.0
__SDCC_VERSION_PATCH Always defined. SDCC patchlevel version number.
E.g. 0 for SDCC 3.5.0
__SDCC_REVISION Always defined. SDCC svn revision number. Older
versions of sdcc used SDCC_REVISION instead.
SDCC_PARMS_IN_BANK1 when --parms-in-bank1 is used
__SDCC_ALL_CALLEE_SAVES when --all-callee-saves is used
__SDCC_FLOAT_REENT when --float-reent is used
__SDCC_INT_LONG_REENT when --int-long-reent is used
__SDCC_OPTIMIZE_SPEED when --opt-code-speed is used
__SDCC_OPTIMIZE_SIZE when --opt-code-size is used
__SDCCCALL Default ABI version for calling convention
64
Chapter 4
4.1.3 Bankswitching
Bankswitching (a.k.a. code banking) is a technique to increase the code space above the 64k limit of the 8051.
65
4.1. MCS51 VARIANTS CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
4.1.3.1 Hardware
8000-FFFF bank1 bank2 bank3
0000-7FFF common
SiLabs C8051F120 example
Usually the hardware uses some sfr (an output port or an internal sfr) to select a bank and put it in the
banked area of the memory map. The selected bank usually becomes active immediately upon assignment to this
sfr and when running inside a bank it will switch out this code it is currently running. Therefor you cannot jump
or call directly from one bank to another and need to use a so-called trampoline in the common area. For SDCC
an example trampoline is in crtbank.asm and you may need to change it to your 8051 derivative or schematic. The
presented code is written for the C8051F120.
When calling a banked function SDCC will put the LSB of the functions address in register R0, the MSB
in R1 and the bank in R2 and then call this trampoline __sdcc_banked_call. The current selected bank is saved on
the stack, the new bank is selected and an indirect jump is made. When the banked function returns it jumps to
__sdcc_banked_ret which restores the previous bank and returns to the caller.
4.1.3.2 Software
When writing banked software using SDCC you need to use some special keywords and options. You also need to
take over a bit of work from the linker.
To create a function that can be called from another bank it requires the keyword __banked. The caller
must see this in the prototype of the callee and the callee needs it for a proper return. Called functions within the
same bank as the caller do not need the __banked keyword nor do functions in the common area. Beware: SDCC
does not know or check if functions are in the same bank. This is your responsibility!
Normally all functions you write end up in the segment CSEG. If you want a function explicitly to reside
in the common area put it in segment HOME. This applies for instance to interrupt service routines as they should
not be banked.
Functions that need to be in a switched bank must be put in a named segment. The name can be mostly
anything up to eight characters (e.g. BANK1). To do this you either use --codeseg BANK1 (See 3.3.4) on the
command line when compiling or #pragma codeseg BANK1 (See 3.16) at the top of the C source file. The segment
name always applies to the whole source file and generated object so functions for different banks need to be
defined in different source files.
When linking your objects you need to tell the linker where to put your segments. To do this you use the
following command line option to SDCC: -Wl-b BANK1=0x18000 (See 3.3.5). This sets the virtual start address
of this segment. It sets the banknumber to 0x01 and maps the bank to 0x8000 and up. The linker will not check for
overflows, again this is your responsibility.
66
4.1. MCS51 VARIANTS CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
67
4.1. MCS51 VARIANTS CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
00006$:
mov r0,#l_XSEG
mov a,r0
orl a,#(l_XSEG >> 8)
jz 00008$
mov r1,#((l_XSEG + 255) >> 8)
mov dptr,#s_XSEG
clr a
00007$: movx @dptr,a
inc dptr
djnz r0,00007$
djnz r1,00007$
00008$:
(crtxstack.asm)
.area GSINIT5 (CODE)
; Need to initialize in GSINIT5 because __mcs51_genXINIT modifies __XPAGE
; and __mcs51_genRAMCLEAR modifies _spx.
mov __XPAGE,#(__start__xstack >> 8)
mov _spx,#__start__xstack
(application modules)
.area GSINIT (CODE)
(main.asm)
.area GSFINAL (CODE)
ljmp __sdcc_program_startup
;--------------------------------------------------------
; Home
;--------------------------------------------------------
.area HOME (CODE)
.area CSEG (CODE)
__sdcc_program_startup:
lcall _main
; return from main will lock up
sjmp .
One of these modules (crtstart.asm) contains a call to the C routine _sdcc_external_startup() at the start of the
CODE area. This routine is also in the runtime library and returns 0 by default. If this routine returns a non-
zero value, the static & global variable initialization will be skipped and the function main will be invoked.
Otherwise static & global variables will be initialized before the function main is invoked. You could add an
_sdcc_external_startup() routine to your program to override the default if you need to setup hardware or perform
some other critical operation prior to static & global variable initialization. On some mcs51 variants __xdata mem-
ory has to be explicitly enabled before it can be accessed or if the watchdog needs to be disabled, this is the place
to do it. The startup code clears all internal data memory, 256 bytes by default, but from 0 to n-1 if --iram-size <n>
is used. (recommended for Chipcon CC1010).
See also the compiler option --no-xinit-opt and section 4.1 about MCS51-variants.
While these initialization modules are meant as generic startup code there might be the need for customiza-
tion. Let’s assume the return value of _sdcc_external_startup() in crtstart.asm should not be checked (or
_sdcc_external_startup() should not be called at all). The recommended way would be to copy crtstart.asm (f.e.
from http://svn.code.sf.net/p/sdcc/code/trunk/sdcc/device/lib/mcs51/crtstart.
asm) into the source directory, adapt it there, then assemble it with sdas8051 -plosgff 1 crtstart.asm and when
linking your project explicitly specify crtstart.rel. As a bonus a listing of the relocated object file crtstart.rst is
generated.
1 ”-plosgff” are the assembler options used in http://sdcc.svn.sourceforge.net/viewvc/sdcc/trunk/sdcc/device/
lib/mcs51/Makefile.in?view=markup
68
4.1. MCS51 VARIANTS CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
int main()
{
return c_func(10,9);
}
The corresponding assembler function is:
.globl _asm_func_PARM_2
.globl _asm_func
.area OSEG
_asm_func_PARM_2:
.ds 1
.area CSEG
_asm_func:
mov a,dpl
add a,_asm_func_PARM_2
mov dpl,a
mov dph,#0x00
ret
The parameter naming convention is _<function_name>_PARM_<n>, where n is the parameter number starting
from 1, and counting from the left. The first parameter is passed in DPH, DPL, B and ACC according to the
69
4.1. MCS51 VARIANTS CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
description above. The variable name for the second parameter will be _<function_name>_PARM_2.
Then compile and link the assembler routine to the C source file with the following command:
int main()
{
return c_func(10,9,8);
}
The corresponding (unoptimized) assembler routine is:
.globl _asm_func
_asm_func:
push _bp
mov _bp,sp ;stack contains: _bp, return address, second
parameter, third parameter
mov r2,dpl
mov a,_bp
add a,#0xfd ;calculate pointer to the second parameter
mov r0,a
mov a,_bp
add a,#0xfc ;calculate pointer to the rightmost parameter
mov r1,a
mov a,@r0
add a,@r1
add a,r2 ;calculate the result (= sum of all three
parameters)
mov dpl,a ;return value goes into dptr (cast into int)
mov dph,#0x00
mov sp,_bp
pop _bp
ret
The compiling and linking procedure remains the same, however note the extra entry & exit linkage required for
the assembler code, _bp is the stack frame pointer and is used to compute the offset into the stack for parameters
and local variables.
70
4.2. DS400 PORT CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
4.3 The Z80, Z180, Rabbit 2000, Rabbit 2000A, Rabbit 3000A, SM83
(GameBoy), eZ80 and TLCS-90 ports
SDCC can target the Z80, Z180, eZ80 in Z80 mode, Rabbit 2000, Rabbit 2000A, Rabbit 3000A and LR35902, the
Sharp SM83 (used .e.g in the Nintendo GameBoy) sm83.
When a frame pointer is used, it resides in IX. Register A, B, C, D, E, H, L and IY are used as a temporary
registers for holding variables.
When enabling optimizations using --opt-code size and a sufficiently high value for --max-allocs-per-node
SDCC typically generates much better code for these architectures than many other compilers. A comparison of
compilers for these architecture can be found at http://sdcc.sourceforge.net/wiki/index.php/
Z80_code_size.
71
4.3. THE Z80, Z180, RABBIT 2000, RABBIT 2000A, RABBIT 3000A, SM83 (GAMEBOY), EZ80 AND
TLCS-90 PORTS CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
for stack parameters the parameters after the call (thus the callee has to do this instead). __z88dk_callee can be
combined with __smallc, __sdcccall(0) or __sdcccall(1).
For Functions that do not have variable arguments: The first parameter is passed in a if it has 8 bits. If it has 16
bits it is passed in hl. If it has 32 bits, it is passed in hlde. If the first parameter is in a, and the second has 8 bits, it
is passed in l; if the first is passed in a or hl, and the second has 16 bits, it is passed in de; all other parameters are
passed on the stack, right-to-left. Independent of their size, struct / union parameters and all following parameters
are always passed on the stack. If __z88dk_callee is not used, after the call, the stack parameters are cleaned up by
the caller, with the following exceptions: functions that do not have variable arguments and return void or a type of
at most 16 bits, or have both a first parameter of type float and a return value of type float.
4.3.4 Rabbit 2000, Rabbit 2000A, Rabbit 3000A, eZ80 and TLCS-90 calling conventions
The default is the Z80 SDCC calling convention, version 0 as described above. Using the command-line option
–sdcccall 1, the default can be changed to version 1 of the Rabbit SDCC calling convention. There are four
other calling conventions supported, which can be specified using the keywords __smallc, __z88dk_fastcall and
__z88dk_callee. They are primarily intended for compatibility with libraries written for other compilers. For
__z88dk_fastcall, there may be only one parameter of at most 32 bits, which is passed the same way as the return
value. For __z88dk_callee, the stack is not adjusted for stack parameters the parameters after the call (thus the
callee has to do this instead). __z88dk_callee can be combined with __smallc, __sdcccall(0) or __sdcccall(1).
For Functions that do not have variable arguments: The first parameter is passed in a if it has 8 bits. If it has 16
bits it is passed in hl. If it has 32 bits, it is passed in hlde. If the first parameter is in a, and the second has 8 bits,
72
4.3. THE Z80, Z180, RABBIT 2000, RABBIT 2000A, RABBIT 3000A, SM83 (GAMEBOY), EZ80 AND
TLCS-90 PORTS CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
it is passed in l; if the first is in hl or hlde, and the second has 8 bits, it is passed in a; if the first is in a, and the
second has 16 bits, it is passed in hl; all other parameters are passed on the stack, right-to-left. Independent of their
size, struct / union parameters and all following parameters are always passed on the stack. If __z88dk_callee is
not used, after the call, the stack parameters are cleaned up by the caller, with the following exceptions: functions
that do not have variable arguments and return void or a type of at most 16 bits, or have both a first parameter of
type float and a return value of type float.
For Functions that do not have variable arguments: The first parameter is passed in a if it has 8 bits. If it has 16
bits it is passed in de. If it has 32 bits, it is passed in debc. If the first parameter is in a, and the second has 8 bits, it
is passed in e; if the first is in bc or debc, and the second has 8 bits, it is passed in a; if the first is passed in a, and
the second has 16 bits, it is passed in bc; if the first is passed in de, and the second has 16 bits, it is passed in bc; all
other parameters are passed on the stack, right-to-left. Independent of their size, struct / union parameters and all
following parameters are always passed on the stack. The stack is adjusted by the callee (thus explicitly specifying
__z88dk_callee does not make a difference).
73
4.4. THE HC08 AND S08 PORTS CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
For functions that have variable arguments, all parameters are passed on the stack. For other functions, if the
first parameter has 8 or 16 bits, it is passed in a or x. If the first parameter has 8 bits, and the second has 16 bits,
the second is passed in x. If the first parameter has 16 bits, and the second has 8 bits, the second is passed in a.
All other parameters are passed on the stack. Independent of their size, struct / union parameters and all following
parameters are always passed on the stack. If __z88dk_callee is specified, the stack is always adjusted by the callee.
Otherwise, for the large memory model, the stack is always adjusted by the caller. For the medium memory model
74
4.6. THE PIC14 PORT CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
the stack is adjusted by the caller, with the following exceptions: functions that do not have variable arguments and
return void or a type of at most 16 bits, or have both a first parameter of type float and a return value of type float.
75
4.6. THE PIC14 PORT CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
76
4.6. THE PIC14 PORT CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
1. Make local functions static, as non static functions require code page selection overhead.
Due to the way SDCC handles functions, place called functions prior to calling functions in the file wherever
possible: Otherwise SDCC will insert unnecessary pagesel directives around the call, believing that the called
function is externally defined.
2. For devices that have multiple code pages it is more efficient to use the same number of files as pages: Use
up to 4 separate .c files for the 16F877, but only 2 files for the 16F874. This way the linker can put the code
for each file into different code pages and there will be less page selection overhead.
3. And as for any 8 bit micro (especially for PIC14 as they have a very simple instruction set), use ‘unsigned
char’ wherever possible instead of ‘int’.
If your processor header file doesn’t contain config addresses you can declare it manually or use a literal
address:
static __code uint16_t __at (0x2007) configword1 = _INTRC_IO &
_CP_ALL & _WDT_OFF & [...];
77
4.6. THE PIC14 PORT CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
Pic device specific header and c source files are automatically generated from MPLAB include files, which
are published by Microchip with a special requirement that they are only to be used with authentic Microchip
devices. This reqirement prevents to publish generated header and c source files under the GPL compatible license,
so they are located in non-free directory (see section 2.3). In order to include them in include and library search
paths, the --use-non-free command line option should be defined.
NOTE: the compiled code, which use non-free pic device specific libraries, is not GPL compatible!
$(PRJ).hex: $(OBJS)
gplink -m -s $(PRJ).lkr -o $(PRJ).hex $(OBJS) libsdcc.lib
Here is a Makefile using MPLAB:
.c.o:
sdcc -S -V --use-non-free -mpic14 -p16f877 $<
mpasmwin /q /o $*.asm
$(PRJ).hex: $(OBJS)
mplink /v $(PRJ).lkr /m $(PRJ).map /o $(PRJ).hex $(OBJS)
libsdcc.lib
Please note that indentations within a Makefile have to be done with a tabulator character.
--stack-loc sets the lowest address of the argument passing stack (defaults to a suitably large shared databank to
reduce BANKSEL overhead)
--stack-size sets the size if the argument passing stack (default: 16, minimum: 4)
--use-non-free make non-free device headers and libraries available in the compiler’s search paths (implicit -I and
-L options)
--no-extended-instructions forbid use of the extended instruction set (e.g., ADDFSR)
78
4.6. THE PIC14 PORT CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
79
4.7. THE PIC16 PORT CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
80
4.7. THE PIC16 PORT CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
81
4.7. THE PIC16 PORT CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
small Selects small stack model. 8 bit stack and frame pointers. Supports 256 bytes stack size.
large Selects large stack model. 16 bit stack and frame pointers. Supports 65536 bytes stack size.
0 no optimization
1 checks previous used register and if it is the same then does not emit BANKSEL, accounts only
for labels.
2 tries to check the location of (even different) symbols and removes BANKSELs if they are in the
same bank.
Important: There might be problems if the linker script has data sections across bank borders!
--preplace-udata-with=[kword] Replaces the default udata keyword for allocating unitialized data variables with
[kword]. Valid keywords are: "udata_acs", "udata_shr", "udata_ovr".
--ivt-loc=n Place the interrupt vector table at address n. Useful for bootloaders.
--nodefaultlibs Do not link default libraries when linking.
82
4.7. THE PIC16 PORT CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
Macro Description
__SDCC_pic16 Port identification
pic18fxxxx MCU Identification. xxxx is the microcontrol identification number, i.e. 452, 6620, etc
__18Fxxxx MCU Identification (same as above)
STACK_MODEL_nnn nnn = SMALL or LARGE respectively according to the stack model used
Macro Description
__18Fxxxx MCU Identification. xxxx is the microcontrol identification number, i.e. 452, 6620, etc
__SDCC_MODEL_nnn nnn = SMALL or LARGE respectively according to the memory model used for SDCC
STACK_MODEL_nnn nnn = SMALL or LARGE respectively according to the stack model used
4.7.5 Directories
PIC16 port uses the following directories for searching header files and libraries.
83
4.7. THE PIC16 PORT CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
If the --use-non-free command line option is specified, non-free directories are searched:
4.7.6 Pragmas
The PIC16 port currently supports the following pragmas:
stack This forces the code generator to initialize the stack & frame pointers at a specific address. This is an ad
hoc solution for cases where no STACK directive is available in the linker script or gplink is not instructed to
create a stack section.
The stack pragma should be used only once in a project. Multiple pragmas may result in indeterminate
behaviour of the program.2
The format is as follows:
bottom_address is the lower bound of the stack section. The stack pointer initially will point at address
(bottom_address+stack_size-1).
Example:
/* initializes stack of 100 bytes at RAM address 0x200 */
#pragma stack 0x200 100
If the stack_size field is omitted then a stack is created with the default size of 64. This size might be enough for
most programs, but its not enough for operations with deep function nesting or excessive stack usage.
code Force a function to a static FLASH address.
Example:
/* place function test_func at 0x4000 */
#pragma code test_func 0x4000
module_name can be any library or object file (including its path). Note that there are four reserved keywords
which have special meaning. These are:
This feature allows for linking with specific libraries without having to explicit name them in the command line.
Note that the IGNORE keyword will reject all modules specified by the library pragma.
udata The pragma udata instructs the compiler to emit code so that linker will place a variable at a specific memory
bank.
2 The old format (ie. #pragma stack 0x5ff) is deprecated and will cause the stack pointer to cross page boundaries (or even exceed the
available data RAM) and crash the program. Make sure that stack does not cross page boundaries when using the SMALL stack model.
84
4.7. THE PIC16 PORT CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
Example:
/* places variable foo at bank2 */
#pragma udata bank2 foo
char foo;
In order for this pragma to work extra SECTION directives should be added in the .lkr script. In the following
example a sample .lkr file is shown:
The linker will recognise the section name set in the pragma statement and will position the variable at the memory
bank set with the RAM field at the SECTION line in the linker script file.
config The pragma config instructs the compiler to emit config directive.
The format is as follows:
Multiple settings may be defined on a single line, separated by commas. Settings for a single configuration byte
may also be defined on separate lines.
Example:
#pragma config CP0=OFF,OSCS=ON,OSC=LP,BOR=ON,BORV=25,WDT=ON,WDTPS=128,CCP2MUX=ON
#pragma config STVR=ON
NOTE: the compiled code, which use non-free pic device specific libraries, is not GPL compatible!
85
4.7. THE PIC16 PORT CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
#include <pic18fregs.h>
The specific microcontroller is selected within the pic18fregs.h automatically, so the same source can be used with
a variety of devices.
4.7.9 Libraries
The libraries that PIC16 port depends on are the microcontroller device libraries which contain the symbol defini-
tions for the microcontroller special function registers. These libraries have the format pic18fxxxx.lib, where xxxx
is the microcontroller identification number. The specific library is selected automatically by the compiler at link
stage according to the selected device.
Libraries are created with gplib which is part of the gputils package http://sourceforge.net/projects/
gputils.
cd device/lib/pic16
./configure.gnu
cd ..
make model-pic16
su -c ’make install’ # install the libraries, you need the root password
cd ../..
cd device/include
su -c ’make install’ # install the headers, you need the root password
86
4.7. THE PIC16 PORT CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
4. Either
5. Edit /path/to/sdcc/device/include/pic16/pic18fregs.h
The file format is self-explanatory, just add
#elif defined(picDEVICE)
# include <picDEVICE.h>
at the right place (keep the file sorted, please).
6. Edit /path/to/sdcc/device/include/pic16devices.txt
Copy and modify an existing entry or create a new one and insert it at the correct place (keep the file sorted,
please).
7. ( cd /path/to/sdcc/device/non-free/lib/pic16 && sh update.sh )
8. Recompile the pic16 libraries as described in 4.7.9 or just configure and build sdcc again from scratch (rec-
ommended).
• small model
• large model
Memory model affects the default size of pointers within the source. The sizes are shown in the next table:
It is advisable that all sources within a project are compiled with the same memory model. If one wants to
override the default memory model, this can be done by declaring a pointer as far or near. Far selects large
memory model’s pointers, while near selects small memory model’s pointers.
The standard device libraries (see 4.7.8) contain no reference to pointers, so they can be used with both memory
models.
4.7.12 Stack
The stack implementation for the PIC16 port uses two indirect registers, FSR1 and FSR2.
FSR1 is assigned as stack pointer
FSR2 is assigned as frame pointer
The following stack models are supported by the PIC16 port
• SMALL model
• LARGE model
3 In fact, the .ignore files are only used when auto-generating Makefile.am using the .../libio/mkmk.sh script.
87
4.7. THE PIC16 PORT CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
S MALL model means that only the FSRxL byte is used to access stack and frame, while LARGE uses both FSRxL
and FSRxH registers. The following table shows the stack/frame pointers sizes according to stack model and the
maximum space they can address:
Stack & Frame pointer sizes according to stack model small large
Stack pointer FSR1 8-bits 16-bits
Frame pointer FSR2 8-bits 16-bits
L ARGE stack model is currently not working properly throughout the code generator. So its use is not advised.
Also there are some other points that need special care:
1. Do not create stack sections with size more than one physical bank (that is 256 bytes)
2. Stack sections should no cross physical bank limits (i.e. #pragma stack 0x50 0x100)
These limitations are caused by the fact that only FSRxL is modified when using SMALL stack model, so no more
than 256 bytes of stack can be used. This problem will disappear after LARGE model is fully implemented.
4.7.13 Functions
In addition to the standard SDCC function keywords, PIC16 port makes available two more:
__wparam Use the WREG to pass one byte of the first function argument. This improves speed but you may not
use this for functions with arguments that are called via function pointers, otherwise the first byte of the first
parameter will get lost. Usage:
__shadowregs When entering/exiting an ISR, it is possible to take advantage of the PIC18F hardware shadow
registers which hold the values of WREG, STATUS and BSR registers. This can be done by adding the
keyword __shadowregs before the __interrupt keyword in the function’s header.
__shadowregs instructs the code generator not to store/restore WREG, STATUS, BSR when entering/exiting the
ISR.
88
4.7. THE PIC16 PORT CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
4.7.15 Interrupts
An interrupt service routine (ISR) is declared using the __interrupt keyword.
When generating assembly code for ISR the code generator places a GOTO instruction at the Interrupt Vector
Address which points at the generated ISR. This single GOTO instruction is part of an automatically generated
interrupt entry point function. The actual ISR code is placed as normally would in the code space. Upon interrupt
request, the GOTO instruction is executed which jumps to the ISR code. When declaring interrupt functions as
_naked this GOTO instruction is not generated. The whole interrupt functions is therefore placed at the Interrupt
Vector Address of the specific interrupt. This is not a problem for the LOW priority interrupts, but it is a problem
for the RESET and the HIGH priority interrupts because code may be written at the next interrupt’s vector address
and cause indeterminate program behaviour if that interrupt is raised.4
n may be omitted. This way a function is generated similar to an ISR, but it is not assigned to any interrupt.
When entering an interrupt, currently the PIC16 port automatically saves the following registers:
• WREG
• STATUS
• BSR
• PROD (PRODL and PRODH)
• FSR0 (FSR0L and FSR0H)
These registers are restored upon return from the interrupt routine.5
pointer type 7th bit 6th bit rest of the pointer description
data 1 0 uuuuuu uuuuxxxx xxxxxxxx a 12-bit data pointer in data RAM memory
code 0 0 uxxxxx xxxxxxxx xxxxxxxx a 21-bit code pointer in FLASH memory
eeprom 0 1 uuuuuu uuuuuuxx xxxxxxxx a 10-bit eeprom pointer in EEPROM memory
(unimplemented) 1 1 xxxxxx xxxxxxxx xxxxxxxx unimplemented pointer type
Generic pointer are read and written with a set of library functions which read/write 1, 2, 3, 4 bytes.
4 This is not a problem when
1. this is a HIGH interrupt ISR and LOW interrupts are disabled or not used.
2. when the ISR is small enough not to reach the next interrupt’s vector address.
5 NOTE that when the _naked attribute is specified for an interrupt routine, then NO registers are stored or restored.
89
4.7. THE PIC16 PORT CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
• using ‘__code’ and ‘__at’ modifiers. This method is deprecated. Possible options should be ANDed and
can be found in your processor header file. Example for PIC18F2550:
Mixing both methods is not allowed and throws an error message ”mixing __CONFIG and CONFIG directives”.
This type is the stream type implemented I/O in the PIC18F devices. Also the standard input and output streams
are declared in stdio.h:
The FILE type is actually a generic pointer which defines one more type of generic pointers, the stream pointer.
This new type has the format:
pointer type <7:6> <5> <4> <3:0> rest of the pointer descrption
stream 00 1 0 nnnn uuuuuuuu uuuuuuuu upper byte high nubble is 0x2n, the rest are zeroes
Currently implemented there are 3 types of streams defined:
stream type value module description
STREAM_USART 0x200000UL USART Writes/Reads characters via the USART peripheral
STREAM_MSSP 0x210000UL MSSP Writes/Reads characters via the MSSP peripheral
STREAM_USER 0x2f0000UL (none) Writes/Reads characters via used defined functions
The stream identifiers are declared as macros in the stdio.h header.
In the libc library there exist the functions that are used to write to each of the above streams. These are
90
4.7. THE PIC16 PORT CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
In order to increase performance putchar is declared in stdio.h as having its parameter in WREG (it has the
__wparam keyword). In stdio.h exists the macro PUTCHAR(arg) that defines the putchar function in a user-friendly
way. arg is the name of the variable that holds the character to print. An example follows:
#include <pic18fregs.h>
#include <stdio.h>
PUTCHAR( c )
{
PORTA = c; /* dump character c to PORTA */
}
void main(void)
{
stdout = STREAM_USER; /* this is not necessary, since stdout points
* by default to STREAM_USER */
printf (”This is a printf test\n”);
}
For sprintf and vsprintf buf should normally be a data pointer where the resulting string will be placed. No range
checking is done so the user should allocate the necessary buffer. For fprintf and vfprintf fp should be a stream
pointer (i.e. stdout, STREAM_MSSP, etc...).
4.7.18.3 Signals
The PIC18F family of microcontrollers supports a number of interrupt sources. A list of these interrupts is shown
in the following table:
The prototypes for these names are defined in the header file signal.h.
In order to simplify signal handling, a number of macros is provided:
DEF_INTHIGH(name) begin the definition of the interrupt dispatch table for high priority interrupts. name is the
function name to use.
DEF_INTLOW(name) begin the definition of the interrupt dispatch table for low priority interrupt. name is the
function name to use.
91
4.7. THE PIC16 PORT CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
SIGHANDLER(handler) this declares the function prototype for the handler function.
SIGHANDLERNAKED(handler) same as SIGHANDLER() but declares a naked function.
An example of using the macros above is shown below:
#include <pic18fregs.h>
#include <signal.h>
DEF_INTHIGH(high_int)
DEF_HANDLER(SIG_TMR0, _tmr0_handler)
DEF_HANDLER(SIG_BCOL, _bcol_handler)
END_DEF
SIGHANDLER(_tmr0_handler)
{
/* action to be taken when timer 0 overflows */
}
SIGHANDLERNAKED(_bcol_handler)
{
__asm
/* action to be taken when bus collision occurs */
retfie
__endasm;
}
NOTES: Special care should be taken when using the above scheme:
• do not place a colon (;) at the end of the DEF_* and END_DEF macros.
• when declaring SIGHANDLERNAKED handler never forget to use retfie for proper returning.
It is should be understood that stack is easily consumed when calling complicated functions. Using command line
arguments like --fomit-frame-pointer might reduce stack usage by not creating unnecessary stack frames. Other
ways to reduce stack usage may exist.
92
4.7. THE PIC16 PORT CHAPTER 4. NOTES ON SUPPORTED PROCESSORS
93
Chapter 5
Debugging
There are several approaches to debugging your code. This chapter is meant to show your options and to give
detail on some of them:
• run a syntax-checking tool like splint (see --more-pedantic 3.3.4) over the code.
• for the high level code use a C-compiler (like f.e. GCC) to compile run and debug the code on your host. See
(see --more-pedantic 3.3.4) on how to handle syntax extensions like __xdata, __at(), ...
• use another C-compiler to compile code for your target. Always an option but not recommended:) And not
very likely to help you. If you seriously consider walking this path you should at least occasionally check
portability of your code. Most commercial compiler vendors will offer an evaluation version so you can test
compile your code or snippets of your code.
Debugging on a simulator:
• use a MCU port pin to serially output debug data to the RS232 port of your host. You’ll probably want some
level shifting device typically involving a MAX232 or similar IC. If the hardware serial port of the MCU is
not available search for ’Software UART’ in your favourite search machine.
• use an on-target monitor. In this context a monitor is a small program which usually accepts commands
via a serial line and allows to set program counter, to single step through a program and read/write memory
locations. For the 8051 good examples of monitors are paulmon and cmon51 (see section 6.5).
• toggle MCU port pins at strategic points within your code and use an oscilloscope. A digital oscilloscope
with deep trace memory is really helpful especially if you have to debug a realtime application. If you need to
monitor more pins than your oscilloscope provides you can sometimes get away with a small R-2R network.
On a single channel oscilloscope you could for example monitor 2 push-pull driven pins by connecting one
via a 10 kΩ resistor and the other one by a 5 kΩ resistor to the oscilloscope probe (check output drive
capability of the pins you want to monitor). If you need to monitor many more pins a logic analyzer will be
handy.
• use an ICE (in circuit emulator). Usually very expensive. And very nice to have too. And usually locks you
(for years...) to the devices the ICE can emulate.
94
5.1. DEBUGGING WITH SDCDB CHAPTER 5. DEBUGGING
• use a remote debugger. In most 8-bit systems the symbol information is not available on the target, and a
complete debugger is too bulky for the target system. Therefore usually a debugger on the host system con-
nects to an on-target debugging stub which accepts only primitive commands.
Terms to enter into your favourite search engine could be ’remote debugging’, ’gdb stub’ or ’inferior debug-
ger’. (is there one?)
• use an on target hardware debugger. Some of the more modern MCUs include hardware support for setting
break points and monitoring/changing variables by using dedicated hardware pins. This facility doesn’t
require additional code to run on the target and usually doesn’t affect runtime behaviour until a breakpoint is
hit. For the mcs51 most hardware debuggers use the AOMF file (see 3.2.1) as input file.
Last not least:
• if you are not familiar with any of the following terms you’re likely to run into problems rather sooner than
later: volatile, atomic, memory map, overlay. As an embedded programmer you have to know them so why
not look them up before you have problems?)
• tell someone else about your problem (actually this is a surprisingly effective means to hunt down the bug
even if the listener is not familiar with your environment). As ’failure to communicate’ is probably one of
the job-induced deformations of an embedded programmer this is highly encouraged.
sdcdb foo
95
5.1. DEBUGGING WITH SDCDB CHAPTER 5. DEBUGGING
• -s <serial port file> passed to simulator see the simulator docs for details.
• -S <serial in,out> passed to simulator see the simulator docs for details.
• -k <port number> passed to simulator see the simulator docs for details.
sdcdb>break 100
sdcdb>break foo.c:100
sdcdb>break funcfoo
sdcdb>break foo.c:funcfoo
sdcdb>clear 100
sdcdb>clear foo.c:100
sdcdb>clear funcfoo
sdcdb>clear foo.c:funcfoo
continue
Continue program being debugged, after breakpoint.
finish
Execute till the end of the current function.
delete [n]
Delete breakpoint number ’n’. If used without any option clear ALL user defined break points.
96
5.1. DEBUGGING WITH SDCDB CHAPTER 5. DEBUGGING
step
Step program until it reaches a different source line. Note: pressing <return> repeats the last command.
next
Step program, proceeding through subroutine calls.
run
Start debugged program.
ptype variable
Print type information of the variable.
print variable
print value of variable.
file filename
load the given file name. Note this is an alternate method of loading file for debugging.
frame
print information about current frame.
set srcmode
Toggle between C source & assembly source.
! simulator command
Send the string following ’!’ to the simulator, the simulator response is displayed. Note the debugger does not
interpret the command being sent to the simulator, so if a command like ’go’ is sent the debugger can loose its
execution context and may display incorrect values.
quit
"Watch me now. Iam going Down. My name is Bobby Brown"
97
5.1. DEBUGGING WITH SDCDB CHAPTER 5. DEBUGGING
(load-file sdcdbsrc.el)
.xemacs is a lisp file so the () around the command is REQUIRED. The files can also be loaded dynami-
cally while XEmacs is running, set the environment variable ’EMACSLOADPATH’ to the installation bin directory
(<installdir>/bin), then enter the following command ESC-x load-file sdcdbsrc. To start the interface enter the
following command:
ESC-x sdcdbsrc
The command line options that are passed to the simulator directly are bound to default values in the file
sdcdbsrc.el. The variables are listed below, these values maybe changed as required.
• sdcdbsrc-cpu-type ’51
• sdcdbsrc-frequency ’11059200
• sdcdbsrc-serial nil
The following is a list of key mapping for the debugger interface.
;; Current Listing ::
;;key binding Comment
;;--- ------- -------
;;
;; n sdcdb-next-from-src SDCDB next command
;; b sdcdb-back-from-src SDCDB back command
;; c sdcdb-cont-from-src SDCDB continue command
;; s sdcdb-step-from-src SDCDB step command
;; ? sdcdb-whatis-c-sexp SDCDB ptypecommand for data
at
;; buffer point
;; x sdcdbsrc-delete SDCDB Delete all breakpoints
if no arg
;; given or delete arg (C-u
arg x)
;; m sdcdbsrc-frame SDCDB Display current frame
98
5.2. DEBUGGING WITH OTHER DEBUGGERS (E.G. GDB): ELF / DWARF CHAPTER 5. DEBUGGING
if no arg,
;; given or display frame arg
;; buffer point
;; ! sdcdbsrc-goto-sdcdb Goto the SDCDB output buffer
;; p sdcdb-print-c-sexp SDCDB print command for data
at
;; buffer point
;; g sdcdbsrc-goto-sdcdb Goto the SDCDB output buffer
;; t sdcdbsrc-mode Toggles Sdcdbsrc mode (turns
it off)
;;
;; C-c C-f sdcdb-finish-from-src SDCDB finish command
;;
;; C-x SPC sdcdb-break Set break for line with
point
;; ESC t sdcdbsrc-mode Toggle Sdcdbsrc mode
;; ESC m sdcdbsrc-srcmode Toggle list mode
;;
99
Chapter 6
TIPS
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:
100
6.1. PORTING CODE FROM OR TO OTHER COMPILERS CHAPTER 6. TIPS
• check whether the startup code contains the correct initialization (watchdog, peripherals).
• check whether the sizes of short, int, long match.
• check if some 16 or 32 bit hardware registers require a specific addressing order (least significant or most
significant byte first) and adapt if needed (first and last relate to time and not to lower/upper memory location
here, so this is not the same as endianness).
• check whether the keyword volatile is used where needed. The compilers might differ in their optimization
characteristics (as different versions of the same compiler might also use more clever optimizations this is
good idea anyway). See section 3.8.1.1.
• check that the compilers are not told to suppress warnings.
• check and convert compiler specific extensions (interrupts, memory areas, pragmas etc.).
• check for differences in type promotion. Especially check for math operations on char or unsigned
char variables. For the sake of C99 compatibility SDCC will probably promote these to int more often
than other compilers. Eventually insert explicit casts to (char) or (unsigned char). Also check that
the ~ operator is not used on bit variables, use the ! operator instead. See sections 6 and 1.5.
• check the assembly code generated for interrupt routines (f.e. for calls to possibly non-reentrant library
functions).
• check whether timing loops result in proper timing (or preferably consider a rewrite of the code with timer
based delays instead).
• check for differences in printf parameters (some compilers push (va_arg) char variables as int others push
them as char. See section 1.5). Provide a putchar() function if needed.
• check the resulting memory map. Usage of different memory spaces: code, stack, data (for mcs51/ds390
additionally idata, pdata, xdata). Eventually check if unexpected library functions are included.
101
6.3. DOCUMENTATION INCLUDED IN THE DISTRIBUTION CHAPTER 6. TIPS
102
6.4. COMMUNICATION ONLINE AT SOURCEFORGE CHAPTER 6. TIPS
103
6.6. RELATED DOCUMENTATION / RECOMMENDED READING CHAPTER 6. TIPS
104
6.8. SOME QUESTIONS CHAPTER 6. TIPS
• 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 compo-
nents, 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 burnout1 . Chances are you didn’t want to hear some of them...
105
Chapter 7
Support
SDCC has grown to be a large project. The compiler alone (without the preprocessor, assembler and linker) is well
over 150,000 lines of code (blank stripped). The open source nature of this project is a key to its continued growth
and support. You gain the benefit and support of many active software developers and end users. Is SDCC perfect?
No, that’s why we need your help. The developers take pride in fixing reported bugs. You can help by reporting
the bugs and helping other SDCC users. There are lots of ways to contribute, and we encourage you to take part in
making SDCC a great software package.
The SDCC project is hosted on the SDCC SourceForge site at http://sourceforge.net/projects/
sdcc. You’ll find the complete set of mailing lists, forums, bug reporting system, patch submission system, wiki,
rss-feed, download area and Subversion code repository there.
methods of distribution.
106
7.2. REQUESTING FEATURES CHAPTER 7. SUPPORT
7.5 ChangeLog
You can follow the status of the Subversion version of SDCC by watching the Changelog in the Subversion reposi-
tory http://svn.code.sf.net/p/sdcc/code/trunk/sdcc/ChangeLog.
107
7.9. EXAMPLES CHAPTER 7. SUPPORT
You’ll find the test code in the directory sdcc/support/regression. You can run these tests manually by running
make in this directory (or f.e. ”make test-mcs51” if you don’t want to run the complete tests). The test code
might also be interesting if you want to look for examples checking corner cases of SDCC or if you plan to submit
patches.
The PIC14 port uses a different set of regression tests , you’ll find them in the directory sdcc/src/regression.
7.9 Examples
You’ll find some small examples in the directory sdcc/device/examples/. More examples and libraries are avail-
able at The SDCC Open Knowledge Resource http://sdccokr.dl9sec.de/ web site or at http://www.
pjrc.com/tech/8051/.
3. be able to insert excursions about skills like using a revision control system, submitting/applying
patches, using a type-setting (as opposed to word-processing) engine LYX/LATEX, using SourceForge
http://sourceforge.net/, following some netiquette http://en.wikipedia.org/wiki/
Netiquette, understanding BSD/LGPL/GPL/Proprietary licensing, growth models of Open Source
Software, CPU simulation, compiler regression tests.
And if there should be a shortage of ideas then you can always point students to the ever-growing feature
request list http://sourceforge.net/p/sdcc/feature-requests/.
4. not tie students to a specific host platform and instead allow them to use a host platform of their choice
(among them Alpha, i386, i386_64, Mac OS X, Mips, Sparc, Windows and eventually OLPC http://
www.laptop.org)
8. have complete control over and insight into the tool chain
9. make your students aware about the pros and cons of open source software development
10. give back to the public as you are probably at least partially publicly funded
11. give students a chance to publicly prove their skills and to possibly see a world wide impact
then SDCC is probably among the first choices. Well, probably SDCC might be the only choice.
3 the phrase "use in education" might evoke the association "only fit for use in education". This connotation is not intended but nevertheless
108
Chapter 8
8.1 Optimizations
SDCC performs a host of standard optimizations in addition to some MCU specific optimizations.
i = x + y + 1;
j = x + y;
will be translated to
iTemp = x + y;
i = iTemp + 1;
j = iTemp;
Some subexpressions are not as obvious as the above example, e.g.:
a->b[i].c = 10;
a->b[i].d = 11;
In this case the address arithmetic a->b[i] will be computed only once; the equivalent code in C would be.
iTemp = a->b[i];
iTemp.c = 10;
iTemp.d = 11;
void f () {
int i;
i = 1; /* dead store */
global = 1; /* dead store */
global = 2;
return;
global = 3; /* unreachable */
}
will be changed to
109
8.1. OPTIMIZATIONS CHAPTER 8. SDCC TECHNICAL DATA
int global;
void f () {
global = 2;
}
8.1.3 Copy-Propagation
int f() {
int i, j;
i = 10;
j = i;
return j;
}
will be changed to
int f() {
int i, j;
i = 10;
j = 10;
return 10;
}
Note: the dead stores created by this copy propagation will be eliminated by dead-code elimination.
Loop Invariant:
for (i = 0 ; i < 100 ; i ++)
f += k + l;
changed to
itemp = k + l;
for (i = 0; i < 100; i++)
f += itemp;
As mentioned previously some loop invariants are not as apparent, all static address computations are also moved
out of the loop.
changed to
itemp1 = 0;
itemp2 = 0;
110
8.1. OPTIMIZATIONS CHAPTER 8. SDCC TECHNICAL DATA
111
8.1. OPTIMIZATIONS CHAPTER 8. SDCC TECHNICAL DATA
Both the above switch statements will be implemented using a jump-table. The example to the right side is
slightly more efficient as the check for the lower boundary of the jump-table is not needed.
• The number of case labels is not larger than supported by the target architecture.
• If the case labels are not in numerical sequence (’gaps’ between cases) SDCC checks whether a jump table
with additionally inserted dummy cases is still attractive.
• If the starting number is not zero and a check for the lower boundary of the jump-table can thus be eliminated
SDCC might insert dummy cases 0, ... .
Switch statements which have large gaps in the numeric sequence or those that have too many case labels can be
split into more than one switch statement for efficient code generation, e.g.:
switch (i) {
case 1: ...
case 2: ...
case 3: ...
case 4: ...
case 5: ...
case 6: ...
case 7: ...
case 101: ...
case 102: ...
case 103: ...
case 104: ...
case 105: ...
case 106: ...
case 107: ...
}
If the above switch statement is broken down into two switch statements
switch (i) {
case 1: ...
case 2: ...
case 3: ...
case 4: ...
case 5: ...
case 6: ...
case 7: ...
}
and
switch (i) {
case 101: ...
case 102: ...
case 103: ...
case 104: ...
case 105: ...
case 106: ...
case 107: ...
}
then both the switch statements will be implemented using jump-tables whereas the unmodified switch statement
will not be.
112
8.1. OPTIMIZATIONS CHAPTER 8. SDCC TECHNICAL DATA
8.1.9 Bit-rotation
A special case of the bit-shift operation is bit rotation, SDCC recognizes the following expression to be a left
bit-rotation:
unsigned char i; /* unsigned is needed for rotation */
...
i = ((i << 1) | (i >> 7));
...
will generate the following code:
mov a,_i
rl a
mov _i,a
SDCC uses pattern matching on the parse tree to determine this operation.Variations of this case will also be
recognized as bit-rotation, i.e.:
i = ((i >> 7) | (i << 1)); /* left-bit rotation */
113
8.1. OPTIMIZATIONS CHAPTER 8. SDCC TECHNICAL DATA
and generates a swap instruction for the nibble swapping or move instructions for the byte swapping. The ”j”
example can be used to convert from little to big-endian or vice versa. If you want to change the endianness of a
signed integer you have to cast to (unsigned int) first.
Note that SDCC stores numbers in little-endian1 format (i.e. lowest order first) for most backends. However,
the hc08, s08 and stm8 backends are big-endian.
foo () {
unsigned char hob1, aob1;
bit hob2, hob3, aob2, aob3;
...
hob1 = (gint >> 15) & 1;
hob2 = (gint >> 15) & 1;
hob3 = gint & 0x8000;
aob1 = (gint >> 9) & 1;
aob2 = (gint >> 8) & 1;
aob3 = gint & 0x0800;
...
}
will generate the following code:
61 ; hob.c 7
000A E5*01 62 mov a,(_gint + 1)
000C 23 63 rl a
000D 54 01 64 anl a,#0x01
000F F5*02 65 mov _foo_hob1_1_1,a
66 ; hob.c 8
0011 E5*01 67 mov a,(_gint + 1)
0013 33 68 rlc a
0014 92*00 69 mov _foo_hob2_1_1,c
66 ; hob.c 9
0016 E5*01 67 mov a,(_gint + 1)
0018 33 68 rlc a
0019 92*01 69 mov _foo_hob3_1_1,c
70 ; hob.c 10
001B E5*01 71 mov a,(_gint + 1)
001D 03 72 rr a
001E 54 01 73 anl a,#0x01
0020 F5*03 74 mov _foo_aob1_1_1,a
75 ; hob.c 11
0022 E5*01 76 mov a,(_gint + 1)
0024 13 77 rrc a
0025 92*02 78 mov _foo_aob2_1_1,c
79 ; hob.c 12
0027 E5*01 80 mov a,(_gint + 1)
0029 A2 E3 81 mov c,acc[3]
002B 92*03 82 mov _foo_aob3_1_1,c
1 Usually 8-bit processors don’t care much about endianness. This is not the case for the standard 8051 which only has an instruction to
114
8.1. OPTIMIZATIONS CHAPTER 8. SDCC TECHNICAL DATA
Other variations of these cases however will not be recognized. They are standard C expressions, so I heartily
recommend these be the only way to get the highest order bit, (it is portable). Of course it will be recognized even
if it is embedded in other expressions, e.g.:
xyz = gint + ((gint >> 15) & 1);
will still be recognized.
foo () {
unsigned char hob1, hob2;
unsigned int how1, how2;
...
hob1 = (gint >> 8) & 0xFF;
hob2 = glong >> 24;
how1 = (glong >> 16) & 0xFFFF;
how2 = glong >> 8;
...
}
will generate the following code:
91 ; hob.c 15
0037 85*01*06 92 mov _foo_hob1_1_1,(_gint +
1)
93 ; hob.c 16
003A 85*05*07 94 mov _foo_hob2_1_1,(_glong +
3)
95 ; hob.c 17
003D 85*04*08 96 mov _foo_how1_1_1,(_glong +
2)
0040 85*05*09 97 mov (_foo_how1_1_1 + 1),(_glong
+ 3)
0043 85*03*0A 98 mov _foo_how2_1_1,(_glong +
1)
0046 85*04*0B 99 mov (_foo_how2_1_1 + 1),(_glong
+ 2)
Again, variations of these cases may not be recognized. They are standard C expressions, so I heartily recommend
these be the only way to get the higher order byte/word, (it is portable). Of course it will be recognized even if it is
embedded in other expressions, e.g.:
xyz = gint + ((gint >> 8) & 0xFF);
will still be recognized.
115
8.1. OPTIMIZATIONS CHAPTER 8. SDCC TECHNICAL DATA
Other special case optimizations may be added by the user (via --peep-file option). E.g. some variants of
the 8051 MCU allow only ajmp and acall. The following two rules will change all ljmp and lcall to ajmp
and acall
replace { lcall %1 } by { acall %1 }
replace { ljmp %1 } by { ajmp %1 }
116
8.1. OPTIMIZATIONS CHAPTER 8. SDCC TECHNICAL DATA
(NOTE: from version 2.7.3 on, you can use option --acall-ajmp, which also takes care of aligning the interrupt
vectors properly.)
The inline-assembler code is also passed through the peep hole optimizer, thus the peephole optimizer can also
be used as an assembly level macro expander. The rules themselves are MCU dependent whereas the rule language
infra-structure is MCU independent. Peephole optimization rules for other MCU can be easily programmed using
the rule language.
The optimizer will apply to the rules one by one from the top in the sequence of their appearance, it will
terminate when all rules are exhausted. If the ’restart’ option is specified, then the optimizer will start matching the
rules again from the top, this option for a rule is expensive (performance), it is intended to be used in situations
where a transformation will trigger the same rule again. An example of this (not a good one, it has side effects) is
the following rule:
replace restart {
pop %1
push %1 } by {
; nop
}
Note that the replace pattern cannot be a blank, but can be a comment line. Without the ’restart’ option only the
innermost ’pop’ ’push’ pair would be eliminated, i.e.:
pop ar1
pop ar2
push ar2
push ar1
with the restart option the rule will be applied again to the resulting code and then all the pop-push pairs will be
eliminated to yield:
; nop
; nop
A conditional function can be attached to a rule. Attaching rules are somewhat more involved, let’s illustrate this
with an example.
replace {
ljmp %5
%2:
} by {
sjmp %5
%2:
} if labelInRange
117
8.2. CYCLOMATIC COMPLEXITY CHAPTER 8. SDCC TECHNICAL DATA
The optimizer does a look-up of a function name table defined in function callFuncByName in the source file SD-
CCpeeph.c, with the name labelInRange. If it finds a corresponding entry the function is called. Note there can be
no parameters specified for some of these functions, in this case the use of %5 is crucial, since the function labelIn-
Range expects to find the label in that particular variable (the hash table containing the variable bindings is passed
as a parameter). If you want to code more such functions, take a close look at the function labelInRange and the
calling mechanism in source file SDCCpeeph.c. Currently implemented are labelInRange, labelRefCount, label-
RefCountChange, labelIsReturnOnly, xramMovcOption, portIsDS390, 24bitMode, notVolatile. notUsed, notSame,
operandsNotRelated, labelJTInRange, canAssign, optimizeReturn, notUsedFrom, labelIsReturnOnly, operandsLit-
eral, labelIsUncondJump, deadMove, useAcallAjmp and okToRemoveSLOC.
This whole thing is a little kludgy, but maybe some day SDCC will have some better means. If you are looking
at the peeph*.def files, you will see the default rules that are compiled into the compiler, you can add your own
rules in the default set there if you get tired of specifying the --peep-file option.
complexity = (number of edges in control flow graph) - (number of nodes in control flow graph) + 2;
Having said that the industry standard is 10, you should be aware that in some cases it be may unavoidable
to have a complexity level of less than 10. For example if you have switch statement with more than 10 case labels,
each case label adds one to the complexity level. The complexity level is by no means an absolute measure of
the algorithmic complexity of the function, it does however provide a good starting point for which functions you
might look at for further optimization.
• This phase does the bulk of the standard optimizations and is also MCU independent. This phase can be
broken down into several sub-phases:
118
8.3. RETARGETTING FOR OTHER PROCESSORS CHAPTER 8. SDCC TECHNICAL DATA
• This phase determines the live-ranges; by live range I mean those iTemp variables defined by the compiler
that still survive after all the optimizations. Live range analysis is essential for register allocation, since these
computation determines which of these iTemps will be assigned to registers, and for how long.
• Phase five is register allocation. For new ports register allocator described above in 8.1.15 should be used in
most cases, since it can result in substantially better code. In the old register allocator, there are two parts to
register allocation.
The first part I call ’register packing’ (for lack of a better term). In this case several MCU specific
expression folding is done to reduce register pressure.
The second part is more MCU independent and deals with allocating registers to the remaining live
ranges. A lot of MCU specific code does creep into this phase because of the limited number of index
registers available in the 8051.
• The Code generation phase is (unhappily), entirely MCU dependent and very little (if any at all) of this code
can be reused for other MCU. However the scheme for allocating a homogenized assembler operand for each
iCode operand may be reused.
• As mentioned in the optimization section the peep-hole optimizer is rule based system, which can repro-
grammed for other MCUs.
More information is available on SDCC Wiki (preliminary link http://sdcc.sourceforge.net/wiki/
index.php/SDCC_internals_and_porting) and in the thread http://sourceforge.net/
mailarchive/message.php?msg_id=13954144 .
119
Chapter 9
Compiler internals
The current version of SDCC can generate code for Intel 8051 and Z80 MCU. It is fairly easy to retarget
for other 8-bit MCU. Here we take a look at some of the internals of the compiler.
Parsing Parsing the input source file and creating an AST (Annotated Syntax Tree). This phase also involves
propagating types (annotating each node of the parse tree with type information) and semantic analysis. There are
some MCU specific parsing rules. For example the intrinsic named address spaces are MCU specific: While there
may be an __xdata intrinsic named address space for 8051 there none for z80. SDCC has MCU specific intrinsic
named address spacess, i.e. __xdata will be treated as a named address space when parsing 8051 C code but will
be treated as a C identifier when parsing z80 code.
Generating iCode Intermediate code generation. In this phase the AST is broken down into three-operand form
(iCode). These three operand forms are represented as doubly linked lists. ICode is the term given to the interme-
diate form generated by the compiler. ICode example section shows some examples of iCode generated for some
simple C source functions.
Optimizations. Bulk of the target independent optimizations is performed in this phase. The optimizations in-
clude constant propagation, common sub-expression elimination, loop invariant code movement, strength reduction
of loop induction variables and dead-code elimination.
Live range analysis During intermediate code generation phase, the compiler assumes the target machine has
infinite number of registers and generates a lot of temporary variables. The live range computation determines
the lifetime of each of these compiler-generated temporaries. A picture speaks a thousand words. ICode example
sections show the live range annotations for each of the operand. It is important to note here, each iCode is assigned
a number in the order of its execution in the function. The live ranges are computed in terms of these numbers.
The from number is the number of the iCode which first defines the operand and the to number signifies the iCode
which uses this operand last.
Register Allocation The register allocation determines the type and number of registers needed by each operand.
In most MCUs only a few registers can be used for indirect addressing. In case of 8051 for example the registers
R0 & R1 can be used to indirectly address the internal ram and DPTR to indirectly address the external ram. The
compiler will try to allocate the appropriate register to pointer variables if it can. ICode example section shows the
operands annotated with the registers assigned to them. The compiler will try to keep operands in registers as much
as possible; there are several schemes the compiler uses to do achieve this. When the compiler runs out of registers
the compiler will check to see if there are any live operands which is not used or defined in the current basic block
120
9.1. THE ANATOMY OF THE COMPILER CHAPTER 9. COMPILER INTERNALS
being processed, if there are any found then it will push that operand and use the registers in this block, the operand
will then be popped at the end of the basic block.
There are other MCU specific considerations in this phase. Some MCUs have an accumulator; very short-lived
operands could be assigned to the accumulator instead of a general-purpose register.
Code generation Figure II gives a table of iCode operations supported by the compiler. The code generation
involves translating these operations into corresponding assembly code for the processor. This sounds overly
simple but that is the essence of code generation. Some of the iCode operations are generated on a MCU specific
manner for example, the z80 port does not use registers to pass parameters so the SEND and RECV iCode
operations will not be generated, and it also does not support JUMPTABLES.
Figure II
121
9.1. THE ANATOMY OF THE COMPILER CHAPTER 9. COMPILER INTERNALS
122
9.1. THE ANATOMY OF THE COMPILER CHAPTER 9. COMPILER INTERNALS
ICode Example This section shows some details of iCode. The example C code does not do anything useful; it
is used as an example to illustrate the intermediate code generated by the compiler.
1. __xdata int * p;
2. int gint;
3. /* This function does nothing useful. It is used
4. for the purpose of explaining iCode */
5. short function (__data int *x)
6. {
7. short i=10; /* dead initialization eliminated */
8. short sum=10; /* dead initialization eliminated */
9. short mul;
10. int j ;
11. while (*x) *x++ = *p++;
12. sum = 0 ;
13. mul = 0;
14. /* compiler detects i,j to be induction variables */
15. for (i = 0, j = 10 ; i < 10 ; i++, j--) {
16. sum += i;
17. mul += i * 3; /* this multiplication remains */
18. gint += j * 3; /* this multiplication changed to addition
*/
19. }
20. return sum+mul;
21. }
In addition to the operands each iCode contains information about the filename and line it corresponds to in the
source file. The first field in the listing should be interpreted as follows:
Filename(linenumber: iCode Execution sequence number : ICode hash table key : loop depth of the iCode).
Then follows the human readable form of the ICode operation. Each operand of this triplet form can be of three
basic types a) compiler generated temporary b) user defined variable c) a constant value. Note that local variables
and parameters are replaced by compiler generated temporaries. Live ranges are computed only for temporaries
(i.e. live ranges are not computed for global variables). Registers are allocated for temporaries only. Operands are
formatted in the following manner:
Operand Name [lr live-from : live-to ] { type information } [ registers allocated ].
As mentioned earlier the live ranges are computed in terms of the execution sequence number of the iCodes, for
example
the iTemp0 is live from (i.e. first defined in iCode with execution sequence number 3, and is last used in the iCode
with sequence number 5). For induction variables such as iTemp21 the live range computation extends the lifetime
from the start to the end of the loop.
The register allocator used the live range information to allocate registers, the same registers may be used for
different temporaries if their live ranges do not overlap, for example r0 is allocated to both iTemp6 and to iTemp17
since their live ranges do not overlap. In addition the allocator also takes into consideration the type and usage
of a temporary, for example itemp6 is a pointer to near space and is used as to fetch data from (i.e. used in
GET_VALUE_AT_ADDRESS) so it is allocated a pointer register (r0). Some short lived temporaries are allocated
to special registers which have meaning to the code generator e.g. iTemp13 is allocated to a pseudo register CC
which tells the back end that the temporary is used only for a conditional jump the code generation makes use of
this information to optimize a compare and jump ICode.
There are several loop optimizations performed by the compiler. It can detect induction variables iTemp21(i)
and iTemp23(j). Also note the compiler does selective strength reduction, i.e. the multiplication of an induction
variable in line 18 (gint = j * 3) is changed to addition, a new temporary iTemp17 is allocated and assigned a initial
value, a constant 3 is then added for each iteration of the loop. The compiler does not change the multiplication in
line 17 however since the processor does support an 8 * 8 bit multiplication.
Note the dead code elimination optimization eliminated the dead assignments in line 7 & 8 to I and sum respectively.
123
9.1. THE ANATOMY OF THE COMPILER CHAPTER 9. COMPILER INTERNALS
Sample.c(11:4:53:0) preHeaderLbl0($11) :
Sample.c(11:5:55:0) iTemp6 [lr5:16]{_near * int}[r0] := iTemp0 [lr3:5]{_near * int}[r2]
Sample.c(11:6:5:1) _whilecontinue_0($1) :
Sample.c(11:7:7:1) iTemp4 [lr7:8]{int}[r2 r3] = @[iTemp6 [lr5:16]{_near * int}[r0]]
Sample.c(11:8:8:1) if iTemp4 [lr7:8]{int}[r2 r3] == 0 goto _whilebreak_0($3)
Sample.c(11:9:14:1) iTemp7 [lr9:13]{_far * int}[DPTR] := _p [lr0:0]{_far * int}
Sample.c(11:10:15:1) _p [lr0:0]{_far * int} = _p [lr0:0]{_far * int} + 0x2 {short}
Sample.c(11:13:18:1) iTemp10 [lr13:14]{int}[r2 r3] = @[iTemp7 [lr9:13]{_far * int}[DPTR]]
Sample.c(11:14:19:1) *(iTemp6 [lr5:16]{_near * int}[r0]) := iTemp10 [lr13:14]{int}[r2 r3]
Sample.c(11:15:12:1) iTemp6 [lr5:16]{_near * int}[r0] = iTemp6 [lr5:16]{_near * int}[r0] + 0x2 {short}
Sample.c(11:16:20:1) goto _whilecontinue_0($1)
Sample.c(11:17:21:0)_whilebreak_0($3) :
Sample.c(12:18:22:0) iTemp2 [lr18:40]{short}[r2] := 0x0 {short}
Sample.c(13:19:23:0) iTemp11 [lr19:40]{short}[r3] := 0x0 {short}
Sample.c(15:20:54:0)preHeaderLbl1($13) :
Sample.c(15:21:56:0) iTemp21 [lr21:38]{short}[r4] := 0x0 {short}
Sample.c(15:22:57:0) iTemp23 [lr22:38]{int}[r5 r6] := 0xa {int}
Sample.c(15:23:58:0) iTemp17 [lr23:38]{int}[r7 r0] := 0x1e {int}
Sample.c(15:24:26:1)_forcond_0($4) :
Sample.c(15:25:27:1) iTemp13 [lr25:26]{char}[CC] = iTemp21 [lr21:38]{short}[r4] < 0xa {short}
Sample.c(15:26:28:1) if iTemp13 [lr25:26]{char}[CC] == 0 goto _forbreak_0($7)
Sample.c(16:27:31:1) iTemp2 [lr18:40]{short}[r2] = iTemp2 [lr18:40]{short}[r2] + ITemp21 [lr21:38]{short}[r4]
Sample.c(17:29:33:1) iTemp15 [lr29:30]{short}[r1] = iTemp21 [lr21:38]{short}[r4] * 0x3 {short}
Sample.c(17:30:34:1) iTemp11 [lr19:40]{short}[r3] = iTemp11 [lr19:40]{short}[r3] + iTemp15 [lr29:30]{short}[r1]
Sample.c(18:32:36:1:1) iTemp17 [lr23:38]{int}[r7 r0]= iTemp17 [lr23:38]{int}[r7 r0]- 0x3 {short}
Sample.c(18:33:37:1) _gint [lr0:0]{int} = _gint [lr0:0]{int} + iTemp17 [lr23:38]{int}[r7 r0]
Sample.c(15:36:42:1) iTemp21 [lr21:38]{short}[r4] = iTemp21 [lr21:38]{short}[r4] + 0x1 {short}
Sample.c(15:37:45:1) iTemp23 [lr22:38]{int}[r5 r6]= iTemp23 [lr22:38]{int}[r5 r6]- 0x1 {short}
Sample.c(19:38:47:1) goto _forcond_0($4)
Sample.c(19:39:48:0)_forbreak_0($7) :
Sample.c(20:40:49:0) iTemp24 [lr40:41]{short}[DPTR] = iTemp2 [lr18:40]{short}[r2] + ITemp11 [lr19:40]{short}[r3]
Sample.c(20:41:50:0) ret iTemp24 [lr40:41]{short}
Sample.c(20:42:51:0)_return($8) :
Sample.c(20:43:52:0) eproc _function [lr0:0]{ ia0 re0 rm0}{function short}
124
9.1. THE ANATOMY OF THE COMPILER CHAPTER 9. COMPILER INTERNALS
clr a
addc a,(_p + 1)
mov (_p + 1),a
; iTemp10 [lr13:14]{int}[r2 r3] = @[iTemp7 [lr9:13]{_far * int}[DPTR]]
movx a,@dptr
mov r2,a
inc dptr
movx a,@dptr
mov r3,a
; *(iTemp6 [lr5:16]{_near * int}[r0]) := iTemp10 [lr13:14]{int}[r2 r3]
mov @r0,ar2
inc r0
mov @r0,ar3
; iTemp6 [lr5:16]{_near * int}[r0] =
; iTemp6 [lr5:16]{_near * int}[r0] +
; 0x2 {short}
inc r0
; goto _whilecontinue_0($1)
sjmp 00101$
; _whilebreak_0($3) :
00103$:
; iTemp2 [lr18:40]{short}[r2] := 0x0 {short}
mov r2,#0x00
; iTemp11 [lr19:40]{short}[r3] := 0x0 {short}
mov r3,#0x00
; iTemp21 [lr21:38]{short}[r4] := 0x0 {short}
mov r4,#0x00
; iTemp23 [lr22:38]{int}[r5 r6] := 0xa {int}
mov r5,#0x0A
mov r6,#0x00
; iTemp17 [lr23:38]{int}[r7 r0] := 0x1e {int}
mov r7,#0x1E
mov r0,#0x00
; _forcond_0($4) :
00104$:
; iTemp13 [lr25:26]{char}[CC] = iTemp21 [lr21:38]{short}[r4] < 0xa {short}
; if iTemp13 [lr25:26]{char}[CC] == 0 goto _forbreak_0($7)
clr c
mov a,r4
xrl a,#0x80
subb a,#0x8a
jnc 00107$
00115$:
; iTemp2 [lr18:40]{short}[r2] = iTemp2 [lr18:40]{short}[r2] +
; iTemp21 [lr21:38]{short}[r4]
mov a,r4
add a,r2
mov r2,a
; iTemp15 [lr29:30]{short}[r1] = iTemp21 [lr21:38]{short}[r4] * 0x3 {short}
mov b,#0x03
mov a,r4
mul ab
mov r1,a
; iTemp11 [lr19:40]{short}[r3] = iTemp11 [lr19:40]{short}[r3] +
; iTemp15 [lr29:30]{short}[r1]
add a,r3
mov r3,a
; iTemp17 [lr23:38]{int}[r7 r0]= iTemp17 [lr23:38]{int}[r7 r0]- 0x3 {short}
mov a,r7
add a,#0xfd
mov r7,a
mov a,r0
addc a,#0xff
mov r0,a
; _gint [lr0:0]{int} = _gint [lr0:0]{int} + iTemp17 [lr23:38]{int}[r7 r0]
mov a,r7
add a,_gint
mov _gint,a
mov a,r0
addc a,(_gint + 1)
mov (_gint + 1),a
125
9.2. A FEW WORDS ABOUT BASIC BLOCK SUCCESSORS, PREDECESSORS
CHAPTER 9.AND
COMPILER
DOMINATORS
INTERNALS
9.2 A few words about basic block successors, predecessors and domina-
tors
Successors are basic blocks that might execute after this basic block.
Predecessors are basic blocks that might execute before reaching this basic block.
Dominators are basic blocks that WILL execute before reaching this basic block.
[basic block 1]
if (something)
[basic block 2]
else
[basic block 3]
[basic block 4]
126
Chapter 10
Acknowledgments
http://sdcc.sourceforge.net/#Who
Thanks to all the other volunteer developers who have helped with coding, testing, web-page creation, dis-
tribution sets, etc. You know who you are :-)
Thanks to Sourceforge http://sourceforge.net/ which has hosted the project since 1999 and do-
nates significant download bandwidth.
Also thanks to all SDCC Distributed Compile Farm members for donating CPU cycles and bandwidth for
snapshot builds.
This document was initially written by Sandeep Dutta and updated by SDCC developers.
All product names mentioned herein may be trademarks of their respective companies.
Alphabetical index
To avoid confusion, the installation and building options for SDCC itself (chapter 2) are not part of the index.
127
Index
--Werror, 35 --noloopreverse, 33
--acall-ajmp, 37, 116 --nolospre, 33
--all-callee-saves, 34 --nooverlay, 33
--allow-unsafe-read, 33 --nostdinc, 35
--c1mode, 34 --nostdlib, 35
--callee-saves, 34, 69 --nostdlibcall, 33
--code-loc <Value>, 36, 43 --opt-code-size, 33
--code-size <Value>, 37, 43 --opt-code-speed, 33
--codeseg <Value>, 35 --out-fmt-ihx, 36
--compile-only, 34 --out-fmt-s19, 29, 37
--constseg <Value>, 36 --peep-asm, 33, 54
--cyclomatic, 34 --peep-file, 33, 115
--data-loc <Value>, 36, 43 --peep-return, 33
--debug, 30, 33, 34, 83, 95 --print-search-dirs, 23, 35
--disable-warning, 35 --stack-auto, 34, 38, 46, 48, 56, 59, 61
--dump-ast, 38 --stack-loc <Value>, 36, 43
--dump-graphs, 38 --stack-size <Value>, 37
--dump-i-code, 38 --std-c11, 10, 27
--dumpall, 105 --std-c2x, 10, 27
--fdollars-in-identifiers, 36 --std-c89, 10, 26, 35
--float-reent, 34 --std-c95, 27
--fomit-frame-pointer, 33 --std-c99, 10, 27
--fsigned-char, 35 --std-sdcc11, 35
--i-code-in-asm, 35 --std-sdcc2x, 35
--idata-loc <Value>, 36 --std-sdcc89, 35
--int-long-reent, 34, 48, 56 --std-sdcc99, 35
--iram-size <Value>, 37, 43, 68 --use-non-free, 8, 36, 78, 84, 85
--less-pedantic, 35 --use-stdout, 35, 39
--lib-path <path>, 36 --vc, 35, 39
--max-allocs-per-node, 33 --verbose, 35
--model-huge, 37 --version, 34
--model-large, 37, 38, 57 --xdata-loc<Value>, 43
--model-medium, 37, 38 --xram-loc <Value>, 36
--model-small, 37 --xram-size <Value>, 37, 43
--more-pedantic, 36 --xstack, 37, 38, 40, 59
--no-c-code-in-asm, 35 --xstack-loc <Value>, 36
--no-gen-comments, 38 -Aquestion(answer), 32
--no-peep, 33 -C, 32
--no-peep-comments, 35 -D<macro[=value]>, 32
--no-peep-return, 33 -E, 32, 34
--no-ret-without-call, 37 -I<path>, 32
--no-std-crt0, 71 -L <path>, 36
--no-xinit-opt, 33, 68 -M, 32
--nogcse, 33 -MM, 32
--noinduction, 33 -S, 34
--noinvariant, 33 -Umacro, 32
--nolabelopt, 33 -V, 35
128
INDEX INDEX
129
INDEX INDEX
critical, 50 Options
__critical, 50 -ba <Num>, 38
Cyclomatic complexity, 34, 117 -bo <Num>, 38
gcc (GNU Compiler Collection), 32
d52, 103 gdb, 95
d52 (disassembler), 103 generic pointer, 69
__data (hc08 named address space), 43 getchar(), 57
__data (mcs51, ds390 named address space), 36, 40, 42 GPLv2 license, 9
DDD (debugger), 98, 103 GPLv2+LE, 8, 59
Dead-code elimination, 108, 122 GPLv3 license, 9
Debugger, 30, 95 gpsim (pic simulator), 103
#defines, 63 gputils (pic tools), 77, 103
Defines created by the compiler, 63
DESTDIR, 16 HC08, 31, 37, 43, 49, 74
Division, 47 interrupt, 49, 51
Documentation, 22, 102 Options
double (not supported), 26 --out-fmt-elf, 37
download, 105 HD64180 (see Z180), 43
doxygen (source documentation tool), 103 Header files, 41, 101, 102
DPTR, 65, 69, 113 heap (malloc), 58
DPTR, DPH, DPL, 69 Higher Order Byte, 114
DS390, 37 Higher Order Word, 114
Options
--model-flat24, 37 I/O memory (Z80, Z180), 43
--protect-sp-update, 37 ICE (in circuit emulator), 94
--stack-10bit, 37 iCode, 38, 119–122
--stack-probe, 38 __idata (mcs51, ds390 named address space), 36, 40, 42
--tini-libid, 38 IDE, 35, 104
--use-accelerator, 38 Include files, 41, 101, 102
DS390 memory model, 59 indent (source formatting tool), 103
DS400, 71 Infineon, 37
DS80C390, 31 Install paths, 15
DS80C400, 31, 71, 104 Install trouble-shooting, 23
DS89C4x0, 104 Installation, 13
dynamic memory allocation (malloc), 58 instruction cycles (count), 103
Intel hex format, 29, 30, 36, 95
ELF format, 37 Intermediate dump options, 38
Emacs, 98 interrupt, 42, 47, 48, 50–52, 54, 56, 60, 61
__endasm, 51, 53–56 __interrupt, 42, 48, 54
Endianness, 101, 113 interrupt jitter, 51
Environment variables, 39 interrupt latency, 51
Examples, 107 interrupt mask, 51
External stack (mcs51), 59 interrupt priority, 51, 52
interrupt vector table, 36, 48, 61
__far (named address space), 40, 52 interrupts, 52
Feature request, 106 intrinsic named address space, 47, 59
Flags, 41
Flat 24 (DS390 memory model), 59 jump tables, 110
Floating point support, 26, 48, 56–58
FPGA (field programmable gate array), 22 K&R style, 26
FpgaC ((subset of) C to FPGA compiler), 22
function epilogue, 34, 54 Labels, 55
function parameter, 46, 47, 69, 70 LGPLv2.1 license, 9
function pointer, 42 Libraries, 31, 35, 36, 42, 57, 59
function pointers, 69 Linker, 30
function prologue, 34, 54, 60 Linker documentation, 102
Linker options, 36
GBZ80 lint (syntax checking tool), 36, 94
130
INDEX INDEX
131
INDEX INDEX
132
INDEX INDEX
uCsim, 102
union, 26
UnxUtils, 20
USE_FLOATS, 57
using (mcs51, ds390 register bank), 49, 51
__using (mcs51, ds390 register bank), 42, 48, 49, 51
Warnings, 35
watchdog, 68, 101
wiki, 103, 106, 118
Z180, 31, 43
I/O memory, 43
Options
--portmode, 43
Pragmas
#pragma portmode, 43
Z80, 31, 38, 43, 49, 71
133