1 #LyX 1.2 created this file. For more info see http://www.lyx.org/
15 \use_numerical_citations 0
16 \paperorientation portrait
19 \paragraph_separation indent
21 \quotes_language swedish
29 Please note: double dashed longoptions (e.g.
30 --version) need three dashes in this document to be visable in html and
34 SDCC Compiler User Guide
38 \begin_inset LatexCommand \tableofcontents{}
55 is a Freeware, retargettable, optimizing ANSI-C compiler by
59 designed for 8 bit Microprocessors.
60 The current version targets Intel MCS51 based Microprocessors(8051,8052,
61 etc), Zilog Z80 based MCUs, and the Dallas DS80C390 variant.
62 It can be retargetted for other microprocessors, support for PIC, AVR and
63 186 is under development.
64 The entire source code for the compiler is distributed under GPL.
65 SDCC uses ASXXXX & ASLINK, a Freeware, retargettable assembler & linker.
66 SDCC has extensive language extensions suitable for utilizing various microcont
67 rollers and underlying hardware effectively.
72 In addition to the MCU specific optimizations SDCC also does a host of standard
76 global sub expression elimination,
79 loop optimizations (loop invariant, strength reduction of induction variables
83 constant folding & propagation,
99 For the back-end SDCC uses a global register allocation scheme which should
100 be well suited for other 8 bit MCUs.
105 The peep hole optimizer uses a rule based substitution mechanism which is
111 Supported data-types are:
114 char (8 bits, 1 byte),
117 short and int (16 bits, 2 bytes),
120 long (32 bit, 4 bytes)
127 The compiler also allows
129 inline assembler code
131 to be embedded anywhere in a function.
132 In addition, routines developed in assembly can also be called.
136 SDCC also provides an option (--cyclomatic) to report the relative complexity
138 These functions can then be further optimized, or hand coded in assembly
144 SDCC also comes with a companion source level debugger SDCDB, the debugger
145 currently uses ucSim a freeware simulator for 8051 and other micro-controllers.
150 The latest version can be downloaded from
151 \begin_inset LatexCommand \url{http://sdcc.sourceforge.net/}
163 All packages used in this compiler system are
171 ; source code for all the sub-packages (pre-processor, assemblers, linkers
172 etc) is distributed with the package.
173 This documentation is maintained using a freeware word processor (LyX).
175 This program is free software; you can redistribute it and/or modify it
176 under the terms of the GNU General Public License as published by the Free
177 Software Foundation; either version 2, or (at your option) any later version.
178 This program is distributed in the hope that it will be useful, but WITHOUT
179 ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
180 FOR A PARTICULAR PURPOSE.
181 See the GNU General Public License for more details.
182 You should have received a copy of the GNU General Public License along
183 with this program; if not, write to the Free Software Foundation, 59 Temple
184 Place - Suite 330, Boston, MA 02111-1307, USA.
185 In other words, you are welcome to use, share and improve this program.
186 You are forbidden to forbid anyone else to use, share and improve what
188 Help stamp out software-hoarding!
191 Typographic conventions
194 Throughout this manual, we will use the following convention.
195 Commands you have to type in are printed in
203 Code samples are printed in
208 Interesting items and new terms are printed in
213 Compatibility with previous versions
216 This version has numerous bug fixes compared with the previous version.
217 But we also introduced some incompatibilities with older versions.
218 Not just for the fun of it, but to make the compiler more stable, efficient
225 short is now equivalent to int (16 bits), it used to be equivalent to char
226 (8 bits) which is not ANSI compliant
229 the default directory for gcc-builds where include, library and documention
230 files are stored is now in /usr/local/share
233 char type parameters to vararg functions are casted to int unless explicitly
250 will push a as an int and as a char resp.
253 option ---regextend has been removed
256 option ---noregparms has been removed
259 option ---stack-after-data has been removed
264 <pending: more incompatibilities?>
270 What do you need before you start installation of SDCC? A computer, and
272 The preferred method of installation is to compile SDCC from source using
274 For Windows some pre-compiled binary distributions are available for your
276 You should have some experience with command line tools and compiler use.
282 The SDCC home page at
283 \begin_inset LatexCommand \url{http://sdcc.sourceforge.net/}
287 is a great place to find distribution sets.
288 You can also find links to the user mailing lists that offer help or discuss
289 SDCC with other SDCC users.
290 Web links to other SDCC related sites can also be found here.
291 This document can be found in the DOC directory of the source package as
293 Some of the other tools (simulator and assembler) included with SDCC contain
294 their own documentation and can be found in the source distribution.
295 If you want the latest unreleased software, the complete source package
296 is available directly by anonymous CVS on cvs.sdcc.sourceforge.net.
299 Wishes for the future
302 There are (and always will be) some things that could be done.
303 Here are some I can think of:
310 char KernelFunction3(char p) at 0x340;
316 If you can think of some more, please send them to the list.
322 <pending: And then of course a proper index-table
323 \begin_inset LatexCommand \index{index}
336 The install paths and default search paths are defined when running 'configure'.
337 The defaults can be overriden by
345 These configure variables are compiled into the binaries, and can only be
346 changed by rerunning 'configure' and recompiling SDCC.
347 The configure variables are written in
351 to distinguish them from run time environment variables (see section search
356 Cygwin is handled like a *nix, Mingw32 however belongs to the Win32 builds.
357 The SDCC team uses Mingw32 to build the official Windows binaries, because
364 a gcc compiler and last but not least
367 the binaries can be built by cross compiling on Sourceforge's compile farm.
370 The other Win32 builds using Borland, VC or whatever don't use 'configure',
371 but they (hopefully) use the default Win32 paths.
381 <lyxtabular version="3" rows="8" columns="3">
383 <column alignment="left" valignment="top" leftline="true" width="0in">
384 <column alignment="left" valignment="top" leftline="true" width="0in">
385 <column alignment="left" valignment="top" leftline="true" rightline="true" width="0in">
386 <row topline="true" bottomline="true">
387 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
395 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
403 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
413 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
423 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
431 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
443 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
453 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
463 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
475 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
485 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
497 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
513 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
523 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
535 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
547 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
557 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
569 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
585 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
595 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
603 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
612 <row topline="true" bottomline="true">
613 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
623 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
631 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
650 'configure' also computes relative paths.
651 This is needed for full relocatability of a binary package and to complete
652 search paths (see section search paths below):
658 <lyxtabular version="3" rows="4" columns="3">
660 <column alignment="left" valignment="top" leftline="true" width="0in">
661 <column alignment="left" valignment="top" leftline="true" width="0in">
662 <column alignment="left" valignment="top" leftline="true" rightline="true" width="0in">
663 <row topline="true" bottomline="true">
664 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
672 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
680 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
689 <row topline="true" bottomline="true">
690 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
700 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
708 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
719 <row bottomline="true">
720 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
730 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
738 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
747 <row bottomline="true">
748 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
758 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
766 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
785 Binary files (preprocessor, assembler and linker)
790 <lyxtabular version="3" rows="2" columns="3">
792 <column alignment="left" valignment="top" leftline="true" width="0in">
793 <column alignment="left" valignment="top" leftline="true" width="0in">
794 <column alignment="left" valignment="top" leftline="true" rightline="true" width="0in">
795 <row topline="true" bottomline="true">
796 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
804 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
812 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
821 <row topline="true" bottomline="true">
822 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
832 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
840 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
867 <lyxtabular version="3" rows="2" columns="3">
869 <column alignment="block" valignment="top" leftline="true" width="1.6in">
870 <column alignment="center" valignment="top" leftline="true" width="0in">
871 <column alignment="center" valignment="top" leftline="true" rightline="true" width="0in">
872 <row topline="true" bottomline="true">
873 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
881 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
889 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
898 <row topline="true" bottomline="true">
899 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
911 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
916 /usr/local/share/sdcc/include
919 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
945 is auto-appended by the compiler, e.g.
946 small, large, z80, ds390 etc.)
951 <lyxtabular version="3" rows="2" columns="3">
953 <column alignment="left" valignment="top" leftline="true" width="0in">
954 <column alignment="left" valignment="top" leftline="true" width="0in">
955 <column alignment="left" valignment="top" leftline="true" rightline="true" width="0in">
956 <row topline="true" bottomline="true">
957 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
965 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
973 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
982 <row topline="true" bottomline="true">
983 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
990 $DATADIR/$LIB_DIR_SUFFIX
993 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
998 /usr/local/share/sdcc/lib
1001 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1027 \begin_inset Tabular
1028 <lyxtabular version="3" rows="2" columns="3">
1030 <column alignment="left" valignment="top" leftline="true" width="0in">
1031 <column alignment="left" valignment="top" leftline="true" width="0in">
1032 <column alignment="left" valignment="top" leftline="true" rightline="true" width="0in">
1033 <row topline="true" bottomline="true">
1034 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1042 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1050 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1059 <row topline="true" bottomline="true">
1060 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1070 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1075 /usr/local/share/sdcc/doc
1078 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1101 Some search paths or parts of them are determined by configure variables
1106 , see section above).
1107 Further search paths are determined by environment variables during runtime.
1110 The paths searched when running the compiler are as follows (the first catch
1116 Binary files (preprocessor, assembler and linker)
1119 \begin_inset Tabular
1120 <lyxtabular version="3" rows="4" columns="3">
1122 <column alignment="left" valignment="top" leftline="true" width="0in">
1123 <column alignment="left" valignment="top" leftline="true" width="0in">
1124 <column alignment="left" valignment="top" leftline="true" rightline="true" width="0in">
1125 <row topline="true" bottomline="true">
1126 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1134 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1142 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1151 <row topline="true">
1152 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1162 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1170 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1181 <row topline="true">
1182 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1187 Path of argv[0] (if available)
1190 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1198 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1207 <row topline="true" bottomline="true">
1208 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1216 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1224 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1245 \begin_inset Tabular
1246 <lyxtabular version="3" rows="6" columns="3">
1248 <column alignment="block" valignment="top" leftline="true" width="1.5in">
1249 <column alignment="block" valignment="top" leftline="true" width="1.5in">
1250 <column alignment="left" valignment="top" leftline="true" rightline="true" width="0in">
1251 <row topline="true" bottomline="true">
1252 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1260 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1268 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1277 <row topline="true">
1278 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1286 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1294 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1303 <row topline="true">
1304 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
1312 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1320 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1329 <row topline="true">
1330 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
1344 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
1356 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1367 <row topline="true">
1368 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
1386 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1436 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1449 <row topline="true" bottomline="true">
1450 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
1466 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
1471 /usr/local/share/sdcc/
1476 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1493 The option ---nostdinc disables the last two search paths.
1500 With the exception of
1501 \begin_inset Quotes sld
1505 \begin_inset Quotes srd
1512 is auto-appended by the compiler (e.g.
1513 small, large, z80, ds390 etc.).
1517 \begin_inset Tabular
1518 <lyxtabular version="3" rows="6" columns="3">
1520 <column alignment="block" valignment="top" leftline="true" width="1.7in">
1521 <column alignment="left" valignment="top" leftline="true" width="1.2in">
1522 <column alignment="block" valignment="top" leftline="true" rightline="true" width="1.2in">
1523 <row topline="true" bottomline="true">
1524 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
1532 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
1540 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1549 <row topline="true">
1550 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
1558 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1566 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1575 <row topline="true">
1576 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1588 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
1600 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1615 <row topline="true">
1616 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
1627 $LIB_DIR_SUFFIX/<model>
1630 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
1644 <cell alignment="left" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1661 <row topline="true">
1662 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
1677 $LIB_DIR_SUFFIX/<model>
1680 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
1733 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1789 <row topline="true" bottomline="true">
1790 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1799 $LIB_DIR_SUFFIX/<model>
1802 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1807 /usr/local/share/sdcc/
1814 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1830 Don't delete any of the stray spaces in the table above without checking
1831 the HTML output (last line)!
1837 The option ---nostdlib disables the last two search paths.
1840 Linux and other gcc-based systems (cygwin, mingw32, osx)
1845 Download the source package
1847 either from the SDCC CVS repository or from the
1848 \begin_inset LatexCommand \url[nightly snapshots]{http://sdcc.sourceforge.net/snap.php}
1854 , it will be named something like sdcc
1867 Bring up a command line terminal, such as xterm.
1872 Unpack the file using a command like:
1875 "tar -xzf sdcc.src.tar.gz
1880 , this will create a sub-directory called sdcc with all of the sources.
1883 Change directory into the main SDCC directory, for example type:
1900 This configures the package for compilation on your system.
1916 All of the source packages will compile, this can take a while.
1932 This copies the binary executables, the include files, the libraries and
1933 the documentation to the install directories.
1936 On OSX 2.x it was reported, that the default gcc (version 3.1 20020420 (prerelease
1937 )) fails to compile SDCC.
1938 Fortunately there's also gcc 2.9.x installed, which works fine.
1939 This compiler can be selected by running 'configure' with:
1942 ./configure CC=gcc2 CXX=g++2
1946 \layout Subsubsection
1948 Windows Install Using a Binary Package
1951 Download the binary package and unpack it using your favorite unpacking
1952 tool (gunzip, WinZip, etc).
1953 This should unpack to a group of sub-directories.
1954 An example directory structure after unpacking the mingw32 package is:
1961 bin for the executables, c:
1981 lib for the include and libraries.
1984 Adjust your environment variable PATH to include the location of the bin
1985 directory or start sdcc using the full path.
1986 \layout Subsubsection
1988 Windows Install Using Cygwin and Mingw32
1991 Follow the instruction in
1993 Linux and other gcc-based systems
1996 \layout Subsubsection
1998 Windows Install Using Microsoft Visual C++ 6.0/NET
2003 Download the source package
2005 either from the SDCC CVS repository or from the
2006 \begin_inset LatexCommand \url[nightly snapshots]{http://sdcc.sourceforge.net/snap.php}
2012 , it will be named something like sdcc
2019 SDCC is distributed with all the projects, workspaces, and files you need
2020 to build it using Visual C++ 6.0/NET.
2021 The workspace name is 'sdcc.dsw'.
2022 Please note that as it is now, all the executables are created in a folder
2026 Once built you need to copy the executables from sdcc
2030 bin before runnng SDCC.
2035 In order to build SDCC with Visual C++ 6.0/NET you need win32 executables
2036 of bison.exe, flex.exe, and gawk.exe.
2037 One good place to get them is
2038 \begin_inset LatexCommand \url[here]{http://unxutils.sourceforge.net}
2046 Download the file UnxUtils.zip.
2047 Now you have to install the utilities and setup Visual C++ so it can locate
2048 the required programs.
2049 Here there are two alternatives (choose one!):
2056 a) Extract UnxUtils.zip to your C:
2058 hard disk PRESERVING the original paths, otherwise bison won't work.
2059 (If you are using WinZip make certain that 'Use folder names' is selected)
2063 b) In the Visual C++ IDE click Tools, Options, select the Directory tab,
2064 in 'Show directories for:' select 'Executable files', and in the directories
2065 window add a new path: 'C:
2075 (As a side effect, you get a bunch of Unix utilities that could be useful,
2076 such as diff and patch.)
2083 This one avoids extracting a bunch of files you may not use, but requires
2088 a) Create a directory were to put the tools needed, or use a directory already
2096 b) Extract 'bison.exe', 'bison.hairy', 'bison.simple', 'flex.exe', and gawk.exe
2097 to such directory WITHOUT preserving the original paths.
2098 (If you are using WinZip make certain that 'Use folder names' is not selected)
2102 c) Rename bison.exe to '_bison.exe'.
2106 d) Create a batch file 'bison.bat' in 'C:
2110 ' and add these lines:
2130 _bison %1 %2 %3 %4 %5 %6 %7 %8 %9
2134 Steps 'c' and 'd' are needed because bison requires by default that the
2135 files 'bison.simple' and 'bison.hairy' reside in some weird Unix directory,
2136 '/usr/local/share/' I think.
2137 So it is necessary to tell bison where those files are located if they
2138 are not in such directory.
2139 That is the function of the environment variables BISON_SIMPLE and BISON_HAIRY.
2143 e) In the Visual C++ IDE click Tools, Options, select the Directory tab,
2144 in 'Show directories for:' select 'Executable files', and in the directories
2145 window add a new path: 'c:
2148 Note that you can use any other path instead of 'c:
2150 util', even the path where the Visual C++ tools are, probably: 'C:
2154 Microsoft Visual Studio
2159 So you don't have to execute step 'e' :)
2163 Open 'sdcc.dsw' in Visual Studio, click 'build all', when it finishes copy
2164 the executables from sdcc
2168 bin, and you can compile using sdcc.
2169 \layout Subsubsection
2171 Windows Install Using Borland
2174 From the sdcc directory, run the command "make -f Makefile.bcc".
2175 This should regenerate all the .exe files in the bin directory except for
2176 sdcdb.exe (which currently doesn't build under Borland C++).
2179 If you modify any source files and need to rebuild, be aware that the dependanci
2180 es may not be correctly calculated.
2181 The safest option is to delete all .obj files and run the build again.
2182 From a Cygwin BASH prompt, this can easily be done with the commmand:
2192 ( -name '*.obj' -o -name '*.lib' -o -name '*.rul'
2194 ) -print -exec rm {}
2203 or on Windows NT/2000/XP from the command prompt with the commmand:
2210 del /s *.obj *.lib *.rul
2213 from the sdcc directory.
2216 Testing out the SDCC Compiler
2219 The first thing you should do after installing your SDCC compiler is to
2227 at the prompt, and the program should run and tell you the version.
2228 If it doesn't run, or gives a message about not finding sdcc program, then
2229 you need to check over your installation.
2230 Make sure that the sdcc bin directory is in your executable search path
2231 defined by the PATH environment setting (see the Trouble-shooting section
2233 Make sure that the sdcc program is in the bin folder, if not perhaps something
2234 did not install correctly.
2242 is commonly installed as described in section
2243 \begin_inset Quotes sld
2246 Install and search paths
2247 \begin_inset Quotes srd
2256 Make sure the compiler works on a very simple example.
2257 Type in the following test.c program using your favorite
2292 Compile this using the following command:
2301 If all goes well, the compiler will generate a test.asm and test.rel file.
2302 Congratulations, you've just compiled your first program with SDCC.
2303 We used the -c option to tell SDCC not to link the generated code, just
2304 to keep things simple for this step.
2312 The next step is to try it with the linker.
2322 If all goes well the compiler will link with the libraries and produce
2323 a test.ihx output file.
2328 (no test.ihx, and the linker generates warnings), then the problem is most
2329 likely that sdcc cannot find the
2333 usr/local/share/sdcc/lib directory
2337 (see the Install trouble-shooting section for suggestions).
2345 The final test is to ensure sdcc can use the
2349 header files and libraries.
2350 Edit test.c and change it to the following:
2370 strcpy(str1, "testing");
2379 Compile this by typing
2386 This should generate a test.ihx output file, and it should give no warnings
2387 such as not finding the string.h file.
2388 If it cannot find the string.h file, then the problem is that sdcc cannot
2389 find the /usr/local/share/sdcc/include directory
2393 (see the Install trouble-shooting section for suggestions).
2396 Install Trouble-shooting
2397 \layout Subsubsection
2399 SDCC does not build correctly.
2402 A thing to try is starting from scratch by unpacking the .tgz source package
2403 again in an empty directory.
2411 ./configure 2>&1 | tee configure.log
2425 make 2>&1 | tee make.log
2432 If anything goes wrong, you can review the log files to locate the problem.
2433 Or a relevant part of this can be attached to an email that could be helpful
2434 when requesting help from the mailing list.
2435 \layout Subsubsection
2438 \begin_inset Quotes sld
2442 \begin_inset Quotes srd
2449 \begin_inset Quotes sld
2453 \begin_inset Quotes srd
2456 command is a script that analyzes your system and performs some configuration
2457 to ensure the source package compiles on your system.
2458 It will take a few minutes to run, and will compile a few tests to determine
2459 what compiler features are installed.
2460 \layout Subsubsection
2463 \begin_inset Quotes sld
2467 \begin_inset Quotes srd
2473 This runs the GNU make tool, which automatically compiles all the source
2474 packages into the final installed binary executables.
2475 \layout Subsubsection
2478 \begin_inset Quotes sld
2482 \begin_inset Quotes erd
2488 This will install the compiler, other executables libraries and include
2489 files in to the appropriate directories.
2491 \begin_inset Quotes sld
2494 Install and Search PATHS
2495 \begin_inset Quotes srd
2500 On most systems you will need super-user privilages to do this.
2506 SDCC is not just a compiler, but a collection of tools by various developers.
2507 These include linkers, assemblers, simulators and other components.
2508 Here is a summary of some of the components.
2509 Note that the included simulator and assembler have separate documentation
2510 which you can find in the source package in their respective directories.
2511 As SDCC grows to include support for other processors, other packages from
2512 various developers are included and may have their own sets of documentation.
2516 You might want to look at the files which are installed in <installdir>.
2517 At the time of this writing, we find the following programs for gcc-builds:
2521 In <installdir>/bin:
2524 sdcc - The compiler.
2527 sdcpp - The C preprocessor.
2530 asx8051 - The assembler for 8051 type processors.
2537 as-gbz80 - The Z80 and GameBoy Z80 assemblers.
2540 aslink -The linker for 8051 type processors.
2547 link-gbz80 - The Z80 and GameBoy Z80 linkers.
2550 s51 - The ucSim 8051 simulator.
2553 sdcdb - The source debugger.
2556 packihx - A tool to pack (compress) Intel hex files.
2559 In <installdir>/share/sdcc/include
2565 In <installdir>/share/sdcc/lib
2568 the subdirs src and small, large, z80, gbz80 and ds390 with the precompiled
2572 In <installdir>/share/sdcc/doc
2578 As development for other processors proceeds, this list will expand to include
2579 executables to support processors like AVR, PIC, etc.
2580 \layout Subsubsection
2585 This is the actual compiler, it in turn uses the c-preprocessor and invokes
2586 the assembler and linkage editor.
2587 \layout Subsubsection
2589 sdcpp - The C-Preprocessor
2592 The preprocessor is a modified version of the GNU preprocessor.
2593 The C preprocessor is used to pull in #include sources, process #ifdef
2594 statements, #defines and so on.
2595 \layout Subsubsection
2597 asx8051, as-z80, as-gbz80, aslink, link-z80, link-gbz80 - The Assemblers
2601 This is retargettable assembler & linkage editor, it was developed by Alan
2603 John Hartman created the version for 8051, and I (Sandeep) have made some
2604 enhancements and bug fixes for it to work properly with the SDCC.
2605 \layout Subsubsection
2610 S51 is a freeware, opensource simulator developed by Daniel Drotos (
2611 \begin_inset LatexCommand \url{mailto:drdani@mazsola.iit.uni-miskolc.hu}
2616 The simulator is built as part of the build process.
2617 For more information visit Daniel's website at:
2618 \begin_inset LatexCommand \url{http://mazsola.iit.uni-miskolc.hu/~drdani/embedded/s51}
2623 It currently support the core mcs51, the Dallas DS80C390 and the Philips
2625 \layout Subsubsection
2627 sdcdb - Source Level Debugger
2633 <todo: is this thing still alive?>
2640 Sdcdb is the companion source level debugger.
2641 The current version of the debugger uses Daniel's Simulator S51, but can
2642 be easily changed to use other simulators.
2649 \layout Subsubsection
2651 Single Source File Projects
2654 For single source file 8051 projects the process is very simple.
2655 Compile your programs with the following command
2658 "sdcc sourcefile.c".
2662 This will compile, assemble and link your source file.
2663 Output files are as follows
2667 sourcefile.asm - Assembler source file created by the compiler
2669 sourcefile.lst - Assembler listing file created by the Assembler
2671 sourcefile.rst - Assembler listing file updated with linkedit information,
2672 created by linkage editor
2674 sourcefile.sym - symbol listing for the sourcefile, created by the assembler
2676 sourcefile.rel - Object file created by the assembler, input to Linkage editor
2678 sourcefile.map - The memory map for the load module, created by the Linker
2680 sourcefile.ihx - The load module in Intel hex format (you can select the
2681 Motorola S19 format with ---out-fmt-s19)
2683 sourcefile.cdb - An optional file (with ---debug) containing debug information
2685 sourcefile.dump* - Dump file to debug the compiler it self (with ---dumpall)
2687 \begin_inset Quotes sld
2690 Anatomy of the compiler
2691 \begin_inset Quotes srd
2695 \layout Subsubsection
2697 Projects with Multiple Source Files
2700 SDCC can compile only ONE file at a time.
2701 Let us for example assume that you have a project containing the following
2706 foo1.c (contains some functions)
2708 foo2.c (contains some more functions)
2710 foomain.c (contains more functions and the function main)
2718 The first two files will need to be compiled separately with the commands:
2750 Then compile the source file containing the
2754 function and link the files together with the following command:
2762 foomain.c\SpecialChar ~
2763 foo1.rel\SpecialChar ~
2775 can be separately compiled as well:
2786 sdcc foomain.rel foo1.rel foo2.rel
2793 The file containing the
2808 file specified in the command line, since the linkage editor processes
2809 file in the order they are presented to it.
2810 \layout Subsubsection
2812 Projects with Additional Libraries
2815 Some reusable routines may be compiled into a library, see the documentation
2816 for the assembler and linkage editor (which are in <installdir>/share/sdcc/doc)
2822 Libraries created in this manner can be included in the command line.
2823 Make sure you include the -L <library-path> option to tell the linker where
2824 to look for these files if they are not in the current directory.
2825 Here is an example, assuming you have the source file
2837 (if that is not the same as your current project):
2844 sdcc foomain.c foolib.lib -L mylib
2855 must be an absolute path name.
2859 The most efficient way to use libraries is to keep seperate modules in seperate
2861 The lib file now should name all the modules.rel files.
2862 For an example see the standard library file
2866 in the directory <installdir>/share/lib/small.
2869 Command Line Options
2870 \layout Subsubsection
2872 Processor Selection Options
2874 \labelwidthstring 00.00.0000
2880 Generate code for the MCS51 (8051) family of processors.
2881 This is the default processor target.
2883 \labelwidthstring 00.00.0000
2889 Generate code for the DS80C390 processor.
2891 \labelwidthstring 00.00.0000
2897 Generate code for the Z80 family of processors.
2899 \labelwidthstring 00.00.0000
2905 Generate code for the GameBoy Z80 processor.
2907 \labelwidthstring 00.00.0000
2913 Generate code for the Atmel AVR processor (In development, not complete).
2915 \labelwidthstring 00.00.0000
2921 Generate code for the PIC 14-bit processors (In development, not complete).
2923 \labelwidthstring 00.00.0000
2929 Generate code for the Toshiba TLCS-900H processor (In development, not
2932 \labelwidthstring 00.00.0000
2938 Generate code for the Philips XA51 processor (In development, not complete).
2939 \layout Subsubsection
2941 Preprocessor Options
2943 \labelwidthstring 00.00.0000
2949 The additional location where the pre processor will look for <..h> or
2950 \begin_inset Quotes eld
2954 \begin_inset Quotes erd
2959 \labelwidthstring 00.00.0000
2965 Command line definition of macros.
2966 Passed to the pre processor.
2968 \labelwidthstring 00.00.0000
2974 Tell the preprocessor to output a rule suitable for make describing the
2975 dependencies of each object file.
2976 For each source file, the preprocessor outputs one make-rule whose target
2977 is the object file name for that source file and whose dependencies are
2978 all the files `#include'd in it.
2979 This rule may be a single line or may be continued with `
2981 '-newline if it is long.
2982 The list of rules is printed on standard output instead of the preprocessed
2986 \labelwidthstring 00.00.0000
2992 Tell the preprocessor not to discard comments.
2993 Used with the `-E' option.
2995 \labelwidthstring 00.00.0000
3006 Like `-M' but the output mentions only the user header files included with
3008 \begin_inset Quotes eld
3012 System header files included with `#include <file>' are omitted.
3014 \labelwidthstring 00.00.0000
3020 Assert the answer answer for question, in case it is tested with a preprocessor
3021 conditional such as `#if #question(answer)'.
3022 `-A-' disables the standard assertions that normally describe the target
3025 \labelwidthstring 00.00.0000
3031 (answer) Assert the answer answer for question, in case it is tested with
3032 a preprocessor conditional such as `#if #question(answer)'.
3033 `-A-' disables the standard assertions that normally describe the target
3036 \labelwidthstring 00.00.0000
3042 Undefine macro macro.
3043 `-U' options are evaluated after all `-D' options, but before any `-include'
3044 and `-imacros' options.
3046 \labelwidthstring 00.00.0000
3052 Tell the preprocessor to output only a list of the macro definitions that
3053 are in effect at the end of preprocessing.
3054 Used with the `-E' option.
3056 \labelwidthstring 00.00.0000
3062 Tell the preprocessor to pass all macro definitions into the output, in
3063 their proper sequence in the rest of the output.
3065 \labelwidthstring 00.00.0000
3076 Like `-dD' except that the macro arguments and contents are omitted.
3077 Only `#define name' is included in the output.
3078 \layout Subsubsection
3082 \labelwidthstring 00.00.0000
3092 <absolute path to additional libraries> This option is passed to the linkage
3093 editor's additional libraries search path.
3094 The path name must be absolute.
3095 Additional library files may be specified in the command line.
3096 See section Compiling programs for more details.
3098 \labelwidthstring 00.00.0000
3104 <Value> The start location of the external ram, default value is 0.
3105 The value entered can be in Hexadecimal or Decimal format, e.g.: ---xram-loc
3106 0x8000 or ---xram-loc 32768.
3108 \labelwidthstring 00.00.0000
3114 <Value> The start location of the code segment, default value 0.
3115 Note when this option is used the interrupt vector table is also relocated
3116 to the given address.
3117 The value entered can be in Hexadecimal or Decimal format, e.g.: ---code-loc
3118 0x8000 or ---code-loc 32768.
3120 \labelwidthstring 00.00.0000
3126 <Value> By default the stack is placed after the data segment.
3127 Using this option the stack can be placed anywhere in the internal memory
3129 The value entered can be in Hexadecimal or Decimal format, e.g.
3130 ---stack-loc 0x20 or ---stack-loc 32.
3131 Since the sp register is incremented before a push or call, the initial
3132 sp will be set to one byte prior the provided value.
3133 The provided value should not overlap any other memory areas such as used
3134 register banks or the data segment and with enough space for the current
3137 \labelwidthstring 00.00.0000
3143 <Value> The start location of the internal ram data segment.
3144 The value entered can be in Hexadecimal or Decimal format, eg.
3145 ---data-loc 0x20 or ---data-loc 32.
3146 (By default, the start location of the internal ram data segment is set
3147 as low as possible in memory, taking into account the used register banks
3148 and the bit segment at address 0x20.
3149 For example if register banks 0 and 1 are used without bit variables, the
3150 data segment will be set, if ---data-loc is not used, to location 0x10.)
3152 \labelwidthstring 00.00.0000
3158 <Value> The start location of the indirectly addressable internal ram, default
3160 The value entered can be in Hexadecimal or Decimal format, eg.
3161 ---idata-loc 0x88 or ---idata-loc 136.
3163 \labelwidthstring 00.00.0000
3172 The linker output (final object code) is in Intel Hex format.
3173 (This is the default option).
3175 \labelwidthstring 00.00.0000
3184 The linker output (final object code) is in Motorola S19 format.
3185 \layout Subsubsection
3189 \labelwidthstring 00.00.0000
3195 Generate code for Large model programs see section Memory Models for more
3197 If this option is used all source files in the project should be compiled
3199 In addition the standard library routines are compiled with small model,
3200 they will need to be recompiled.
3202 \labelwidthstring 00.00.0000
3213 Generate code for Small Model programs see section Memory Models for more
3215 This is the default model.
3216 \layout Subsubsection
3220 \labelwidthstring 00.00.0000
3231 Generate 24-bit flat mode code.
3232 This is the one and only that the ds390 code generator supports right now
3233 and is default when using
3238 See section Memory Models for more details.
3240 \labelwidthstring 00.00.0000
3246 Generate code for the 10 bit stack mode of the Dallas DS80C390 part.
3247 This is the one and only that the ds390 code generator supports right now
3248 and is default when using
3253 In this mode, the stack is located in the lower 1K of the internal RAM,
3254 which is mapped to 0x400000.
3255 Note that the support is incomplete, since it still uses a single byte
3256 as the stack pointer.
3257 This means that only the lower 256 bytes of the potential 1K stack space
3258 will actually be used.
3259 However, this does allow you to reclaim the precious 256 bytes of low RAM
3260 for use for the DATA and IDATA segments.
3261 The compiler will not generate any code to put the processor into 10 bit
3263 It is important to ensure that the processor is in this mode before calling
3264 any re-entrant functions compiled with this option.
3265 In principle, this should work with the
3269 option, but that has not been tested.
3270 It is incompatible with the
3275 It also only makes sense if the processor is in 24 bit contiguous addressing
3278 ---model-flat24 option
3281 \layout Subsubsection
3283 Optimization Options
3285 \labelwidthstring 00.00.0000
3291 Will not do global subexpression elimination, this option may be used when
3292 the compiler creates undesirably large stack/data spaces to store compiler
3294 A warning message will be generated when this happens and the compiler
3295 will indicate the number of extra bytes it allocated.
3296 It recommended that this option NOT be used, #pragma\SpecialChar ~
3298 to turn off global subexpression elimination for a given function only.
3300 \labelwidthstring 00.00.0000
3306 Will not do loop invariant optimizations, this may be turned off for reasons
3307 explained for the previous option.
3308 For more details of loop optimizations performed see section Loop Invariants.It
3309 recommended that this option NOT be used, #pragma\SpecialChar ~
3310 NOINVARIANT can be used
3311 to turn off invariant optimizations for a given function only.
3313 \labelwidthstring 00.00.0000
3319 Will not do loop induction optimizations, see section strength reduction
3320 for more details.It is recommended that this option is NOT used, #pragma\SpecialChar ~
3322 ION can be used to turn off induction optimizations for a given function
3325 \labelwidthstring 00.00.0000
3336 Will not generate boundary condition check when switch statements are implement
3337 ed using jump-tables.
3338 See section Switch Statements for more details.
3339 It is recommended that this option is NOT used, #pragma\SpecialChar ~
3341 used to turn off boundary checking for jump tables for a given function
3344 \labelwidthstring 00.00.0000
3353 Will not do loop reversal optimization.
3355 \labelwidthstring 00.00.0000
3361 Will not optimize labels (makes the dumpfiles more readable).
3363 \labelwidthstring 00.00.0000
3369 Will not memcpy initialized data in far space from code space.
3370 This saves a few bytes in code space if you don't have initialized data.
3371 \layout Subsubsection
3375 \labelwidthstring 00.00.0000
3382 will compile and assemble the source, but will not call the linkage editor.
3384 \labelwidthstring 00.00.0000
3390 reads the preprocessed source from standard input and compiles it.
3391 The file name for the assembler output must be specified using the -o option.
3393 \labelwidthstring 00.00.0000
3399 Run only the C preprocessor.
3400 Preprocess all the C source files specified and output the results to standard
3403 \labelwidthstring 00.00.0000
3410 The output path resp.
3411 file where everything will be placed.
3412 If the parameter is a path, it must have a trailing slash (or backslash
3413 for the Windows binaries) to be recognized as a path.
3416 \labelwidthstring 00.00.0000
3427 All functions in the source file will be compiled as
3432 the parameters and local variables will be allocated on the stack.
3433 see section Parameters and Local Variables for more details.
3434 If this option is used all source files in the project should be compiled
3438 \labelwidthstring 00.00.0000
3444 Uses a pseudo stack in the first 256 bytes in the external ram for allocating
3445 variables and passing parameters.
3446 See section on external stack for more details.
3448 \labelwidthstring 00.00.0000
3452 ---callee-saves function1[,function2][,function3]....
3455 The compiler by default uses a caller saves convention for register saving
3456 across function calls, however this can cause unneccessary register pushing
3457 & popping when calling small functions from larger functions.
3458 This option can be used to switch the register saving convention for the
3459 function names specified.
3460 The compiler will not save registers when calling these functions, no extra
3461 code will be generated at the entry & exit for these functions to save
3462 & restore the registers used by these functions, this can SUBSTANTIALLY
3463 reduce code & improve run time performance of the generated code.
3464 In the future the compiler (with interprocedural analysis) will be able
3465 to determine the appropriate scheme to use for each function call.
3466 DO NOT use this option for built-in functions such as _muluint..., if this
3467 option is used for a library function the appropriate library function
3468 needs to be recompiled with the same option.
3469 If the project consists of multiple source files then all the source file
3470 should be compiled with the same ---callee-saves option string.
3471 Also see #pragma\SpecialChar ~
3474 \labelwidthstring 00.00.0000
3483 When this option is used the compiler will generate debug information, that
3484 can be used with the SDCDB.
3485 The debug information is collected in a file with .cdb extension.
3486 For more information see documentation for SDCDB.
3488 \labelwidthstring 00.00.0000
3494 <filename> This option can be used to use additional rules to be used by
3495 the peep hole optimizer.
3496 See section Peep Hole optimizations for details on how to write these rules.
3498 \labelwidthstring 00.00.0000
3509 Stop after the stage of compilation proper; do not assemble.
3510 The output is an assembler code file for the input file specified.
3512 \labelwidthstring 00.00.0000
3516 -Wa_asmOption[,asmOption]
3519 Pass the asmOption to the assembler.
3521 \labelwidthstring 00.00.0000
3525 -Wl_linkOption[,linkOption]
3528 Pass the linkOption to the linker.
3530 \labelwidthstring 00.00.0000
3539 Integer (16 bit) and long (32 bit) libraries have been compiled as reentrant.
3540 Note by default these libraries are compiled as non-reentrant.
3541 See section Installation for more details.
3543 \labelwidthstring 00.00.0000
3552 This option will cause the compiler to generate an information message for
3553 each function in the source file.
3554 The message contains some
3558 information about the function.
3559 The number of edges and nodes the compiler detected in the control flow
3560 graph of the function, and most importantly the
3562 cyclomatic complexity
3564 see section on Cyclomatic Complexity for more details.
3566 \labelwidthstring 00.00.0000
3575 Floating point library is compiled as reentrant.See section Installation
3578 \labelwidthstring 00.00.0000
3584 The compiler will not overlay parameters and local variables of any function,
3585 see section Parameters and local variables for more details.
3587 \labelwidthstring 00.00.0000
3593 This option can be used when the code generated is called by a monitor
3595 The compiler will generate a 'ret' upon return from the 'main' function.
3596 The default option is to lock up i.e.
3599 \labelwidthstring 00.00.0000
3605 Disable peep-hole optimization.
3607 \labelwidthstring 00.00.0000
3613 Pass the inline assembler code through the peep hole optimizer.
3614 This can cause unexpected changes to inline assembler code, please go through
3615 the peephole optimizer rules defined in the source file tree '<target>/peeph.def
3616 ' before using this option.
3618 \labelwidthstring 00.00.0000
3624 <Value> Causes the linker to check if the internal ram usage is within limits
3627 \labelwidthstring 00.00.0000
3633 <Value> Causes the linker to check if the external ram usage is within limits
3636 \labelwidthstring 00.00.0000
3642 <Value> Causes the linker to check if the code usage is within limits of
3645 \labelwidthstring 00.00.0000
3651 This will prevent the compiler from passing on the default include path
3652 to the preprocessor.
3654 \labelwidthstring 00.00.0000
3660 This will prevent the compiler from passing on the default library path
3663 \labelwidthstring 00.00.0000
3669 Shows the various actions the compiler is performing.
3671 \labelwidthstring 00.00.0000
3677 Shows the actual commands the compiler is executing.
3679 \labelwidthstring 00.00.0000
3685 Hides your ugly and inefficient c-code from the asm file, so you can always
3686 blame the compiler :).
3688 \labelwidthstring 00.00.0000
3694 Include i-codes in the asm file.
3695 Sounds like noise but is most helpfull for debugging the compiler itself.
3697 \labelwidthstring 00.00.0000
3703 Disable some of the more pedantic warnings (jwk burps: please be more specific
3705 \layout Subsubsection
3707 Intermediate Dump Options
3710 The following options are provided for the purpose of retargetting and debugging
3712 These provided a means to dump the intermediate code (iCode) generated
3713 by the compiler in human readable form at various stages of the compilation
3717 \labelwidthstring 00.00.0000
3723 This option will cause the compiler to dump the intermediate code into
3726 <source filename>.dumpraw
3728 just after the intermediate code has been generated for a function, i.e.
3729 before any optimizations are done.
3730 The basic blocks at this stage ordered in the depth first number, so they
3731 may not be in sequence of execution.
3733 \labelwidthstring 00.00.0000
3739 Will create a dump of iCode's, after global subexpression elimination,
3742 <source filename>.dumpgcse.
3744 \labelwidthstring 00.00.0000
3750 Will create a dump of iCode's, after deadcode elimination, into a file
3753 <source filename>.dumpdeadcode.
3755 \labelwidthstring 00.00.0000
3764 Will create a dump of iCode's, after loop optimizations, into a file named
3767 <source filename>.dumploop.
3769 \labelwidthstring 00.00.0000
3778 Will create a dump of iCode's, after live range analysis, into a file named
3781 <source filename>.dumprange.
3783 \labelwidthstring 00.00.0000
3789 Will dump the life ranges for all symbols.
3791 \labelwidthstring 00.00.0000
3800 Will create a dump of iCode's, after register assignment, into a file named
3803 <source filename>.dumprassgn.
3805 \labelwidthstring 00.00.0000
3811 Will create a dump of the live ranges of iTemp's
3813 \labelwidthstring 00.00.0000
3824 Will cause all the above mentioned dumps to be created.
3827 Environment variables
3830 SDCC recognizes the following environment variables:
3832 \labelwidthstring 00.00.0000
3838 SDCC installs a signal handler to be able to delete temporary files after
3839 an user break (^C) or an exception.
3840 If this environment variable is set, SDCC won't install the signal handler
3841 in order to be able to debug SDCC.
3843 \labelwidthstring 00.00.0000
3851 Path, where temporary files will be created.
3852 The order of the variables is the search order.
3853 In a standard *nix environment these variables are not set, and there's
3854 no need to set them.
3855 On Windows it's recommended to set one of them.
3857 \labelwidthstring 00.00.0000
3864 \begin_inset Quotes sld
3867 2.3 Install and search paths
3868 \begin_inset Quotes srd
3873 \labelwidthstring 00.00.0000
3880 \begin_inset Quotes sld
3883 2.3 Install and search paths
3884 \begin_inset Quotes srd
3889 \labelwidthstring 00.00.0000
3896 \begin_inset Quotes sld
3899 2.3 Install and search paths
3900 \begin_inset Quotes srd
3906 There are some more environment variables recognized by SDCC, but these
3907 are solely used for debugging purposes.
3908 They can change or disappear very quickly, and will never be documentated.
3911 MCS51/DS390 Storage Class Language Extensions
3914 In addition to the ANSI storage classes SDCC allows the following MCS51
3915 specific storage classes.
3916 \layout Subsubsection
3921 Variables declared with this storage class will be placed in the extern
3927 storage class for Large Memory model, e.g.:
3933 xdata unsigned char xduc;
3934 \layout Subsubsection
3943 storage class for Small Memory model.
3944 Variables declared with this storage class will be allocated in the internal
3952 \layout Subsubsection
3957 Variables declared with this storage class will be allocated into the indirectly
3958 addressable portion of the internal ram of a 8051, e.g.:
3965 \layout Subsubsection
3970 This is a data-type and a storage class specifier.
3971 When a variable is declared as a bit, it is allocated into the bit addressable
3972 memory of 8051, e.g.:
3979 \layout Subsubsection
3984 Like the bit keyword,
3988 signifies both a data-type and storage class, they are used to describe
3989 the special function registers and special bit variables of a 8051, eg:
3995 sfr at 0x80 P0; /* special function register P0 at location 0x80 */
3997 sbit at 0xd7 CY; /* CY (Carry Flag) */
4003 SDCC allows (via language extensions) pointers to explicitly point to any
4004 of the memory spaces of the 8051.
4005 In addition to the explicit pointers, the compiler uses (by default) generic
4006 pointers which can be used to point to any of the memory spaces.
4010 Pointer declaration examples:
4019 /* pointer physically in xternal ram pointing to object in internal ram
4022 data unsigned char * xdata p;
4026 /* pointer physically in code rom pointing to data in xdata space */
4028 xdata unsigned char * code p;
4032 /* pointer physically in code space pointing to data in code space */
4034 code unsigned char * code p;
4038 /* the folowing is a generic pointer physically located in xdata space */
4049 Well you get the idea.
4054 All unqualified pointers are treated as 3-byte (4-byte for the ds390)
4067 The highest order byte of the
4071 pointers contains the data space information.
4072 Assembler support routines are called whenever data is stored or retrieved
4078 These are useful for developing reusable library routines.
4079 Explicitly specifying the pointer type will generate the most efficient
4083 Parameters & Local Variables
4086 Automatic (local) variables and parameters to functions can either be placed
4087 on the stack or in data-space.
4088 The default action of the compiler is to place these variables in the internal
4089 RAM (for small model) or external RAM (for large model).
4090 This in fact makes them
4094 so by default functions are non-reentrant.
4098 They can be placed on the stack either by using the
4102 option or by using the
4106 keyword in the function declaration, e.g.:
4115 unsigned char foo(char i) reentrant
4128 Since stack space on 8051 is limited, the
4136 option should be used sparingly.
4137 Note that the reentrant keyword just means that the parameters & local
4138 variables will be allocated to the stack, it
4142 mean that the function is register bank independent.
4146 Local variables can be assigned storage classes and absolute addresses,
4153 unsigned char foo() {
4159 xdata unsigned char i;
4171 data at 0x31 unsiged char j;
4186 In the above example the variable
4190 will be allocated in the external ram,
4194 in bit addressable space and
4203 or when a function is declared as
4207 this should only be done for static variables.
4210 Parameters however are not allowed any storage class, (storage classes for
4211 parameters will be ignored), their allocation is governed by the memory
4212 model in use, and the reentrancy options.
4218 For non-reentrant functions SDCC will try to reduce internal ram space usage
4219 by overlaying parameters and local variables of a function (if possible).
4220 Parameters and local variables of a function will be allocated to an overlayabl
4221 e segment if the function has
4223 no other function calls and the function is non-reentrant and the memory
4227 If an explicit storage class is specified for a local variable, it will
4231 Note that the compiler (not the linkage editor) makes the decision for overlayin
4233 Functions that are called from an interrupt service routine should be preceded
4234 by a #pragma\SpecialChar ~
4235 NOOVERLAY if they are not reentrant.
4238 Also note that the compiler does not do any processing of inline assembler
4239 code, so the compiler might incorrectly assign local variables and parameters
4240 of a function into the overlay segment if the inline assembler code calls
4241 other c-functions that might use the overlay.
4242 In that case the #pragma\SpecialChar ~
4243 NOOVERLAY should be used.
4246 Parameters and Local variables of functions that contain 16 or 32 bit multiplica
4247 tion or division will NOT be overlayed since these are implemented using
4248 external functions, e.g.:
4258 void set_error(unsigned char errcd)
4274 void some_isr () interrupt 2 using 1
4303 In the above example the parameter
4311 would be assigned to the overlayable segment if the #pragma\SpecialChar ~
4313 not present, this could cause unpredictable runtime behavior when called
4315 The #pragma\SpecialChar ~
4316 NOOVERLAY ensures that the parameters and local variables for
4317 the function are NOT overlayed.
4320 Interrupt Service Routines
4323 SDCC allows interrupt service routines to be coded in C, with some extended
4330 void timer_isr (void) interrupt 2 using 1
4343 The number following the
4347 keyword is the interrupt number this routine will service.
4348 The compiler will insert a call to this routine in the interrupt vector
4349 table for the interrupt number specified.
4354 keyword is used to tell the compiler to use the specified register bank
4355 (8051 specific) when generating code for this function.
4356 Note that when some function is called from an interrupt service routine
4357 it should be preceded by a #pragma\SpecialChar ~
4358 NOOVERLAY if it is not reentrant.
4359 A special note here, int (16 bit) and long (32 bit) integer division, multiplic
4360 ation & modulus operations are implemented using external support routines
4361 developed in ANSI-C, if an interrupt service routine needs to do any of
4362 these operations then the support routines (as mentioned in a following
4363 section) will have to be recompiled using the
4367 option and the source file will need to be compiled using the
4374 If you have multiple source files in your project, interrupt service routines
4375 can be present in any of them, but a prototype of the isr MUST be present
4376 or included in the file that contains the function
4383 Interrupt Numbers and the corresponding address & descriptions for the Standard
4384 8051 are listed below.
4385 SDCC will automatically adjust the interrupt vector table to the maximum
4386 interrupt number specified.
4392 \begin_inset Tabular
4393 <lyxtabular version="3" rows="6" columns="3">
4395 <column alignment="center" valignment="top" leftline="true" width="0in">
4396 <column alignment="center" valignment="top" leftline="true" width="0in">
4397 <column alignment="center" valignment="top" leftline="true" rightline="true" width="0in">
4398 <row topline="true" bottomline="true">
4399 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
4407 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
4415 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
4424 <row topline="true">
4425 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
4433 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
4441 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
4450 <row topline="true">
4451 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
4459 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
4467 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
4476 <row topline="true">
4477 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
4485 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
4493 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
4502 <row topline="true">
4503 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
4511 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
4519 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
4528 <row topline="true" bottomline="true">
4529 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
4537 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
4545 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
4562 If the interrupt service routine is defined without
4566 a register bank or with register bank 0 (using 0), the compiler will save
4567 the registers used by itself on the stack upon entry and restore them at
4568 exit, however if such an interrupt service routine calls another function
4569 then the entire register bank will be saved on the stack.
4570 This scheme may be advantageous for small interrupt service routines which
4571 have low register usage.
4574 If the interrupt service routine is defined to be using a specific register
4579 are save and restored, if such an interrupt service routine calls another
4580 function (using another register bank) then the entire register bank of
4581 the called function will be saved on the stack.
4582 This scheme is recommended for larger interrupt service routines.
4585 Calling other functions from an interrupt service routine is not recommended,
4586 avoid it if possible.
4590 Also see the _naked modifier.
4598 <TODO: this isn't implemented at all!>
4604 A special keyword may be associated with a function declaring it as
4609 SDCC will generate code to disable all interrupts upon entry to a critical
4610 function and enable them back before returning.
4611 Note that nesting critical functions may cause unpredictable results.
4636 The critical attribute maybe used with other attributes like
4644 A special keyword may be associated with a function declaring it as
4653 function modifier attribute prevents the compiler from generating prologue
4654 and epilogue code for that function.
4655 This means that the user is entirely responsible for such things as saving
4656 any registers that may need to be preserved, selecting the proper register
4657 bank, generating the
4661 instruction at the end, etc.
4662 Practically, this means that the contents of the function must be written
4663 in inline assembler.
4664 This is particularly useful for interrupt functions, which can have a large
4665 (and often unnecessary) prologue/epilogue.
4666 For example, compare the code generated by these two functions:
4672 data unsigned char counter;
4674 void simpleInterrupt(void) interrupt 1
4688 void nakedInterrupt(void) interrupt 2 _naked
4721 ; MUST explicitly include ret in _naked function.
4735 For an 8051 target, the generated simpleInterrupt looks like:
4880 whereas nakedInterrupt looks like:
4905 ; MUST explicitly include ret(i) in _naked function.
4911 While there is nothing preventing you from writing C code inside a _naked
4912 function, there are many ways to shoot yourself in the foot doing this,
4913 and it is recommended that you stick to inline assembler.
4916 Functions using private banks
4923 attribute (which tells the compiler to use a register bank other than the
4924 default bank zero) should only be applied to
4928 functions (see note 1 below).
4929 This will in most circumstances make the generated ISR code more efficient
4930 since it will not have to save registers on the stack.
4937 attribute will have no effect on the generated code for a
4941 function (but may occasionally be useful anyway
4947 possible exception: if a function is called ONLY from 'interrupt' functions
4948 using a particular bank, it can be declared with the same 'using' attribute
4949 as the calling 'interrupt' functions.
4950 For instance, if you have several ISRs using bank one, and all of them
4951 call memcpy(), it might make sense to create a specialized version of memcpy()
4952 'using 1', since this would prevent the ISR from having to save bank zero
4953 to the stack on entry and switch to bank zero before calling the function
4960 (pending: I don't think this has been done yet)
4967 function using a non-zero bank will assume that it can trash that register
4968 bank, and will not save it.
4969 Since high-priority interrupts can interrupt low-priority ones on the 8051
4970 and friends, this means that if a high-priority ISR
4974 a particular bank occurs while processing a low-priority ISR
4978 the same bank, terrible and bad things can happen.
4979 To prevent this, no single register bank should be
4983 by both a high priority and a low priority ISR.
4984 This is probably most easily done by having all high priority ISRs use
4985 one bank and all low priority ISRs use another.
4986 If you have an ISR which can change priority at runtime, you're on your
4987 own: I suggest using the default bank zero and taking the small performance
4991 It is most efficient if your ISR calls no other functions.
4992 If your ISR must call other functions, it is most efficient if those functions
4993 use the same bank as the ISR (see note 1 below); the next best is if the
4994 called functions use bank zero.
4995 It is very inefficient to call a function using a different, non-zero bank
5003 Data items can be assigned an absolute address with the
5007 keyword, in addition to a storage class, e.g.:
5013 xdata at 0x8000 unsigned char PORTA_8255 ;
5019 In the above example the PORTA_8255 will be allocated to the location 0x8000
5020 of the external ram.
5021 Note that this feature is provided to give the programmer access to
5025 devices attached to the controller.
5026 The compiler does not actually reserve any space for variables declared
5027 in this way (they are implemented with an equate in the assembler).
5028 Thus it is left to the programmer to make sure there are no overlaps with
5029 other variables that are declared without the absolute address.
5030 The assembler listing file (.lst) and the linker output files (.rst) and
5031 (.map) are a good places to look for such overlaps.
5035 Absolute address can be specified for variables in all storage classes,
5048 The above example will allocate the variable at offset 0x02 in the bit-addressab
5050 There is no real advantage to assigning absolute addresses to variables
5051 in this manner, unless you want strict control over all the variables allocated.
5057 The compiler inserts a call to the C routine
5059 _sdcc__external__startup()
5064 at the start of the CODE area.
5065 This routine is in the runtime library.
5066 By default this routine returns 0, if this routine returns a non-zero value,
5067 the static & global variable initialization will be skipped and the function
5068 main will be invoked Other wise static & global variables will be initialized
5069 before the function main is invoked.
5072 _sdcc__external__startup()
5074 routine to your program to override the default if you need to setup hardware
5075 or perform some other critical operation prior to static & global variable
5079 Inline Assembler Code
5082 SDCC allows the use of in-line assembler with a few restriction as regards
5084 All labels defined within inline assembler code
5092 where nnnn is a number less than 100 (which implies a limit of utmost 100
5093 inline assembler labels
5101 It is strongly recommended that each assembly instruction (including labels)
5102 be placed in a separate line (as the example shows).
5107 command line option is used, the inline assembler code will be passed through
5108 the peephole optimizer.
5109 This might cause some unexpected changes in the inline assembler code.
5110 Please go throught the peephole optimizer rules defined in file
5114 carefully before using this option.
5154 The inline assembler code can contain any valid code understood by the assembler
5155 , this includes any assembler directives and comment lines.
5156 The compiler does not do any validation of the code within the
5166 Inline assembler code cannot reference any C-Labels, however it can reference
5167 labels defined by the inline assembler, e.g.:
5193 ; some assembler code
5213 /* some more c code */
5215 clabel:\SpecialChar ~
5217 /* inline assembler cannot reference this label */
5229 $0003: ;label (can be reference by inline assembler only)
5241 /* some more c code */
5249 In other words inline assembly code can access labels defined in inline
5250 assembly within the scope of the funtion.
5254 The same goes the other way, ie.
5255 labels defines in inline assembly CANNOT be accessed by C statements.
5258 int (16 bit) and long (32 bit) Support
5261 For signed & unsigned int (16 bit) and long (32 bit) variables, division,
5262 multiplication and modulus operations are implemented by support routines.
5263 These support routines are all developed in ANSI-C to facilitate porting
5264 to other MCUs, although some model specific assembler optimations are used.
5265 The following files contain the described routine, all of them can be found
5266 in <installdir>/share/sdcc/lib.
5272 <pending: tabularise this>
5278 _mulsint.c - signed 16 bit multiplication (calls _muluint)
5280 _muluint.c - unsigned 16 bit multiplication
5282 _divsint.c - signed 16 bit division (calls _divuint)
5284 _divuint.c - unsigned 16 bit division
5286 _modsint.c - signed 16 bit modulus (call _moduint)
5288 _moduint.c - unsigned 16 bit modulus
5290 _mulslong.c - signed 32 bit multiplication (calls _mululong)
5292 _mululong.c - unsigned32 bit multiplication
5294 _divslong.c - signed 32 division (calls _divulong)
5296 _divulong.c - unsigned 32 division
5298 _modslong.c - signed 32 bit modulus (calls _modulong)
5300 _modulong.c - unsigned 32 bit modulus
5308 Since they are compiled as
5312 , interrupt service routines should not do any of the above operations.
5313 If this is unavoidable then the above routines will need to be compiled
5318 option, after which the source program will have to be compiled with
5325 Floating Point Support
5328 SDCC supports IEEE (single precision 4bytes) floating point numbers.The floating
5329 point support routines are derived from gcc's floatlib.c and consists of
5330 the following routines:
5336 <pending: tabularise this>
5342 _fsadd.c - add floating point numbers
5344 _fssub.c - subtract floating point numbers
5346 _fsdiv.c - divide floating point numbers
5348 _fsmul.c - multiply floating point numbers
5350 _fs2uchar.c - convert floating point to unsigned char
5352 _fs2char.c - convert floating point to signed char
5354 _fs2uint.c - convert floating point to unsigned int
5356 _fs2int.c - convert floating point to signed int
5358 _fs2ulong.c - convert floating point to unsigned long
5360 _fs2long.c - convert floating point to signed long
5362 _uchar2fs.c - convert unsigned char to floating point
5364 _char2fs.c - convert char to floating point number
5366 _uint2fs.c - convert unsigned int to floating point
5368 _int2fs.c - convert int to floating point numbers
5370 _ulong2fs.c - convert unsigned long to floating point number
5372 _long2fs.c - convert long to floating point number
5380 Note if all these routines are used simultaneously the data space might
5382 For serious floating point usage it is strongly recommended that the large
5389 SDCC allows two memory models for MCS51 code, small and large.
5390 Modules compiled with different memory models should
5394 be combined together or the results would be unpredictable.
5395 The library routines supplied with the compiler are compiled as both small
5397 The compiled library modules are contained in seperate directories as small
5398 and large so that you can link to either set.
5402 When the large model is used all variables declared without a storage class
5403 will be allocated into the external ram, this includes all parameters and
5404 local variables (for non-reentrant functions).
5405 When the small model is used variables without storage class are allocated
5406 in the internal ram.
5409 Judicious usage of the processor specific storage classes and the 'reentrant'
5410 function type will yield much more efficient code, than using the large
5412 Several optimizations are disabled when the program is compiled using the
5413 large model, it is therefore strongly recommdended that the small model
5414 be used unless absolutely required.
5420 The only model supported is Flat 24.
5421 This generates code for the 24 bit contiguous addressing mode of the Dallas
5423 In this mode, up to four meg of external RAM or code space can be directly
5425 See the data sheets at www.dalsemi.com for further information on this part.
5429 In older versions of the compiler, this option was used with the MCS51 code
5435 Now, however, the '390 has it's own code generator, selected by the
5444 Note that the compiler does not generate any code to place the processor
5445 into 24 bitmode (although
5449 in the ds390 libraries will do that for you).
5454 , the boot loader or similar code must ensure that the processor is in 24
5455 bit contiguous addressing mode before calling the SDCC startup code.
5463 option, variables will by default be placed into the XDATA segment.
5468 Segments may be placed anywhere in the 4 meg address space using the usual
5470 Note that if any segments are located above 64K, the -r flag must be passed
5471 to the linker to generate the proper segment relocations, and the Intel
5472 HEX output format must be used.
5473 The -r flag can be passed to the linker by using the option
5477 on the sdcc command line.
5478 However, currently the linker can not handle code segments > 64k.
5481 Defines Created by the Compiler
5484 The compiler creates the following #defines.
5487 SDCC - this Symbol is always defined.
5490 SDCC_mcs51 or SDCC_ds390 or SDCC_z80, etc - depending on the model used
5494 __mcs51 or __ds390 or __z80, etc - depending on the model used (e.g.
5498 SDCC_STACK_AUTO - this symbol is defined when
5505 SDCC_MODEL_SMALL - when
5512 SDCC_MODEL_LARGE - when
5519 SDCC_USE_XSTACK - when
5526 SDCC_STACK_TENBIT - when
5533 SDCC_MODEL_FLAT24 - when
5546 SDCC performs a host of standard optimizations in addition to some MCU specific
5549 \layout Subsubsection
5551 Sub-expression Elimination
5554 The compiler does local and global common subexpression elimination, e.g.:
5569 will be translated to
5585 Some subexpressions are not as obvious as the above example, e.g.:
5599 In this case the address arithmetic a->b[i] will be computed only once;
5600 the equivalent code in C would be.
5616 The compiler will try to keep these temporary variables in registers.
5617 \layout Subsubsection
5619 Dead-Code Elimination
5634 i = 1; \SpecialChar ~
5639 global = 1;\SpecialChar ~
5652 global = 3;\SpecialChar ~
5667 int global; void f ()
5680 \layout Subsubsection
5741 Note: the dead stores created by this copy propagation will be eliminated
5742 by dead-code elimination.
5743 \layout Subsubsection
5748 Two types of loop optimizations are done by SDCC loop invariant lifting
5749 and strength reduction of loop induction variables.
5750 In addition to the strength reduction the optimizer marks the induction
5751 variables and the register allocator tries to keep the induction variables
5752 in registers for the duration of the loop.
5753 Because of this preference of the register allocator, loop induction optimizati
5754 on causes an increase in register pressure, which may cause unwanted spilling
5755 of other temporary variables into the stack / data space.
5756 The compiler will generate a warning message when it is forced to allocate
5757 extra space either on the stack or data space.
5758 If this extra space allocation is undesirable then induction optimization
5759 can be eliminated either for the entire source file (with ---noinduction
5760 option) or for a given function only using #pragma\SpecialChar ~
5771 for (i = 0 ; i < 100 ; i ++)
5789 for (i = 0; i < 100; i++)
5799 As mentioned previously some loop invariants are not as apparent, all static
5800 address computations are also moved out of the loop.
5804 Strength Reduction, this optimization substitutes an expression by a cheaper
5811 for (i=0;i < 100; i++)
5831 for (i=0;i< 100;i++) {
5835 ar[itemp1] = itemp2;
5851 The more expensive multiplication is changed to a less expensive addition.
5852 \layout Subsubsection
5857 This optimization is done to reduce the overhead of checking loop boundaries
5858 for every iteration.
5859 Some simple loops can be reversed and implemented using a
5860 \begin_inset Quotes eld
5863 decrement and jump if not zero
5864 \begin_inset Quotes erd
5868 SDCC checks for the following criterion to determine if a loop is reversible
5869 (note: more sophisticated compilers use data-dependency analysis to make
5870 this determination, SDCC uses a more simple minded analysis).
5873 The 'for' loop is of the form
5879 for (<symbol> = <expression> ; <sym> [< | <=] <expression> ; [<sym>++ |
5889 The <for body> does not contain
5890 \begin_inset Quotes eld
5894 \begin_inset Quotes erd
5898 \begin_inset Quotes erd
5904 All goto's are contained within the loop.
5907 No function calls within the loop.
5910 The loop control variable <sym> is not assigned any value within the loop
5913 The loop control variable does NOT participate in any arithmetic operation
5917 There are NO switch statements in the loop.
5918 \layout Subsubsection
5920 Algebraic Simplifications
5923 SDCC does numerous algebraic simplifications, the following is a small sub-set
5924 of these optimizations.
5930 i = j + 0 ; /* changed to */ i = j;
5932 i /= 2; /* changed to */ i >>= 1;
5934 i = j - j ; /* changed to */ i = 0;
5936 i = j / 1 ; /* changed to */ i = j;
5942 Note the subexpressions given above are generally introduced by macro expansions
5943 or as a result of copy/constant propagation.
5944 \layout Subsubsection
5949 SDCC changes switch statements to jump tables when the following conditions
5954 The case labels are in numerical sequence, the labels need not be in order,
5955 and the starting number need not be one or zero.
5961 switch(i) {\SpecialChar ~
6068 Both the above switch statements will be implemented using a jump-table.
6071 The number of case labels is at least three, since it takes two conditional
6072 statements to handle the boundary conditions.
6075 The number of case labels is less than 84, since each label takes 3 bytes
6076 and a jump-table can be utmost 256 bytes long.
6080 Switch statements which have gaps in the numeric sequence or those that
6081 have more that 84 case labels can be split into more than one switch statement
6082 for efficient code generation, e.g.:
6120 If the above switch statement is broken down into two switch statements
6154 case 9: \SpecialChar ~
6164 case 12:\SpecialChar ~
6174 then both the switch statements will be implemented using jump-tables whereas
6175 the unmodified switch statement will not be.
6176 \layout Subsubsection
6178 Bit-shifting Operations.
6181 Bit shifting is one of the most frequently used operation in embedded programmin
6183 SDCC tries to implement bit-shift operations in the most efficient way
6203 generates the following code:
6221 In general SDCC will never setup a loop if the shift count is known.
6261 Note that SDCC stores numbers in little-endian format (i.e.
6262 lowest order first).
6263 \layout Subsubsection
6268 A special case of the bit-shift operation is bit rotation, SDCC recognizes
6269 the following expression to be a left bit-rotation:
6280 i = ((i << 1) | (i >> 7));
6288 will generate the following code:
6304 SDCC uses pattern matching on the parse tree to determine this operation.Variatio
6305 ns of this case will also be recognized as bit-rotation, i.e.:
6311 i = ((i >> 7) | (i << 1)); /* left-bit rotation */
6312 \layout Subsubsection
6317 It is frequently required to obtain the highest order bit of an integral
6318 type (long, int, short or char types).
6319 SDCC recognizes the following expression to yield the highest order bit
6320 and generates optimized code for it, e.g.:
6341 hob = (gint >> 15) & 1;
6354 will generate the following code:
6393 000A E5*01\SpecialChar ~
6421 000C 33\SpecialChar ~
6452 000D E4\SpecialChar ~
6483 000E 13\SpecialChar ~
6514 000F F5*02\SpecialChar ~
6544 Variations of this case however will
6549 It is a standard C expression, so I heartily recommend this be the only
6550 way to get the highest order bit, (it is portable).
6551 Of course it will be recognized even if it is embedded in other expressions,
6558 xyz = gint + ((gint >> 15) & 1);
6564 will still be recognized.
6565 \layout Subsubsection
6570 The compiler uses a rule based, pattern matching and re-writing mechanism
6571 for peep-hole optimization.
6576 a peep-hole optimizer by Christopher W.
6577 Fraser (cwfraser@microsoft.com).
6578 A default set of rules are compiled into the compiler, additional rules
6579 may be added with the
6581 ---peep-file <filename>
6584 The rule language is best illustrated with examples.
6612 The above rule will change the following assembly sequence:
6642 Note: All occurrences of a
6646 (pattern variable) must denote the same string.
6647 With the above rule, the assembly sequence:
6665 will remain unmodified.
6669 Other special case optimizations may be added by the user (via
6675 some variants of the 8051 MCU allow only
6684 The following two rules will change all
6706 replace { lcall %1 } by { acall %1 }
6708 replace { ljmp %1 } by { ajmp %1 }
6716 inline-assembler code
6718 is also passed through the peep hole optimizer, thus the peephole optimizer
6719 can also be used as an assembly level macro expander.
6720 The rules themselves are MCU dependent whereas the rule language infra-structur
6721 e is MCU independent.
6722 Peephole optimization rules for other MCU can be easily programmed using
6727 The syntax for a rule is as follows:
6733 rule := replace [ restart ] '{' <assembly sequence> '
6771 <assembly sequence> '
6789 '}' [if <functionName> ] '
6797 <assembly sequence> := assembly instruction (each instruction including
6798 labels must be on a separate line).
6802 The optimizer will apply to the rules one by one from the top in the sequence
6803 of their appearance, it will terminate when all rules are exhausted.
6804 If the 'restart' option is specified, then the optimizer will start matching
6805 the rules again from the top, this option for a rule is expensive (performance)
6806 , it is intended to be used in situations where a transformation will trigger
6807 the same rule again.
6808 An example of this (not a good one, it has side effects) is the following
6835 Note that the replace pattern cannot be a blank, but can be a comment line.
6836 Without the 'restart' option only the inner most 'pop' 'push' pair would
6837 be eliminated, i.e.:
6889 the restart option the rule will be applied again to the resulting code
6890 and then all the pop-push pairs will be eliminated to yield:
6908 A conditional function can be attached to a rule.
6909 Attaching rules are somewhat more involved, let me illustrate this with
6940 The optimizer does a look-up of a function name table defined in function
6945 in the source file SDCCpeeph.c, with the name
6950 If it finds a corresponding entry the function is called.
6951 Note there can be no parameters specified for these functions, in this
6956 is crucial, since the function
6960 expects to find the label in that particular variable (the hash table containin
6961 g the variable bindings is passed as a parameter).
6962 If you want to code more such functions, take a close look at the function
6963 labelInRange and the calling mechanism in source file SDCCpeeph.c.
6964 I know this whole thing is a little kludgey, but maybe some day we will
6965 have some better means.
6966 If you are looking at this file, you will also see the default rules that
6967 are compiled into the compiler, you can add your own rules in the default
6968 set there if you get tired of specifying the ---peep-file option.
6974 SDCC supports the following #pragma directives.
6977 SAVE - this will save all current options to the SAVE/RESTORE stack.
6981 RESTORE - will restore saved options from the last save.
6982 SAVEs & RESTOREs can be nested.
6983 SDCC uses a SAVE/RESTORE stack: SAVE pushes current options to the stack,
6984 RESTORE pulls current options from the stack.
6988 NOGCSE - will stop global subexpression elimination.
6991 NOINDUCTION - will stop loop induction optimizations.
6994 NOJTBOUND - will not generate code for boundary value checking, when switch
6995 statements are turned into jump-tables.
6998 NOOVERLAY - the compiler will not overlay the parameters and local variables
7002 LESS_PEDANTIC - the compiler will not warn you anymore for obvious mistakes,
7003 you'r on your own now ;-(
7006 NOLOOPREVERSE - Will not do loop reversal optimization
7009 EXCLUDE NONE | {acc[,b[,dpl[,dph]]] - The exclude pragma disables generation
7010 of pair of push/pop instruction in ISR function (using interrupt keyword).
7011 The directive should be placed immediately before the ISR function definition
7012 and it affects ALL ISR functions following it.
7013 To enable the normal register saving for ISR functions use #pragma\SpecialChar ~
7014 EXCLUDE\SpecialChar ~
7018 NOIV - Do not generate interrupt vector table entries for all ISR functions
7019 defined after the pragma.
7020 This is useful in cases where the interrupt vector table must be defined
7021 manually, or when there is a secondary, manually defined interrupt vector
7023 for the autovector feature of the Cypress EZ-USB FX2).
7026 CALLEE-SAVES function1[,function2[,function3...]] - The compiler by default
7027 uses a caller saves convention for register saving across function calls,
7028 however this can cause unneccessary register pushing & popping when calling
7029 small functions from larger functions.
7030 This option can be used to switch the register saving convention for the
7031 function names specified.
7032 The compiler will not save registers when calling these functions, extra
7033 code will be generated at the entry & exit for these functions to save
7034 & restore the registers used by these functions, this can SUBSTANTIALLY
7035 reduce code & improve run time performance of the generated code.
7036 In future the compiler (with interprocedural analysis) will be able to
7037 determine the appropriate scheme to use for each function call.
7038 If ---callee-saves command line option is used, the function names specified
7039 in #pragma\SpecialChar ~
7040 CALLEE-SAVES is appended to the list of functions specified inthe
7044 The pragma's are intended to be used to turn-off certain optimizations which
7045 might cause the compiler to generate extra stack / data space to store
7046 compiler generated temporary variables.
7047 This usually happens in large functions.
7048 Pragma directives should be used as shown in the following example, they
7049 are used to control options & optimizations for a given function; pragmas
7050 should be placed before and/or after a function, placing pragma's inside
7051 a function body could have unpredictable results.
7057 #pragma SAVE /* save the current settings */
7059 #pragma NOGCSE /* turnoff global subexpression elimination */
7061 #pragma NOINDUCTION /* turn off induction optimizations */
7083 #pragma RESTORE /* turn the optimizations back on */
7089 The compiler will generate a warning message when extra space is allocated.
7090 It is strongly recommended that the SAVE and RESTORE pragma's be used when
7091 changing options for a function.
7096 <pending: this is messy and incomplete>
7101 Compiler support routines (_gptrget, _mulint etc)
7104 Stdclib functions (puts, printf, strcat etc)
7107 Math functions (sin, pow, sqrt etc)
7110 Interfacing with Assembly Routines
7111 \layout Subsubsection
7113 Global Registers used for Parameter Passing
7116 The compiler always uses the global registers
7124 to pass the first parameter to a routine.
7125 The second parameter onwards is either allocated on the stack (for reentrant
7126 routines or if ---stack-auto is used) or in the internal / external ram
7127 (depending on the memory model).
7129 \layout Subsubsection
7131 Assembler Routine(non-reentrant)
7134 In the following example the function cfunc calls an assembler routine asm_func,
7135 which takes two parameters.
7141 extern int asm_func(unsigned char, unsigned char);
7145 int c_func (unsigned char i, unsigned char j)
7153 return asm_func(i,j);
7167 return c_func(10,9);
7175 The corresponding assembler function is:
7181 .globl _asm_func_PARM_2
7245 add a,_asm_func_PARM_2
7281 Note here that the return values are placed in 'dpl' - One byte return value,
7282 'dpl' LSB & 'dph' MSB for two byte values.
7283 'dpl', 'dph' and 'b' for three byte values (generic pointers) and 'dpl','dph','
7284 b' & 'acc' for four byte values.
7287 The parameter naming convention is _<function_name>_PARM_<n>, where n is
7288 the parameter number starting from 1, and counting from the left.
7289 The first parameter is passed in
7290 \begin_inset Quotes eld
7294 \begin_inset Quotes erd
7297 for One bye parameter,
7298 \begin_inset Quotes eld
7302 \begin_inset Quotes erd
7306 \begin_inset Quotes eld
7310 \begin_inset Quotes erd
7314 \begin_inset Quotes eld
7318 \begin_inset Quotes erd
7321 for four bytes, the varible name for the second parameter will be _<function_na
7326 Assemble the assembler routine with the following command:
7333 asx8051 -losg asmfunc.asm
7340 Then compile and link the assembler routine to the C source file with the
7348 sdcc cfunc.c asmfunc.rel
7349 \layout Subsubsection
7351 Assembler Routine(reentrant)
7354 In this case the second parameter onwards will be passed on the stack, the
7355 parameters are pushed from right to left i.e.
7356 after the call the left most parameter will be on the top of the stack.
7363 extern int asm_func(unsigned char, unsigned char);
7367 int c_func (unsigned char i, unsigned char j) reentrant
7375 return asm_func(i,j);
7389 return c_func(10,9);
7397 The corresponding assembler routine is:
7507 The compiling and linking procedure remains the same, however note the extra
7508 entry & exit linkage required for the assembler code, _bp is the stack
7509 frame pointer and is used to compute the offset into the stack for parameters
7510 and local variables.
7516 The external stack is located at the start of the external ram segment,
7517 and is 256 bytes in size.
7518 When ---xstack option is used to compile the program, the parameters and
7519 local variables of all reentrant functions are allocated in this area.
7520 This option is provided for programs with large stack space requirements.
7521 When used with the ---stack-auto option, all parameters and local variables
7522 are allocated on the external stack (note support libraries will need to
7523 be recompiled with the same options).
7526 The compiler outputs the higher order address byte of the external ram segment
7527 into PORT P2, therefore when using the External Stack option, this port
7528 MAY NOT be used by the application program.
7534 Deviations from the compliancy.
7537 functions are not always reentrant.
7540 structures cannot be assigned values directly, cannot be passed as function
7541 parameters or assigned to each other and cannot be a return value from
7568 s1 = s2 ; /* is invalid in SDCC although allowed in ANSI */
7579 struct s foo1 (struct s parms) /* is invalid in SDCC although allowed in
7601 return rets;/* is invalid in SDCC although allowed in ANSI */
7606 'long long' (64 bit integers) not supported.
7609 'double' precision floating point not supported.
7612 No support for setjmp and longjmp (for now).
7615 Old K&R style function declarations are NOT allowed.
7621 foo(i,j) /* this old style of function declarations */
7623 int i,j; /* are valid in ANSI but not valid in SDCC */
7637 functions declared as pointers must be dereferenced during the call.
7648 /* has to be called like this */
7650 (*foo)(); /* ansi standard allows calls to be made like 'foo()' */
7653 Cyclomatic Complexity
7656 Cyclomatic complexity of a function is defined as the number of independent
7657 paths the program can take during execution of the function.
7658 This is an important number since it defines the number test cases you
7659 have to generate to validate the function.
7660 The accepted industry standard for complexity number is 10, if the cyclomatic
7661 complexity reported by SDCC exceeds 10 you should think about simplification
7662 of the function logic.
7663 Note that the complexity level is not related to the number of lines of
7665 Large functions can have low complexity, and small functions can have large
7671 SDCC uses the following formula to compute the complexity:
7676 complexity = (number of edges in control flow graph) - (number of nodes
7677 in control flow graph) + 2;
7681 Having said that the industry standard is 10, you should be aware that in
7682 some cases it be may unavoidable to have a complexity level of less than
7684 For example if you have switch statement with more than 10 case labels,
7685 each case label adds one to the complexity level.
7686 The complexity level is by no means an absolute measure of the algorithmic
7687 complexity of the function, it does however provide a good starting point
7688 for which functions you might look at for further optimization.
7694 Here are a few guidelines that will help the compiler generate more efficient
7695 code, some of the tips are specific to this compiler others are generally
7696 good programming practice.
7699 Use the smallest data type to represent your data-value.
7700 If it is known in advance that the value is going to be less than 256 then
7701 use an 'unsigned char' instead of a 'short' or 'int'.
7704 Use unsigned when it is known in advance that the value is not going to
7706 This helps especially if you are doing division or multiplication.
7709 NEVER jump into a LOOP.
7712 Declare the variables to be local whenever possible, especially loop control
7713 variables (induction).
7716 Since the compiler does not always do implicit integral promotion, the programme
7717 r should do an explicit cast when integral promotion is required.
7720 Reducing the size of division, multiplication & modulus operations can reduce
7721 code size substantially.
7722 Take the following code for example.
7728 foobar(unsigned int p1, unsigned char ch)
7732 unsigned char ch1 = p1 % ch ;
7743 For the modulus operation the variable ch will be promoted to unsigned int
7744 first then the modulus operation will be performed (this will lead to a
7745 call to support routine _moduint()), and the result will be casted to a
7747 If the code is changed to
7753 foobar(unsigned int p1, unsigned char ch)
7757 unsigned char ch1 = (unsigned char)p1 % ch ;
7768 It would substantially reduce the code generated (future versions of the
7769 compiler will be smart enough to detect such optimization oppurtunities).
7772 Notes on MCS51 memory layout
7775 The 8051 family of micro controller have a minimum of 128 bytes of internal
7776 memory which is structured as follows
7780 - Bytes 00-1F - 32 bytes to hold up to 4 banks of the registers R7 to R7
7783 - Bytes 20-2F - 16 bytes to hold 128 bit variables and
7785 - Bytes 30-7F - 60 bytes for general purpose use.
7789 Normally the SDCC compiler will only utilise the first bank of registers,
7790 but it is possible to specify that other banks of registers should be used
7791 in interrupt routines.
7792 By default, the compiler will place the stack after the last bank of used
7794 if the first 2 banks of registers are used, it will position the base of
7795 the internal stack at address 16 (0X10).
7796 This implies that as the stack grows, it will use up the remaining register
7797 banks, and the 16 bytes used by the 128 bit variables, and 60 bytes for
7798 general purpose use.
7801 By default, the compiler uses the 60 general purpose bytes to hold "near
7803 The compiler/optimiser may also declare some Local Variables in this area
7808 If any of the 128 bit variables are used, or near data is being used then
7809 care needs to be taken to ensure that the stack does not grow so much that
7810 it starts to over write either your bit variables or "near data".
7811 There is no runtime checking to prevent this from happening.
7814 The amount of stack being used is affected by the use of the "internal stack"
7815 to save registers before a subroutine call is made (---stack-auto will
7816 declare parameters and local variables on the stack) and the number of
7820 If you detect that the stack is over writing you data, then the following
7822 ---xstack will cause an external stack to be used for saving registers
7823 and (if ---stack-auto is being used) storing parameters and local variables.
7824 However this will produce more code which will be slower to execute.
7828 ---stack-loc will allow you specify the start of the stack, i.e.
7829 you could start it after any data in the general purpose area.
7830 However this may waste the memory not used by the register banks and if
7831 the size of the "near data" increases, it may creep into the bottom of
7835 ---stack-after-data, similar to the ---stack-loc, but it automatically places
7836 the stack after the end of the "near data".
7837 Again this could waste any spare register space.
7840 ---data-loc allows you to specify the start address of the near data.
7841 This could be used to move the "near data" further away from the stack
7842 giving it more room to grow.
7843 This will only work if no bit variables are being used and the stack can
7844 grow to use the bit variable space.
7852 If you find that the stack is over writing your bit variables or "near data"
7853 then the approach which best utilised the internal memory is to position
7854 the "near data" after the last bank of used registers or, if you use bit
7855 variables, after the last bit variable by using the ---data-loc, e.g.
7856 if two register banks are being used and no bit variables, ---data-loc
7857 16, and use the ---stack-after-data option.
7860 If bit variables are being used, another method would be to try and squeeze
7861 the data area in the unused register banks if it will fit, and start the
7862 stack after the last bit variable.
7865 Retargetting for other MCUs.
7868 The issues for retargetting the compiler are far too numerous to be covered
7870 What follows is a brief description of each of the seven phases of the
7871 compiler and its MCU dependency.
7874 Parsing the source and building the annotated parse tree.
7875 This phase is largely MCU independent (except for the language extensions).
7876 Syntax & semantic checks are also done in this phase, along with some initial
7877 optimizations like back patching labels and the pattern matching optimizations
7878 like bit-rotation etc.
7881 The second phase involves generating an intermediate code which can be easy
7882 manipulated during the later phases.
7883 This phase is entirely MCU independent.
7884 The intermediate code generation assumes the target machine has unlimited
7885 number of registers, and designates them with the name iTemp.
7886 The compiler can be made to dump a human readable form of the code generated
7887 by using the ---dumpraw option.
7890 This phase does the bulk of the standard optimizations and is also MCU independe
7892 This phase can be broken down into several sub-phases:
7896 Break down intermediate code (iCode) into basic blocks.
7898 Do control flow & data flow analysis on the basic blocks.
7900 Do local common subexpression elimination, then global subexpression elimination
7902 Dead code elimination
7906 If loop optimizations caused any changes then do 'global subexpression eliminati
7907 on' and 'dead code elimination' again.
7910 This phase determines the live-ranges; by live range I mean those iTemp
7911 variables defined by the compiler that still survive after all the optimization
7913 Live range analysis is essential for register allocation, since these computati
7914 on determines which of these iTemps will be assigned to registers, and for
7918 Phase five is register allocation.
7919 There are two parts to this process.
7923 The first part I call 'register packing' (for lack of a better term).
7924 In this case several MCU specific expression folding is done to reduce
7929 The second part is more MCU independent and deals with allocating registers
7930 to the remaining live ranges.
7931 A lot of MCU specific code does creep into this phase because of the limited
7932 number of index registers available in the 8051.
7935 The Code generation phase is (unhappily), entirely MCU dependent and very
7936 little (if any at all) of this code can be reused for other MCU.
7937 However the scheme for allocating a homogenized assembler operand for each
7938 iCode operand may be reused.
7941 As mentioned in the optimization section the peep-hole optimizer is rule
7942 based system, which can reprogrammed for other MCUs.
7945 SDCDB - Source Level Debugger
7948 SDCC is distributed with a source level debugger.
7949 The debugger uses a command line interface, the command repertoire of the
7950 debugger has been kept as close to gdb (the GNU debugger) as possible.
7951 The configuration and build process is part of the standard compiler installati
7952 on, which also builds and installs the debugger in the target directory
7953 specified during configuration.
7954 The debugger allows you debug BOTH at the C source and at the ASM source
7958 Compiling for Debugging
7963 debug option must be specified for all files for which debug information
7965 The complier generates a .cdb file for each of these files.
7966 The linker updates the .cdb file with the address information.
7967 This .cdb is used by the debugger.
7970 How the Debugger Works
7973 When the ---debug option is specified the compiler generates extra symbol
7974 information some of which are put into the the assembler source and some
7975 are put into the .cdb file, the linker updates the .cdb file with the address
7976 information for the symbols.
7977 The debugger reads the symbolic information generated by the compiler &
7978 the address information generated by the linker.
7979 It uses the SIMULATOR (Daniel's S51) to execute the program, the program
7980 execution is controlled by the debugger.
7981 When a command is issued for the debugger, it translates it into appropriate
7982 commands for the simulator.
7985 Starting the Debugger
7988 The debugger can be started using the following command line.
7989 (Assume the file you are debugging has the file name foo).
8003 The debugger will look for the following files.
8006 foo.c - the source file.
8009 foo.cdb - the debugger symbol information file.
8012 foo.ihx - the intel hex format object file.
8015 Command Line Options.
8018 ---directory=<source file directory> this option can used to specify the
8019 directory search list.
8020 The debugger will look into the directory list specified for source, cdb
8022 The items in the directory list must be separated by ':', e.g.
8023 if the source files can be in the directories /home/src1 and /home/src2,
8024 the ---directory option should be ---directory=/home/src1:/home/src2.
8025 Note there can be no spaces in the option.
8029 -cd <directory> - change to the <directory>.
8032 -fullname - used by GUI front ends.
8035 -cpu <cpu-type> - this argument is passed to the simulator please see the
8036 simulator docs for details.
8039 -X <Clock frequency > this options is passed to the simulator please see
8040 the simulator docs for details.
8043 -s <serial port file> passed to simulator see the simulator docs for details.
8046 -S <serial in,out> passed to simulator see the simulator docs for details.
8052 As mention earlier the command interface for the debugger has been deliberately
8053 kept as close the GNU debugger gdb, as possible.
8054 This will help the integration with existing graphical user interfaces
8055 (like ddd, xxgdb or xemacs) existing for the GNU debugger.
8056 \layout Subsubsection
8058 break [line | file:line | function | file:function]
8061 Set breakpoint at specified line or function:
8070 sdcdb>break foo.c:100
8074 sdcdb>break foo.c:funcfoo
8075 \layout Subsubsection
8077 clear [line | file:line | function | file:function ]
8080 Clear breakpoint at specified line or function:
8089 sdcdb>clear foo.c:100
8093 sdcdb>clear foo.c:funcfoo
8094 \layout Subsubsection
8099 Continue program being debugged, after breakpoint.
8100 \layout Subsubsection
8105 Execute till the end of the current function.
8106 \layout Subsubsection
8111 Delete breakpoint number 'n'.
8112 If used without any option clear ALL user defined break points.
8113 \layout Subsubsection
8115 info [break | stack | frame | registers ]
8118 info break - list all breakpoints
8121 info stack - show the function call stack.
8124 info frame - show information about the current execution frame.
8127 info registers - show content of all registers.
8128 \layout Subsubsection
8133 Step program until it reaches a different source line.
8134 \layout Subsubsection
8139 Step program, proceeding through subroutine calls.
8140 \layout Subsubsection
8145 Start debugged program.
8146 \layout Subsubsection
8151 Print type information of the variable.
8152 \layout Subsubsection
8157 print value of variable.
8158 \layout Subsubsection
8163 load the given file name.
8164 Note this is an alternate method of loading file for debugging.
8165 \layout Subsubsection
8170 print information about current frame.
8171 \layout Subsubsection
8176 Toggle between C source & assembly source.
8177 \layout Subsubsection
8182 Send the string following '!' to the simulator, the simulator response is
8184 Note the debugger does not interpret the command being sent to the simulator,
8185 so if a command like 'go' is sent the debugger can loose its execution
8186 context and may display incorrect values.
8187 \layout Subsubsection
8194 My name is Bobby Brown"
8197 Interfacing with XEmacs.
8200 Two files (in emacs lisp) are provided for the interfacing with XEmacs,
8201 sdcdb.el and sdcdbsrc.el.
8202 These two files can be found in the $(prefix)/bin directory after the installat
8204 These files need to be loaded into XEmacs for the interface to work.
8205 This can be done at XEmacs startup time by inserting the following into
8206 your '.xemacs' file (which can be found in your HOME directory):
8212 (load-file sdcdbsrc.el)
8218 .xemacs is a lisp file so the () around the command is REQUIRED.
8219 The files can also be loaded dynamically while XEmacs is running, set the
8220 environment variable 'EMACSLOADPATH' to the installation bin directory
8221 (<installdir>/bin), then enter the following command ESC-x load-file sdcdbsrc.
8222 To start the interface enter the following command:
8236 You will prompted to enter the file name to be debugged.
8241 The command line options that are passed to the simulator directly are bound
8242 to default values in the file sdcdbsrc.el.
8243 The variables are listed below, these values maybe changed as required.
8246 sdcdbsrc-cpu-type '51
8249 sdcdbsrc-frequency '11059200
8255 The following is a list of key mapping for the debugger interface.
8263 ;; Current Listing ::
8280 binding\SpecialChar ~
8319 ------\SpecialChar ~
8359 sdcdb-next-from-src\SpecialChar ~
8385 sdcdb-back-from-src\SpecialChar ~
8411 sdcdb-cont-from-src\SpecialChar ~
8421 SDCDB continue command
8437 sdcdb-step-from-src\SpecialChar ~
8463 sdcdb-whatis-c-sexp\SpecialChar ~
8473 SDCDB ptypecommand for data at
8537 sdcdbsrc-delete\SpecialChar ~
8551 SDCDB Delete all breakpoints if no arg
8599 given or delete arg (C-u arg x)
8615 sdcdbsrc-frame\SpecialChar ~
8630 SDCDB Display current frame if no arg,
8679 given or display frame arg
8744 sdcdbsrc-goto-sdcdb\SpecialChar ~
8754 Goto the SDCDB output buffer
8770 sdcdb-print-c-sexp\SpecialChar ~
8781 SDCDB print command for data at
8845 sdcdbsrc-goto-sdcdb\SpecialChar ~
8855 Goto the SDCDB output buffer
8871 sdcdbsrc-mode\SpecialChar ~
8887 Toggles Sdcdbsrc mode (turns it off)
8891 ;; C-c C-f\SpecialChar ~
8899 sdcdb-finish-from-src\SpecialChar ~
8907 SDCDB finish command
8911 ;; C-x SPC\SpecialChar ~
8919 sdcdb-break\SpecialChar ~
8937 Set break for line with point
8939 ;; ESC t\SpecialChar ~
8949 sdcdbsrc-mode\SpecialChar ~
8965 Toggle Sdcdbsrc mode
8967 ;; ESC m\SpecialChar ~
8977 sdcdbsrc-srcmode\SpecialChar ~
9001 The Z80 and gbz80 port
9004 SDCC can target both the Zilog Z80 and the Nintendo Gameboy's Z80-like gbz80.
9005 The port is incomplete - long support is incomplete (mul, div and mod are
9006 unimplimented), and both float and bitfield support is missing.
9007 Apart from that the code generated is correct.
9010 As always, the code is the authoritave reference - see z80/ralloc.c and z80/gen.c.
9011 The stack frame is similar to that generated by the IAR Z80 compiler.
9012 IX is used as the base pointer, HL is used as a temporary register, and
9013 BC and DE are available for holding varibles.
9014 IY is currently unusued.
9015 Return values are stored in HL.
9016 One bad side effect of using IX as the base pointer is that a functions
9017 stack frame is limited to 127 bytes - this will be fixed in a later version.
9023 SDCC has grown to be a large project.
9024 The compiler alone (without the preprocessor, assembler and linker) is
9025 about 40,000 lines of code (blank stripped).
9026 The open source nature of this project is a key to its continued growth
9028 You gain the benefit and support of many active software developers and
9030 Is SDCC perfect? No, that's why we need your help.
9031 The developers take pride in fixing reported bugs.
9032 You can help by reporting the bugs and helping other SDCC users.
9033 There are lots of ways to contribute, and we encourage you to take part
9034 in making SDCC a great software package.
9040 Send an email to the mailing list at 'user-sdcc@sdcc.sourceforge.net' or 'devel-sd
9041 cc@sdcc.sourceforge.net'.
9042 Bugs will be fixed ASAP.
9043 When reporting a bug, it is very useful to include a small test program
9044 which reproduces the problem.
9045 If you can isolate the problem by looking at the generated assembly code,
9046 this can be very helpful.
9047 Compiling your program with the ---dumpall option can sometimes be useful
9048 in locating optimization problems.
9054 The anatomy of the compiler
9059 This is an excerpt from an atricle published in Circuit Cellar MagaZine
9061 It's a little outdated (the compiler is much more efficient now and user/devell
9062 oper friendly), but pretty well exposes the guts of it all.
9068 The current version of SDCC can generate code for Intel 8051 and Z80 MCU.
9069 It is fairly easy to retarget for other 8-bit MCU.
9070 Here we take a look at some of the internals of the compiler.
9077 Parsing the input source file and creating an AST (Annotated Syntax Tree).
9078 This phase also involves propagating types (annotating each node of the
9079 parse tree with type information) and semantic analysis.
9080 There are some MCU specific parsing rules.
9081 For example the storage classes, the extended storage classes are MCU specific
9082 while there may be a xdata storage class for 8051 there is no such storage
9083 class for z80 or Atmel AVR.
9084 SDCC allows MCU specific storage class extensions, i.e.
9085 xdata will be treated as a storage class specifier when parsing 8051 C
9086 code but will be treated as a C identifier when parsing z80 or ATMEL AVR
9093 Intermediate code generation.
9094 In this phase the AST is broken down into three-operand form (iCode).
9095 These three operand forms are represented as doubly linked lists.
9096 ICode is the term given to the intermediate form generated by the compiler.
9097 ICode example section shows some examples of iCode generated for some simple
9104 Bulk of the target independent optimizations is performed in this phase.
9105 The optimizations include constant propagation, common sub-expression eliminati
9106 on, loop invariant code movement, strength reduction of loop induction variables
9107 and dead-code elimination.
9113 During intermediate code generation phase, the compiler assumes the target
9114 machine has infinite number of registers and generates a lot of temporary
9116 The live range computation determines the lifetime of each of these compiler-ge
9117 nerated temporaries.
9118 A picture speaks a thousand words.
9119 ICode example sections show the live range annotations for each of the
9121 It is important to note here, each iCode is assigned a number in the order
9122 of its execution in the function.
9123 The live ranges are computed in terms of these numbers.
9124 The from number is the number of the iCode which first defines the operand
9125 and the to number signifies the iCode which uses this operand last.
9131 The register allocation determines the type and number of registers needed
9133 In most MCUs only a few registers can be used for indirect addressing.
9134 In case of 8051 for example the registers R0 & R1 can be used to indirectly
9135 address the internal ram and DPTR to indirectly address the external ram.
9136 The compiler will try to allocate the appropriate register to pointer variables
9138 ICode example section shows the operands annotated with the registers assigned
9140 The compiler will try to keep operands in registers as much as possible;
9141 there are several schemes the compiler uses to do achieve this.
9142 When the compiler runs out of registers the compiler will check to see
9143 if there are any live operands which is not used or defined in the current
9144 basic block being processed, if there are any found then it will push that
9145 operand and use the registers in this block, the operand will then be popped
9146 at the end of the basic block.
9150 There are other MCU specific considerations in this phase.
9151 Some MCUs have an accumulator; very short-lived operands could be assigned
9152 to the accumulator instead of general-purpose register.
9158 Figure II gives a table of iCode operations supported by the compiler.
9159 The code generation involves translating these operations into corresponding
9160 assembly code for the processor.
9161 This sounds overly simple but that is the essence of code generation.
9162 Some of the iCode operations are generated on a MCU specific manner for
9163 example, the z80 port does not use registers to pass parameters so the
9164 SEND and RECV iCode operations will not be generated, and it also does
9165 not support JUMPTABLES.
9172 <Where is Figure II ?>
9178 This section shows some details of iCode.
9179 The example C code does not do anything useful; it is used as an example
9180 to illustrate the intermediate code generated by the compiler.
9193 /* This function does nothing useful.
9200 for the purpose of explaining iCode */
9203 short function (data int *x)
9211 short i=10; /* dead initialization eliminated */
9216 short sum=10; /* dead initialization eliminated */
9229 while (*x) *x++ = *p++;
9243 /* compiler detects i,j to be induction variables */
9247 for (i = 0, j = 10 ; i < 10 ; i++, j---) {
9259 mul += i * 3; /* this multiplication remains */
9265 gint += j * 3;/* this multiplication changed to addition */
9282 In addition to the operands each iCode contains information about the filename
9283 and line it corresponds to in the source file.
9284 The first field in the listing should be interpreted as follows:
9289 Filename(linenumber: iCode Execution sequence number : ICode hash table
9290 key : loop depth of the iCode).
9295 Then follows the human readable form of the ICode operation.
9296 Each operand of this triplet form can be of three basic types a) compiler
9297 generated temporary b) user defined variable c) a constant value.
9298 Note that local variables and parameters are replaced by compiler generated
9300 Live ranges are computed only for temporaries (i.e.
9301 live ranges are not computed for global variables).
9302 Registers are allocated for temporaries only.
9303 Operands are formatted in the following manner:
9308 Operand Name [lr live-from : live-to ] { type information } [ registers
9314 As mentioned earlier the live ranges are computed in terms of the execution
9315 sequence number of the iCodes, for example
9317 the iTemp0 is live from (i.e.
9318 first defined in iCode with execution sequence number 3, and is last used
9319 in the iCode with sequence number 5).
9320 For induction variables such as iTemp21 the live range computation extends
9321 the lifetime from the start to the end of the loop.
9323 The register allocator used the live range information to allocate registers,
9324 the same registers may be used for different temporaries if their live
9325 ranges do not overlap, for example r0 is allocated to both iTemp6 and to
9326 iTemp17 since their live ranges do not overlap.
9327 In addition the allocator also takes into consideration the type and usage
9328 of a temporary, for example itemp6 is a pointer to near space and is used
9329 as to fetch data from (i.e.
9330 used in GET_VALUE_AT_ADDRESS) so it is allocated a pointer registers (r0).
9331 Some short lived temporaries are allocated to special registers which have
9332 meaning to the code generator e.g.
9333 iTemp13 is allocated to a pseudo register CC which tells the back end that
9334 the temporary is used only for a conditional jump the code generation makes
9335 use of this information to optimize a compare and jump ICode.
9337 There are several loop optimizations performed by the compiler.
9338 It can detect induction variables iTemp21(i) and iTemp23(j).
9339 Also note the compiler does selective strength reduction, i.e.
9340 the multiplication of an induction variable in line 18 (gint = j * 3) is
9341 changed to addition, a new temporary iTemp17 is allocated and assigned
9342 a initial value, a constant 3 is then added for each iteration of the loop.
9343 The compiler does not change the multiplication in line 17 however since
9344 the processor does support an 8 * 8 bit multiplication.
9346 Note the dead code elimination optimization eliminated the dead assignments
9347 in line 7 & 8 to I and sum respectively.
9354 Sample.c (5:1:0:0) _entry($9) :
9359 Sample.c(5:2:1:0) proc _function [lr0:0]{function short}
9364 Sample.c(11:3:2:0) iTemp0 [lr3:5]{_near * int}[r2] = recv
9369 Sample.c(11:4:53:0) preHeaderLbl0($11) :
9374 Sample.c(11:5:55:0) iTemp6 [lr5:16]{_near * int}[r0] := iTemp0 [lr3:5]{_near
9380 Sample.c(11:6:5:1) _whilecontinue_0($1) :
9385 Sample.c(11:7:7:1) iTemp4 [lr7:8]{int}[r2 r3] = @[iTemp6 [lr5:16]{_near *
9391 Sample.c(11:8:8:1) if iTemp4 [lr7:8]{int}[r2 r3] == 0 goto _whilebreak_0($3)
9396 Sample.c(11:9:14:1) iTemp7 [lr9:13]{_far * int}[DPTR] := _p [lr0:0]{_far
9402 Sample.c(11:10:15:1) _p [lr0:0]{_far * int} = _p [lr0:0]{_far * int} + 0x2
9408 Sample.c(11:13:18:1) iTemp10 [lr13:14]{int}[r2 r3] = @[iTemp7 [lr9:13]{_far
9414 Sample.c(11:14:19:1) *(iTemp6 [lr5:16]{_near * int}[r0]) := iTemp10 [lr13:14]{int
9420 Sample.c(11:15:12:1) iTemp6 [lr5:16]{_near * int}[r0] = iTemp6 [lr5:16]{_near
9421 * int}[r0] + 0x2 {short}
9426 Sample.c(11:16:20:1) goto _whilecontinue_0($1)
9431 Sample.c(11:17:21:0)_whilebreak_0($3) :
9436 Sample.c(12:18:22:0) iTemp2 [lr18:40]{short}[r2] := 0x0 {short}
9441 Sample.c(13:19:23:0) iTemp11 [lr19:40]{short}[r3] := 0x0 {short}
9446 Sample.c(15:20:54:0)preHeaderLbl1($13) :
9451 Sample.c(15:21:56:0) iTemp21 [lr21:38]{short}[r4] := 0x0 {short}
9456 Sample.c(15:22:57:0) iTemp23 [lr22:38]{int}[r5 r6] := 0xa {int}
9461 Sample.c(15:23:58:0) iTemp17 [lr23:38]{int}[r7 r0] := 0x1e {int}
9466 Sample.c(15:24:26:1)_forcond_0($4) :
9471 Sample.c(15:25:27:1) iTemp13 [lr25:26]{char}[CC] = iTemp21 [lr21:38]{short}[r4]
9477 Sample.c(15:26:28:1) if iTemp13 [lr25:26]{char}[CC] == 0 goto _forbreak_0($7)
9482 Sample.c(16:27:31:1) iTemp2 [lr18:40]{short}[r2] = iTemp2 [lr18:40]{short}[r2]
9483 + ITemp21 [lr21:38]{short}[r4]
9488 Sample.c(17:29:33:1) iTemp15 [lr29:30]{short}[r1] = iTemp21 [lr21:38]{short}[r4]
9494 Sample.c(17:30:34:1) iTemp11 [lr19:40]{short}[r3] = iTemp11 [lr19:40]{short}[r3]
9495 + iTemp15 [lr29:30]{short}[r1]
9500 Sample.c(18:32:36:1:1) iTemp17 [lr23:38]{int}[r7 r0]= iTemp17 [lr23:38]{int}[r7
9506 Sample.c(18:33:37:1) _gint [lr0:0]{int} = _gint [lr0:0]{int} + iTemp17 [lr23:38]{
9512 Sample.c(15:36:42:1) iTemp21 [lr21:38]{short}[r4] = iTemp21 [lr21:38]{short}[r4]
9518 Sample.c(15:37:45:1) iTemp23 [lr22:38]{int}[r5 r6]= iTemp23 [lr22:38]{int}[r5
9524 Sample.c(19:38:47:1) goto _forcond_0($4)
9529 Sample.c(19:39:48:0)_forbreak_0($7) :
9534 Sample.c(20:40:49:0) iTemp24 [lr40:41]{short}[DPTR] = iTemp2 [lr18:40]{short}[r2]
9535 + ITemp11 [lr19:40]{short}[r3]
9540 Sample.c(20:41:50:0) ret iTemp24 [lr40:41]{short}
9545 Sample.c(20:42:51:0)_return($8) :
9550 Sample.c(20:43:52:0) eproc _function [lr0:0]{ ia0 re0 rm0}{function short}
9556 Finally the code generated for this function:
9597 ; ----------------------------------------------
9607 ; ----------------------------------------------
9617 ; iTemp0 [lr3:5]{_near * int}[r2] = recv
9629 ; iTemp6 [lr5:16]{_near * int}[r0] := iTemp0 [lr3:5]{_near * int}[r2]
9641 ;_whilecontinue_0($1) :
9651 ; iTemp4 [lr7:8]{int}[r2 r3] = @[iTemp6 [lr5:16]{_near * int}[r0]]
9656 ; if iTemp4 [lr7:8]{int}[r2 r3] == 0 goto _whilebreak_0($3)
9715 ; iTemp7 [lr9:13]{_far * int}[DPTR] := _p [lr0:0]{_far * int}
9734 ; _p [lr0:0]{_far * int} = _p [lr0:0]{_far * int} + 0x2 {short}
9781 ; iTemp10 [lr13:14]{int}[r2 r3] = @[iTemp7 [lr9:13]{_far * int}[DPTR]]
9821 ; *(iTemp6 [lr5:16]{_near * int}[r0]) := iTemp10 [lr13:14]{int}[r2 r3]
9847 ; iTemp6 [lr5:16]{_near * int}[r0] =
9852 ; iTemp6 [lr5:16]{_near * int}[r0] +
9869 ; goto _whilecontinue_0($1)
9881 ; _whilebreak_0($3) :
9891 ; iTemp2 [lr18:40]{short}[r2] := 0x0 {short}
9903 ; iTemp11 [lr19:40]{short}[r3] := 0x0 {short}
9915 ; iTemp21 [lr21:38]{short}[r4] := 0x0 {short}
9927 ; iTemp23 [lr22:38]{int}[r5 r6] := 0xa {int}
9946 ; iTemp17 [lr23:38]{int}[r7 r0] := 0x1e {int}
9975 ; iTemp13 [lr25:26]{char}[CC] = iTemp21 [lr21:38]{short}[r4] < 0xa {short}
9980 ; if iTemp13 [lr25:26]{char}[CC] == 0 goto _forbreak_0($7)
10025 ; iTemp2 [lr18:40]{short}[r2] = iTemp2 [lr18:40]{short}[r2] +
10030 ; iTemp21 [lr21:38]{short}[r4]
10056 ; iTemp15 [lr29:30]{short}[r1] = iTemp21 [lr21:38]{short}[r4] * 0x3 {short}
10089 ; iTemp11 [lr19:40]{short}[r3] = iTemp11 [lr19:40]{short}[r3] +
10094 ; iTemp15 [lr29:30]{short}[r1]
10113 ; iTemp17 [lr23:38]{int}[r7 r0]= iTemp17 [lr23:38]{int}[r7 r0]- 0x3 {short}
10160 ; _gint [lr0:0]{int} = _gint [lr0:0]{int} + iTemp17 [lr23:38]{int}[r7 r0]
10207 ; iTemp21 [lr21:38]{short}[r4] = iTemp21 [lr21:38]{short}[r4] + 0x1 {short}
10219 ; iTemp23 [lr22:38]{int}[r5 r6]= iTemp23 [lr22:38]{int}[r5 r6]- 0x1 {short}
10233 cjne r5,#0xff,00104$
10245 ; goto _forcond_0($4)
10257 ; _forbreak_0($7) :
10267 ; ret iTemp24 [lr40:41]{short}
10310 A few words about basic block successors, predecessors and dominators
10313 Successors are basic blocks that might execute after this basic block.
10315 Predecessors are basic blocks that might execute before reaching this basic
10318 Dominators are basic blocks that WILL execute before reaching this basic
10344 a) succList of [BB2] = [BB4], of [BB3] = [BB4], of [BB1] = [BB2,BB3]
10347 b) predList of [BB2] = [BB1], of [BB3] = [BB1], of [BB4] = [BB2,BB3]
10350 c) domVect of [BB4] = BB1 ...
10351 here we are not sure if BB2 or BB3 was executed but we are SURE that BB1
10359 \begin_inset LatexCommand \url{http://sdcc.sourceforge.net#Who}
10369 Thanks to all the other volunteer developers who have helped with coding,
10370 testing, web-page creation, distribution sets, etc.
10371 You know who you are :-)
10378 This document was initially written by Sandeep Dutta
10381 All product names mentioned herein may be trademarks of their respective
10387 \begin_inset LatexCommand \printindex{}
projects / fw / sdcc / blob