1 #LyX 1.2 created this file. For more info see http://www.lyx.org/
5 \usepackage[colorlinks=true,linkcolor=blue]{hyperref}
11 \paperfontsize default
18 \use_numerical_citations 0
19 \paperorientation portrait
22 \paragraph_separation indent
24 \quotes_language swedish
32 Please note: double dashed longoptions (e.g.
33 --version) need three dashes in this document to be visable in html and
37 SDCC Compiler User Guide
41 \begin_inset LatexCommand \tableofcontents{}
58 is a Freeware, retargettable, optimizing ANSI-C compiler by
62 designed for 8 bit Microprocessors.
63 The current version targets Intel MCS51 based Microprocessors(8051,8052,
64 etc), Zilog Z80 based MCUs, and the Dallas DS80C390 variant.
65 It can be retargetted for other microprocessors, support for PIC, AVR and
66 186 is under development.
67 The entire source code for the compiler is distributed under GPL.
68 SDCC uses ASXXXX & ASLINK, a Freeware, retargettable assembler & linker.
69 SDCC has extensive language extensions suitable for utilizing various microcont
70 rollers and underlying hardware effectively.
75 In addition to the MCU specific optimizations SDCC also does a host of standard
79 global sub expression elimination,
82 loop optimizations (loop invariant, strength reduction of induction variables
86 constant folding & propagation,
102 For the back-end SDCC uses a global register allocation scheme which should
103 be well suited for other 8 bit MCUs.
108 The peep hole optimizer uses a rule based substitution mechanism which is
114 Supported data-types are:
117 char (8 bits, 1 byte),
120 short and int (16 bits, 2 bytes),
123 long (32 bit, 4 bytes)
130 The compiler also allows
132 inline assembler code
134 to be embedded anywhere in a function.
135 In addition, routines developed in assembly can also be called.
139 SDCC also provides an option (--cyclomatic) to report the relative complexity
141 These functions can then be further optimized, or hand coded in assembly
147 SDCC also comes with a companion source level debugger SDCDB, the debugger
148 currently uses ucSim a freeware simulator for 8051 and other micro-controllers.
153 The latest version can be downloaded from
154 \begin_inset LatexCommand \url{http://sdcc.sourceforge.net/}
166 All packages used in this compiler system are
174 ; source code for all the sub-packages (pre-processor, assemblers, linkers
175 etc) is distributed with the package.
176 This documentation is maintained using a freeware word processor (LyX).
178 This program is free software; you can redistribute it and/or modify it
179 under the terms of the GNU General Public License as published by the Free
180 Software Foundation; either version 2, or (at your option) any later version.
181 This program is distributed in the hope that it will be useful, but WITHOUT
182 ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
183 FOR A PARTICULAR PURPOSE.
184 See the GNU General Public License for more details.
185 You should have received a copy of the GNU General Public License along
186 with this program; if not, write to the Free Software Foundation, 59 Temple
187 Place - Suite 330, Boston, MA 02111-1307, USA.
188 In other words, you are welcome to use, share and improve this program.
189 You are forbidden to forbid anyone else to use, share and improve what
191 Help stamp out software-hoarding!
194 Typographic conventions
197 Throughout this manual, we will use the following convention.
198 Commands you have to type in are printed in
206 Code samples are printed in
211 Interesting items and new terms are printed in
216 Compatibility with previous versions
219 This version has numerous bug fixes compared with the previous version.
220 But we also introduced some incompatibilities with older versions.
221 Not just for the fun of it, but to make the compiler more stable, efficient
228 short is now equivalent to int (16 bits), it used to be equivalent to char
229 (8 bits) which is not ANSI compliant
232 the default directory for gcc-builds where include, library and documention
233 files are stored is now in /usr/local/share
236 char type parameters to vararg functions are casted to int unless explicitly
253 will push a as an int and as a char resp.
256 option ---regextend has been removed
259 option ---noregparms has been removed
262 option ---stack-after-data has been removed
267 <pending: more incompatibilities?>
273 What do you need before you start installation of SDCC? A computer, and
275 The preferred method of installation is to compile SDCC from source using
277 For Windows some pre-compiled binary distributions are available for your
279 You should have some experience with command line tools and compiler use.
285 The SDCC home page at
286 \begin_inset LatexCommand \url{http://sdcc.sourceforge.net/}
290 is a great place to find distribution sets.
291 You can also find links to the user mailing lists that offer help or discuss
292 SDCC with other SDCC users.
293 Web links to other SDCC related sites can also be found here.
294 This document can be found in the DOC directory of the source package as
296 Some of the other tools (simulator and assembler) included with SDCC contain
297 their own documentation and can be found in the source distribution.
298 If you want the latest unreleased software, the complete source package
299 is available directly by anonymous CVS on cvs.sdcc.sourceforge.net.
302 Wishes for the future
305 There are (and always will be) some things that could be done.
306 Here are some I can think of:
313 char KernelFunction3(char p) at 0x340;
319 If you can think of some more, please send them to the list.
325 <pending: And then of course a proper index-table
326 \begin_inset LatexCommand \index{index}
339 The install paths, search paths and other options are defined when running
341 The defaults can be overriden by:
343 \labelwidthstring 00.00.0000
345 ---prefix see tabel below
347 \labelwidthstring 00.00.0000
349 ---exec_prefix see tabel below
351 \labelwidthstring 00.00.0000
353 ---bindir see tabel below
355 \labelwidthstring 00.00.0000
357 ---datadir see tabel below
359 \labelwidthstring 00.00.0000
361 docdir environment variable, see tabel below
363 \labelwidthstring 00.00.0000
365 include_dir_suffix environment variable, see tabel below
367 \labelwidthstring 00.00.0000
369 lib_dir_suffix environment variable, see tabel below
371 \labelwidthstring 00.00.0000
373 sdccconf_h_dir_separator environment variable, either / or
378 This character will only be used in sdccconf.h; don't forget it's a C-header,
379 therefore a double-backslash is needed there.
381 \labelwidthstring 00.00.0000
383 ---disable-mcs51-port Excludes the Intel mcs51 port
385 \labelwidthstring 00.00.0000
387 ---disable-gbz80-port Excludes the Gameboy gbz80 port
389 \labelwidthstring 00.00.0000
391 ---disable-z80-port Excludes the z80 port
393 \labelwidthstring 00.00.0000
395 ---disable-avr-port Excludes the AVR port
397 \labelwidthstring 00.00.0000
399 ---disable-ds390-port Excludes the DS390 port
401 \labelwidthstring 00.00.0000
403 ---disable-pic-port Excludes the PIC port
405 \labelwidthstring 00.00.0000
407 ---disable-xa51-port Excludes the XA51 port
409 \labelwidthstring 00.00.0000
411 ---disable-ucsim Disables configuring and building of ucsim
413 \labelwidthstring 00.00.0000
415 ---disable-device-lib-build Disables automatically building device libraries
417 \labelwidthstring 00.00.0000
419 ---disable-packihx Disables building packihx
421 \labelwidthstring 00.00.0000
423 ---enable-libgc Use the Bohem memory allocator.
424 Lower runtime footprint.
427 Furthermore the environment variables CC, CFLAGS, ...
428 the tools and their arguments can be influenced.
429 Please see `configure ---help` and the man/info pages of `configure` for
434 The names of the standard libraries STD_LIB, STD_INT_LIB, STD_LONG_LIB,
435 STD_FP_LIB, STD_DS390_LIB, STD_XA51_LIB and the environment variables SDCC_DIR_
436 NAME, SDCC_INCLUDE_NAME, SDCC_LIB_NAME are defined by `configure` too.
437 At the moment it's not possible to change the default settings (it was
438 simply never required.
442 These configure options are compiled into the binaries, and can only be
443 changed by rerunning 'configure' and recompiling SDCC.
444 The configure options are written in
448 to distinguish them from run time environment variables (see section search
454 \begin_inset Quotes sld
458 \begin_inset Quotes srd
461 are used by the SDCC team to build the official Win32 binaries.
462 The SDCC team uses Mingw32 to build the official Windows binaries, because
469 a gcc compiler and last but not least
472 the binaries can be built by cross compiling on Sourceforge's compile farm.
475 See the examples, how to pass the Win32 settings to 'configure'.
476 The other Win32 builds using Borland, VC or whatever don't use 'configure',
477 but a header file sdcc_vc_in.h is the same as sdccconf.h built by 'configure'
488 <lyxtabular version="3" rows="8" columns="3">
490 <column alignment="left" valignment="top" leftline="true" width="0in">
491 <column alignment="left" valignment="top" leftline="true" width="0in">
492 <column alignment="left" valignment="top" leftline="true" rightline="true" width="0in">
493 <row topline="true" bottomline="true">
494 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
502 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
510 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
520 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
530 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
538 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
550 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
560 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
570 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
582 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
592 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
604 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
620 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
630 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
642 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
654 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
664 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
676 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
692 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
702 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
710 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
719 <row topline="true" 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">
757 'configure' also computes relative paths.
758 This is needed for full relocatability of a binary package and to complete
759 search paths (see section search paths below):
765 <lyxtabular version="3" rows="4" columns="3">
767 <column alignment="left" valignment="top" leftline="true" width="0in">
768 <column alignment="left" valignment="top" leftline="true" width="0in">
769 <column alignment="left" valignment="top" leftline="true" rightline="true" width="0in">
770 <row topline="true" bottomline="true">
771 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
779 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
787 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
796 <row topline="true" bottomline="true">
797 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
807 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
815 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
826 <row bottomline="true">
827 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
837 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
845 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
854 <row bottomline="true">
855 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
865 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
873 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
895 ./configure ---prefix=
896 \begin_inset Quotes srd
900 \begin_inset Quotes srd
904 \begin_inset Quotes srd
908 \begin_inset Quotes srd
914 ./configure ---disable-avr-port ---disable-xa51-port
917 To crosscompile on linux for Mingw32 (see also 'sdcc/support/scripts/sdcc_mingw3
927 \begin_inset Quotes srd
931 \begin_inset Quotes srd
935 \begin_inset Quotes srd
939 \begin_inset Quotes srd
948 \begin_inset Quotes srd
951 i586-mingw32msvc-ranlib
952 \begin_inset Quotes srd
961 \begin_inset Quotes srd
964 i586-mingw32msvc-strip
965 \begin_inset Quotes srd
974 \begin_inset Quotes srd
978 \begin_inset Quotes srd
987 \begin_inset Quotes srd
991 \begin_inset Quotes srd
1000 \begin_inset Quotes srd
1004 \begin_inset Quotes srd
1013 \begin_inset Quotes srd
1017 \begin_inset Quotes srd
1026 \begin_inset Quotes srd
1030 \begin_inset Quotes srd
1038 sdccconf_h_dir_separator=
1039 \begin_inset Quotes srd
1051 \begin_inset Quotes srd
1059 ---disable-device-lib-build
1069 ---host=i586-mingw32msvc ---build=unknown-unknown-linux-gnu
1073 \begin_inset Quotes sld
1077 \begin_inset Quotes srd
1080 compile on Cygwin for Mingw32(see also sdcc/support/scripts/sdcc_cygwin_mingw32)
1090 \begin_inset Quotes srd
1094 \begin_inset Quotes srd
1103 \begin_inset Quotes srd
1107 \begin_inset Quotes srd
1116 \begin_inset Quotes srd
1120 \begin_inset Quotes srd
1129 \begin_inset Quotes srd
1133 \begin_inset Quotes srd
1142 \begin_inset Quotes srd
1146 \begin_inset Quotes srd
1155 \begin_inset Quotes srd
1159 \begin_inset Quotes srd
1168 \begin_inset Quotes srd
1172 \begin_inset Quotes srd
1180 sdccconf_h_dir_separator=
1181 \begin_inset Quotes srd
1193 \begin_inset Quotes srd
1204 'configure' is quite slow on Cygwin (at least on windows before Win2000/XP).
1205 The option '--C' turns on caching, which gives a little bit extra speed.
1206 However if options are changed, it can be necessary to delete the config.cache
1214 Binary files (preprocessor, assembler and linker)
1218 \begin_inset Tabular
1219 <lyxtabular version="3" rows="2" columns="3">
1221 <column alignment="left" valignment="top" leftline="true" width="0in">
1222 <column alignment="left" valignment="top" leftline="true" width="0in">
1223 <column alignment="left" valignment="top" leftline="true" rightline="true" width="0in">
1224 <row topline="true" bottomline="true">
1225 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1233 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1241 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1250 <row topline="true" bottomline="true">
1251 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1261 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1269 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1295 \begin_inset Tabular
1296 <lyxtabular version="3" rows="2" columns="3">
1298 <column alignment="block" valignment="top" leftline="true" width="1.6in">
1299 <column alignment="left" valignment="top" leftline="true" width="0in">
1300 <column alignment="center" valignment="top" leftline="true" rightline="true" width="0in">
1301 <row topline="true" bottomline="true">
1302 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1310 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1318 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1327 <row topline="true" bottomline="true">
1328 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
1340 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1345 /usr/local/share/sdcc/include
1348 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1374 is auto-appended by the compiler, e.g.
1375 small, large, z80, ds390 etc.)
1379 \begin_inset Tabular
1380 <lyxtabular version="3" rows="2" columns="3">
1382 <column alignment="left" valignment="top" leftline="true" width="0in">
1383 <column alignment="left" valignment="top" leftline="true" width="0in">
1384 <column alignment="left" valignment="top" leftline="true" rightline="true" width="0in">
1385 <row topline="true" bottomline="true">
1386 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1394 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1402 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1411 <row topline="true" bottomline="true">
1412 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1419 $DATADIR/$LIB_DIR_SUFFIX
1422 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1427 /usr/local/share/sdcc/lib
1430 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1456 \begin_inset Tabular
1457 <lyxtabular version="3" rows="2" columns="3">
1459 <column alignment="left" valignment="top" leftline="true" width="0in">
1460 <column alignment="left" valignment="top" leftline="true" width="0in">
1461 <column alignment="left" valignment="top" leftline="true" rightline="true" width="0in">
1462 <row topline="true" bottomline="true">
1463 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1471 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1479 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1488 <row topline="true" bottomline="true">
1489 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1499 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1504 /usr/local/share/sdcc/doc
1507 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1528 The install paths can still be changed during `make install` with e.g.:
1531 make install prefix=$(HOME)/local/sdcc
1534 Of course this doesn't change the search paths compiled into the binaries.
1540 Some search paths or parts of them are determined by configure variables
1545 , see section above).
1546 Further search paths are determined by environment variables during runtime.
1549 The paths searched when running the compiler are as follows (the first catch
1555 Binary files (preprocessor, assembler and linker)
1558 \begin_inset Tabular
1559 <lyxtabular version="3" rows="4" columns="3">
1561 <column alignment="left" valignment="top" leftline="true" width="0in">
1562 <column alignment="left" valignment="top" leftline="true" width="0in">
1563 <column alignment="left" valignment="top" leftline="true" rightline="true" width="0in">
1564 <row topline="true" bottomline="true">
1565 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1573 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1581 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1590 <row topline="true">
1591 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1601 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1609 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1620 <row topline="true">
1621 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1626 Path of argv[0] (if available)
1629 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1637 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1646 <row topline="true" bottomline="true">
1647 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1655 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1663 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1684 \begin_inset Tabular
1685 <lyxtabular version="3" rows="6" columns="3">
1687 <column alignment="block" valignment="top" leftline="true" width="1.5in">
1688 <column alignment="block" valignment="top" leftline="true" width="1.5in">
1689 <column alignment="left" valignment="top" leftline="true" rightline="true" width="0in">
1690 <row topline="true" bottomline="true">
1691 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1699 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1707 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1716 <row topline="true">
1717 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1725 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1733 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1742 <row topline="true">
1743 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
1751 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1759 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1768 <row topline="true">
1769 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
1783 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
1795 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1806 <row topline="true">
1807 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
1825 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
1875 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1888 <row topline="true" bottomline="true">
1889 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
1905 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
1910 /usr/local/share/sdcc/
1915 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1932 The option ---nostdinc disables the last two search paths.
1939 With the exception of
1940 \begin_inset Quotes sld
1944 \begin_inset Quotes srd
1951 is auto-appended by the compiler (e.g.
1952 small, large, z80, ds390 etc.).
1956 \begin_inset Tabular
1957 <lyxtabular version="3" rows="6" columns="3">
1959 <column alignment="block" valignment="top" leftline="true" width="1.7in">
1960 <column alignment="left" valignment="top" leftline="true" width="1.2in">
1961 <column alignment="block" valignment="top" leftline="true" rightline="true" width="1.2in">
1962 <row topline="true" bottomline="true">
1963 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
1971 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
1979 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
1988 <row topline="true">
1989 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
1997 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
2005 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
2014 <row topline="true">
2015 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
2027 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
2039 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
2054 <row topline="true">
2055 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
2066 $LIB_DIR_SUFFIX/<model>
2069 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
2083 <cell alignment="left" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
2100 <row topline="true">
2101 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
2116 $LIB_DIR_SUFFIX/<model>
2119 <cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
2172 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
2228 <row topline="true" bottomline="true">
2229 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
2238 $LIB_DIR_SUFFIX/<model>
2241 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
2246 /usr/local/share/sdcc/
2253 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
2269 Don't delete any of the stray spaces in the table above without checking
2270 the HTML output (last line)!
2276 The option ---nostdlib disables the last two search paths.
2280 \layout Subsubsection
2282 Building SDCC on Linux
2287 Download the source package
2289 either from the SDCC CVS repository or from the
2290 \begin_inset LatexCommand \url[nightly snapshots]{http://sdcc.sourceforge.net/snap.php}
2296 , it will be named something like sdcc
2309 Bring up a command line terminal, such as xterm.
2314 Unpack the file using a command like:
2317 "tar -xzf sdcc.src.tar.gz
2322 , this will create a sub-directory called sdcc with all of the sources.
2325 Change directory into the main SDCC directory, for example type:
2342 This configures the package for compilation on your system.
2358 All of the source packages will compile, this can take a while.
2374 This copies the binary executables, the include files, the libraries and
2375 the documentation to the install directories.
2376 \layout Subsubsection
2378 Building SDCC on OSX 2.x
2381 Follow the instruction for Linux.
2385 On OSX 2.x it was reported, that the default gcc (version 3.1 20020420 (prerelease
2386 )) fails to compile SDCC.
2387 Fortunately there's also gcc 2.9.x installed, which works fine.
2388 This compiler can be selected by running 'configure' with:
2391 ./configure CC=gcc2 CXX=g++2
2392 \layout Subsubsection
2394 Crosscompiling SDCC on Linux for Windows
2397 With the Mingw32 gcc crosscompiler it's easy to compile SDCC for Win32.
2398 See section 'Configure Options'.
2399 \layout Subsubsection
2401 Building SDCC on Windows
2404 With the exception of Cygwin the SDCC binaries uCsim and sdcdb can't be
2406 They use Unix-sockets, which are not available on Win32.
2407 \layout Subsubsection
2409 Windows Install Using a Binary Package
2412 Download the binary package and unpack it using your favorite unpacking
2413 tool (gunzip, WinZip, etc).
2414 This should unpack to a group of sub-directories.
2415 An example directory structure after unpacking the mingw32 package is:
2420 bin for the executables, c:
2428 lib for the include and libraries.
2431 Adjust your environment variable PATH to include the location of the bin
2432 directory or start sdcc using the full path.
2433 \layout Subsubsection
2435 Building SDCC using Cygwin and Mingw32
2438 For building and installing a Cygwin executable follow the instructions
2444 \begin_inset Quotes sld
2448 \begin_inset Quotes srd
2451 Win32-binary can be built, which will not need the Cygwin-DLL.
2452 For the necessary 'configure' options see section 'configure options' or
2453 the script 'sdcc/support/scripts/sdcc_cygwinmingw32'.
2457 In order to install Cygwin on Windows download setup.exe from
2458 \begin_inset LatexCommand \url[www.cygwin.com]{http://www.cygwin.com/}
2464 \begin_inset Quotes sld
2467 default text file type
2468 \begin_inset Quotes srd
2472 \begin_inset Quotes sld
2476 \begin_inset Quotes srd
2479 and download/install at least the following packages.
2480 Some packages are selected by default, others will be automatically selected
2481 because of dependencies with the manually selected packages.
2482 Never deselect these packages!
2491 gcc ; version 3.x is fine, no need to use the old 2.9x
2494 binutils ; selected with gcc
2500 rxvt ; a nice console, which makes life much easier under windoze (see below)
2503 man ; not really needed for building SDCC, but you'll miss it sooner or
2507 less ; not really needed for building SDCC, but you'll miss it sooner or
2511 cvs ; only if you use CVS access
2514 If you want to develop something you'll need:
2517 python ; for the regression tests
2520 gdb ; the gnu debugger, together with the nice GUI
2521 \begin_inset Quotes sld
2525 \begin_inset Quotes srd
2531 openssh ; to access the CF or commit changes
2534 autoconf and autoconf-devel ; if you want to fight with 'configure', don't
2535 use autoconf-stable!
2538 rxvt is a nice console with history.
2539 Replace in your cygwin.bat the line
2548 rxvt -sl 1000 -fn "Lucida Console-12" -sr -cr red
2551 -bg black -fg white -geometry 100x65 -e bash --login
2554 Text selected with the mouse is automatically copied to the clipboard, pasting
2555 works with shift-insert.
2559 The other good tip is to make sure you have no //c/-style paths anywhere,
2560 use /cygdrive/c/ instead.
2561 Using // invokes a network lookup which is very slow.
2563 \begin_inset Quotes sld
2567 \begin_inset Quotes srd
2570 is too long, you can change it with e.g.
2576 SDCC sources use the unix line ending LF.
2577 Life is much easier, if you store the source tree on a drive, which is
2578 mount in binary mode.
2579 And use an editor which can handle LF-only line endings.
2580 Make sure not to commit files with windows line endings.
2581 \layout Subsubsection
2583 Windows Install Using Microsoft Visual C++ 6.0/NET
2588 Download the source package
2590 either from the SDCC CVS repository or from the
2591 \begin_inset LatexCommand \url[nightly snapshots]{http://sdcc.sourceforge.net/snap.php}
2597 , it will be named something like sdcc
2604 SDCC is distributed with all the projects, workspaces, and files you need
2605 to build it using Visual C++ 6.0/NET.
2606 The workspace name is 'sdcc.dsw'.
2607 Please note that as it is now, all the executables are created in a folder
2611 Once built you need to copy the executables from sdcc
2615 bin before runnng SDCC.
2620 In order to build SDCC with Visual C++ 6.0/NET you need win32 executables
2621 of bison.exe, flex.exe, and gawk.exe.
2622 One good place to get them is
2623 \begin_inset LatexCommand \url[here]{http://unxutils.sourceforge.net}
2631 Download the file UnxUtils.zip.
2632 Now you have to install the utilities and setup Visual C++ so it can locate
2633 the required programs.
2634 Here there are two alternatives (choose one!):
2641 a) Extract UnxUtils.zip to your C:
2643 hard disk PRESERVING the original paths, otherwise bison won't work.
2644 (If you are using WinZip make certain that 'Use folder names' is selected)
2648 b) In the Visual C++ IDE click Tools, Options, select the Directory tab,
2649 in 'Show directories for:' select 'Executable files', and in the directories
2650 window add a new path: 'C:
2660 (As a side effect, you get a bunch of Unix utilities that could be useful,
2661 such as diff and patch.)
2668 This one avoids extracting a bunch of files you may not use, but requires
2673 a) Create a directory were to put the tools needed, or use a directory already
2681 b) Extract 'bison.exe', 'bison.hairy', 'bison.simple', 'flex.exe', and gawk.exe
2682 to such directory WITHOUT preserving the original paths.
2683 (If you are using WinZip make certain that 'Use folder names' is not selected)
2687 c) Rename bison.exe to '_bison.exe'.
2691 d) Create a batch file 'bison.bat' in 'C:
2695 ' and add these lines:
2715 _bison %1 %2 %3 %4 %5 %6 %7 %8 %9
2719 Steps 'c' and 'd' are needed because bison requires by default that the
2720 files 'bison.simple' and 'bison.hairy' reside in some weird Unix directory,
2721 '/usr/local/share/' I think.
2722 So it is necessary to tell bison where those files are located if they
2723 are not in such directory.
2724 That is the function of the environment variables BISON_SIMPLE and BISON_HAIRY.
2728 e) In the Visual C++ IDE click Tools, Options, select the Directory tab,
2729 in 'Show directories for:' select 'Executable files', and in the directories
2730 window add a new path: 'c:
2733 Note that you can use any other path instead of 'c:
2735 util', even the path where the Visual C++ tools are, probably: 'C:
2739 Microsoft Visual Studio
2744 So you don't have to execute step 'e' :)
2748 Open 'sdcc.dsw' in Visual Studio, click 'build all', when it finishes copy
2749 the executables from sdcc
2753 bin, and you can compile using sdcc.
2754 \layout Subsubsection
2756 Windows Install Using Borland
2759 From the sdcc directory, run the command "make -f Makefile.bcc".
2760 This should regenerate all the .exe files in the bin directory except for
2761 sdcdb.exe (which currently doesn't build under Borland C++).
2764 If you modify any source files and need to rebuild, be aware that the dependanci
2765 es may not be correctly calculated.
2766 The safest option is to delete all .obj files and run the build again.
2767 From a Cygwin BASH prompt, this can easily be done with the commmand:
2777 ( -name '*.obj' -o -name '*.lib' -o -name '*.rul'
2779 ) -print -exec rm {}
2788 or on Windows NT/2000/XP from the command prompt with the commmand:
2795 del /s *.obj *.lib *.rul
2798 from the sdcc directory.
2801 Building the Documentation
2808 Testing out the SDCC Compiler
2811 The first thing you should do after installing your SDCC compiler is to
2819 at the prompt, and the program should run and tell you the version.
2820 If it doesn't run, or gives a message about not finding sdcc program, then
2821 you need to check over your installation.
2822 Make sure that the sdcc bin directory is in your executable search path
2823 defined by the PATH environment setting (see the Trouble-shooting section
2825 Make sure that the sdcc program is in the bin folder, if not perhaps something
2826 did not install correctly.
2834 is commonly installed as described in section
2835 \begin_inset Quotes sld
2838 Install and search paths
2839 \begin_inset Quotes srd
2848 Make sure the compiler works on a very simple example.
2849 Type in the following test.c program using your favorite
2884 Compile this using the following command:
2893 If all goes well, the compiler will generate a test.asm and test.rel file.
2894 Congratulations, you've just compiled your first program with SDCC.
2895 We used the -c option to tell SDCC not to link the generated code, just
2896 to keep things simple for this step.
2904 The next step is to try it with the linker.
2914 If all goes well the compiler will link with the libraries and produce
2915 a test.ihx output file.
2920 (no test.ihx, and the linker generates warnings), then the problem is most
2921 likely that sdcc cannot find the
2925 usr/local/share/sdcc/lib directory
2929 (see the Install trouble-shooting section for suggestions).
2937 The final test is to ensure sdcc can use the
2941 header files and libraries.
2942 Edit test.c and change it to the following:
2962 strcpy(str1, "testing");
2971 Compile this by typing
2978 This should generate a test.ihx output file, and it should give no warnings
2979 such as not finding the string.h file.
2980 If it cannot find the string.h file, then the problem is that sdcc cannot
2981 find the /usr/local/share/sdcc/include directory
2985 (see the Install trouble-shooting section for suggestions).
2988 Install Trouble-shooting
2989 \layout Subsubsection
2991 SDCC does not build correctly.
2994 A thing to try is starting from scratch by unpacking the .tgz source package
2995 again in an empty directory.
3003 ./configure 2>&1 | tee configure.log
3017 make 2>&1 | tee make.log
3024 If anything goes wrong, you can review the log files to locate the problem.
3025 Or a relevant part of this can be attached to an email that could be helpful
3026 when requesting help from the mailing list.
3027 \layout Subsubsection
3030 \begin_inset Quotes sld
3034 \begin_inset Quotes srd
3041 \begin_inset Quotes sld
3045 \begin_inset Quotes srd
3048 command is a script that analyzes your system and performs some configuration
3049 to ensure the source package compiles on your system.
3050 It will take a few minutes to run, and will compile a few tests to determine
3051 what compiler features are installed.
3052 \layout Subsubsection
3055 \begin_inset Quotes sld
3059 \begin_inset Quotes srd
3065 This runs the GNU make tool, which automatically compiles all the source
3066 packages into the final installed binary executables.
3067 \layout Subsubsection
3070 \begin_inset Quotes sld
3074 \begin_inset Quotes erd
3080 This will install the compiler, other executables libraries and include
3081 files in to the appropriate directories.
3083 \begin_inset Quotes sld
3086 Install and Search PATHS
3087 \begin_inset Quotes srd
3092 On most systems you will need super-user privilages to do this.
3098 SDCC is not just a compiler, but a collection of tools by various developers.
3099 These include linkers, assemblers, simulators and other components.
3100 Here is a summary of some of the components.
3101 Note that the included simulator and assembler have separate documentation
3102 which you can find in the source package in their respective directories.
3103 As SDCC grows to include support for other processors, other packages from
3104 various developers are included and may have their own sets of documentation.
3108 You might want to look at the files which are installed in <installdir>.
3109 At the time of this writing, we find the following programs for gcc-builds:
3113 In <installdir>/bin:
3116 sdcc - The compiler.
3119 sdcpp - The C preprocessor.
3122 asx8051 - The assembler for 8051 type processors.
3129 as-gbz80 - The Z80 and GameBoy Z80 assemblers.
3132 aslink -The linker for 8051 type processors.
3139 link-gbz80 - The Z80 and GameBoy Z80 linkers.
3142 s51 - The ucSim 8051 simulator.
3145 sdcdb - The source debugger.
3148 packihx - A tool to pack (compress) Intel hex files.
3151 In <installdir>/share/sdcc/include
3157 In <installdir>/share/sdcc/lib
3160 the subdirs src and small, large, z80, gbz80 and ds390 with the precompiled
3164 In <installdir>/share/sdcc/doc
3170 As development for other processors proceeds, this list will expand to include
3171 executables to support processors like AVR, PIC, etc.
3172 \layout Subsubsection
3177 This is the actual compiler, it in turn uses the c-preprocessor and invokes
3178 the assembler and linkage editor.
3179 \layout Subsubsection
3181 sdcpp - The C-Preprocessor
3184 The preprocessor is a modified version of the GNU preprocessor.
3185 The C preprocessor is used to pull in #include sources, process #ifdef
3186 statements, #defines and so on.
3187 \layout Subsubsection
3189 asx8051, as-z80, as-gbz80, aslink, link-z80, link-gbz80 - The Assemblers
3193 This is retargettable assembler & linkage editor, it was developed by Alan
3195 John Hartman created the version for 8051, and I (Sandeep) have made some
3196 enhancements and bug fixes for it to work properly with the SDCC.
3197 \layout Subsubsection
3202 S51 is a freeware, opensource simulator developed by Daniel Drotos (
3203 \begin_inset LatexCommand \url{mailto:drdani@mazsola.iit.uni-miskolc.hu}
3208 The simulator is built as part of the build process.
3209 For more information visit Daniel's website at:
3210 \begin_inset LatexCommand \url{http://mazsola.iit.uni-miskolc.hu/~drdani/embedded/s51}
3215 It currently support the core mcs51, the Dallas DS80C390 and the Philips
3217 \layout Subsubsection
3219 sdcdb - Source Level Debugger
3225 <todo: is this thing still alive?>
3232 Sdcdb is the companion source level debugger.
3233 The current version of the debugger uses Daniel's Simulator S51, but can
3234 be easily changed to use other simulators.
3241 \layout Subsubsection
3243 Single Source File Projects
3246 For single source file 8051 projects the process is very simple.
3247 Compile your programs with the following command
3250 "sdcc sourcefile.c".
3254 This will compile, assemble and link your source file.
3255 Output files are as follows
3259 sourcefile.asm - Assembler source file created by the compiler
3261 sourcefile.lst - Assembler listing file created by the Assembler
3263 sourcefile.rst - Assembler listing file updated with linkedit information,
3264 created by linkage editor
3266 sourcefile.sym - symbol listing for the sourcefile, created by the assembler
3268 sourcefile.rel - Object file created by the assembler, input to Linkage editor
3270 sourcefile.map - The memory map for the load module, created by the Linker
3272 sourcefile.mem - A file with a summary of the memory ussage
3274 sourcefile.ihx - The load module in Intel hex format (you can select the
3275 Motorola S19 format with ---out-fmt-s19)
3277 sourcefile.adb - An intermediate file containing debug information needed
3278 to create the .cdb file (with ---debug)
3280 sourcefile.cdb - An optional file (with ---debug) containing debug information
3283 - (no extension) An optional AOMF51 file containing debug information (with
3286 sourcefile.dump* - Dump file to debug the compiler it self (with ---dumpall)
3288 \begin_inset Quotes sld
3291 Anatomy of the compiler
3292 \begin_inset Quotes srd
3296 \layout Subsubsection
3298 Projects with Multiple Source Files
3301 SDCC can compile only ONE file at a time.
3302 Let us for example assume that you have a project containing the following
3307 foo1.c (contains some functions)
3309 foo2.c (contains some more functions)
3311 foomain.c (contains more functions and the function main)
3319 The first two files will need to be compiled separately with the commands:
3351 Then compile the source file containing the
3355 function and link the files together with the following command:
3363 foomain.c\SpecialChar ~
3364 foo1.rel\SpecialChar ~
3376 can be separately compiled as well:
3387 sdcc foomain.rel foo1.rel foo2.rel
3394 The file containing the
3409 file specified in the command line, since the linkage editor processes
3410 file in the order they are presented to it.
3411 \layout Subsubsection
3413 Projects with Additional Libraries
3416 Some reusable routines may be compiled into a library, see the documentation
3417 for the assembler and linkage editor (which are in <installdir>/share/sdcc/doc)
3423 Libraries created in this manner can be included in the command line.
3424 Make sure you include the -L <library-path> option to tell the linker where
3425 to look for these files if they are not in the current directory.
3426 Here is an example, assuming you have the source file
3438 (if that is not the same as your current project):
3445 sdcc foomain.c foolib.lib -L mylib
3456 must be an absolute path name.
3460 The most efficient way to use libraries is to keep seperate modules in seperate
3462 The lib file now should name all the modules.rel files.
3463 For an example see the standard library file
3467 in the directory <installdir>/share/lib/small.
3470 Command Line Options
3471 \layout Subsubsection
3473 Processor Selection Options
3475 \labelwidthstring 00.00.0000
3481 Generate code for the MCS51 (8051) family of processors.
3482 This is the default processor target.
3484 \labelwidthstring 00.00.0000
3490 Generate code for the DS80C390 processor.
3492 \labelwidthstring 00.00.0000
3498 Generate code for the Z80 family of processors.
3500 \labelwidthstring 00.00.0000
3506 Generate code for the GameBoy Z80 processor.
3508 \labelwidthstring 00.00.0000
3514 Generate code for the Atmel AVR processor (In development, not complete).
3516 \labelwidthstring 00.00.0000
3522 Generate code for the PIC 14-bit processors (In development, not complete).
3524 \labelwidthstring 00.00.0000
3530 Generate code for the Toshiba TLCS-900H processor (In development, not
3533 \labelwidthstring 00.00.0000
3539 Generate code for the Philips XA51 processor (In development, not complete).
3540 \layout Subsubsection
3542 Preprocessor Options
3544 \labelwidthstring 00.00.0000
3550 The additional location where the pre processor will look for <..h> or
3551 \begin_inset Quotes eld
3555 \begin_inset Quotes erd
3560 \labelwidthstring 00.00.0000
3566 Command line definition of macros.
3567 Passed to the pre processor.
3569 \labelwidthstring 00.00.0000
3575 Tell the preprocessor to output a rule suitable for make describing the
3576 dependencies of each object file.
3577 For each source file, the preprocessor outputs one make-rule whose target
3578 is the object file name for that source file and whose dependencies are
3579 all the files `#include'd in it.
3580 This rule may be a single line or may be continued with `
3582 '-newline if it is long.
3583 The list of rules is printed on standard output instead of the preprocessed
3587 \labelwidthstring 00.00.0000
3593 Tell the preprocessor not to discard comments.
3594 Used with the `-E' option.
3596 \labelwidthstring 00.00.0000
3607 Like `-M' but the output mentions only the user header files included with
3609 \begin_inset Quotes eld
3613 System header files included with `#include <file>' are omitted.
3615 \labelwidthstring 00.00.0000
3621 Assert the answer answer for question, in case it is tested with a preprocessor
3622 conditional such as `#if #question(answer)'.
3623 `-A-' disables the standard assertions that normally describe the target
3626 \labelwidthstring 00.00.0000
3632 (answer) Assert the answer answer for question, in case it is tested with
3633 a preprocessor conditional such as `#if #question(answer)'.
3634 `-A-' disables the standard assertions that normally describe the target
3637 \labelwidthstring 00.00.0000
3643 Undefine macro macro.
3644 `-U' options are evaluated after all `-D' options, but before any `-include'
3645 and `-imacros' options.
3647 \labelwidthstring 00.00.0000
3653 Tell the preprocessor to output only a list of the macro definitions that
3654 are in effect at the end of preprocessing.
3655 Used with the `-E' option.
3657 \labelwidthstring 00.00.0000
3663 Tell the preprocessor to pass all macro definitions into the output, in
3664 their proper sequence in the rest of the output.
3666 \labelwidthstring 00.00.0000
3677 Like `-dD' except that the macro arguments and contents are omitted.
3678 Only `#define name' is included in the output.
3679 \layout Subsubsection
3683 \labelwidthstring 00.00.0000
3693 <absolute path to additional libraries> This option is passed to the linkage
3694 editor's additional libraries search path.
3695 The path name must be absolute.
3696 Additional library files may be specified in the command line.
3697 See section Compiling programs for more details.
3699 \labelwidthstring 00.00.0000
3705 <Value> The start location of the external ram, default value is 0.
3706 The value entered can be in Hexadecimal or Decimal format, e.g.: ---xram-loc
3707 0x8000 or ---xram-loc 32768.
3709 \labelwidthstring 00.00.0000
3715 <Value> The start location of the code segment, default value 0.
3716 Note when this option is used the interrupt vector table is also relocated
3717 to the given address.
3718 The value entered can be in Hexadecimal or Decimal format, e.g.: ---code-loc
3719 0x8000 or ---code-loc 32768.
3721 \labelwidthstring 00.00.0000
3727 <Value> By default the stack is placed after the data segment.
3728 Using this option the stack can be placed anywhere in the internal memory
3730 The value entered can be in Hexadecimal or Decimal format, e.g.
3731 ---stack-loc 0x20 or ---stack-loc 32.
3732 Since the sp register is incremented before a push or call, the initial
3733 sp will be set to one byte prior the provided value.
3734 The provided value should not overlap any other memory areas such as used
3735 register banks or the data segment and with enough space for the current
3738 \labelwidthstring 00.00.0000
3744 <Value> The start location of the internal ram data segment.
3745 The value entered can be in Hexadecimal or Decimal format, eg.
3746 ---data-loc 0x20 or ---data-loc 32.
3747 (By default, the start location of the internal ram data segment is set
3748 as low as possible in memory, taking into account the used register banks
3749 and the bit segment at address 0x20.
3750 For example if register banks 0 and 1 are used without bit variables, the
3751 data segment will be set, if ---data-loc is not used, to location 0x10.)
3753 \labelwidthstring 00.00.0000
3759 <Value> The start location of the indirectly addressable internal ram, default
3761 The value entered can be in Hexadecimal or Decimal format, eg.
3762 ---idata-loc 0x88 or ---idata-loc 136.
3764 \labelwidthstring 00.00.0000
3773 The linker output (final object code) is in Intel Hex format.
3774 (This is the default option).
3776 \labelwidthstring 00.00.0000
3785 The linker output (final object code) is in Motorola S19 format.
3786 \layout Subsubsection
3790 \labelwidthstring 00.00.0000
3796 Generate code for Large model programs see section Memory Models for more
3798 If this option is used all source files in the project should be compiled
3800 In addition the standard library routines are compiled with small model,
3801 they will need to be recompiled.
3803 \labelwidthstring 00.00.0000
3814 Generate code for Small Model programs see section Memory Models for more
3816 This is the default model.
3817 \layout Subsubsection
3821 \labelwidthstring 00.00.0000
3832 Generate 24-bit flat mode code.
3833 This is the one and only that the ds390 code generator supports right now
3834 and is default when using
3839 See section Memory Models for more details.
3841 \labelwidthstring 00.00.0000
3847 Generate code for the 10 bit stack mode of the Dallas DS80C390 part.
3848 This is the one and only that the ds390 code generator supports right now
3849 and is default when using
3854 In this mode, the stack is located in the lower 1K of the internal RAM,
3855 which is mapped to 0x400000.
3856 Note that the support is incomplete, since it still uses a single byte
3857 as the stack pointer.
3858 This means that only the lower 256 bytes of the potential 1K stack space
3859 will actually be used.
3860 However, this does allow you to reclaim the precious 256 bytes of low RAM
3861 for use for the DATA and IDATA segments.
3862 The compiler will not generate any code to put the processor into 10 bit
3864 It is important to ensure that the processor is in this mode before calling
3865 any re-entrant functions compiled with this option.
3866 In principle, this should work with the
3870 option, but that has not been tested.
3871 It is incompatible with the
3876 It also only makes sense if the processor is in 24 bit contiguous addressing
3879 ---model-flat24 option
3882 \layout Subsubsection
3884 Optimization Options
3886 \labelwidthstring 00.00.0000
3892 Will not do global subexpression elimination, this option may be used when
3893 the compiler creates undesirably large stack/data spaces to store compiler
3895 A warning message will be generated when this happens and the compiler
3896 will indicate the number of extra bytes it allocated.
3897 It recommended that this option NOT be used, #pragma\SpecialChar ~
3899 to turn off global subexpression elimination for a given function only.
3901 \labelwidthstring 00.00.0000
3907 Will not do loop invariant optimizations, this may be turned off for reasons
3908 explained for the previous option.
3909 For more details of loop optimizations performed see section Loop Invariants.It
3910 recommended that this option NOT be used, #pragma\SpecialChar ~
3911 NOINVARIANT can be used
3912 to turn off invariant optimizations for a given function only.
3914 \labelwidthstring 00.00.0000
3920 Will not do loop induction optimizations, see section strength reduction
3921 for more details.It is recommended that this option is NOT used, #pragma\SpecialChar ~
3923 ION can be used to turn off induction optimizations for a given function
3926 \labelwidthstring 00.00.0000
3937 Will not generate boundary condition check when switch statements are implement
3938 ed using jump-tables.
3939 See section Switch Statements for more details.
3940 It is recommended that this option is NOT used, #pragma\SpecialChar ~
3942 used to turn off boundary checking for jump tables for a given function
3945 \labelwidthstring 00.00.0000
3954 Will not do loop reversal optimization.
3956 \labelwidthstring 00.00.0000
3962 Will not optimize labels (makes the dumpfiles more readable).
3964 \labelwidthstring 00.00.0000
3970 Will not memcpy initialized data in far space from code space.
3971 This saves a few bytes in code space if you don't have initialized data.
3972 \layout Subsubsection
3976 \labelwidthstring 00.00.0000
3983 will compile and assemble the source, but will not call the linkage editor.
3985 \labelwidthstring 00.00.0000
3991 reads the preprocessed source from standard input and compiles it.
3992 The file name for the assembler output must be specified using the -o option.
3994 \labelwidthstring 00.00.0000
4000 Run only the C preprocessor.
4001 Preprocess all the C source files specified and output the results to standard
4004 \labelwidthstring 00.00.0000
4011 The output path resp.
4012 file where everything will be placed.
4013 If the parameter is a path, it must have a trailing slash (or backslash
4014 for the Windows binaries) to be recognized as a path.
4017 \labelwidthstring 00.00.0000
4028 All functions in the source file will be compiled as
4033 the parameters and local variables will be allocated on the stack.
4034 see section Parameters and Local Variables for more details.
4035 If this option is used all source files in the project should be compiled
4039 \labelwidthstring 00.00.0000
4045 Uses a pseudo stack in the first 256 bytes in the external ram for allocating
4046 variables and passing parameters.
4047 See section on external stack for more details.
4049 \labelwidthstring 00.00.0000
4053 ---callee-saves function1[,function2][,function3]....
4056 The compiler by default uses a caller saves convention for register saving
4057 across function calls, however this can cause unneccessary register pushing
4058 & popping when calling small functions from larger functions.
4059 This option can be used to switch the register saving convention for the
4060 function names specified.
4061 The compiler will not save registers when calling these functions, no extra
4062 code will be generated at the entry & exit for these functions to save
4063 & restore the registers used by these functions, this can SUBSTANTIALLY
4064 reduce code & improve run time performance of the generated code.
4065 In the future the compiler (with interprocedural analysis) will be able
4066 to determine the appropriate scheme to use for each function call.
4067 DO NOT use this option for built-in functions such as _muluint..., if this
4068 option is used for a library function the appropriate library function
4069 needs to be recompiled with the same option.
4070 If the project consists of multiple source files then all the source file
4071 should be compiled with the same ---callee-saves option string.
4072 Also see #pragma\SpecialChar ~
4075 \labelwidthstring 00.00.0000
4084 When this option is used the compiler will generate debug information, that
4085 can be used with the SDCDB.
4086 The debug information is collected in a file with .cdb extension.
4087 For more information see documentation for SDCDB.
4089 \labelwidthstring 00.00.0000
4095 <filename> This option can be used to use additional rules to be used by
4096 the peep hole optimizer.
4097 See section Peep Hole optimizations for details on how to write these rules.
4099 \labelwidthstring 00.00.0000
4110 Stop after the stage of compilation proper; do not assemble.
4111 The output is an assembler code file for the input file specified.
4113 \labelwidthstring 00.00.0000
4117 -Wa_asmOption[,asmOption]
4120 Pass the asmOption to the assembler.
4122 \labelwidthstring 00.00.0000
4126 -Wl_linkOption[,linkOption]
4129 Pass the linkOption to the linker.
4131 \labelwidthstring 00.00.0000
4140 Integer (16 bit) and long (32 bit) libraries have been compiled as reentrant.
4141 Note by default these libraries are compiled as non-reentrant.
4142 See section Installation for more details.
4144 \labelwidthstring 00.00.0000
4153 This option will cause the compiler to generate an information message for
4154 each function in the source file.
4155 The message contains some
4159 information about the function.
4160 The number of edges and nodes the compiler detected in the control flow
4161 graph of the function, and most importantly the
4163 cyclomatic complexity
4165 see section on Cyclomatic Complexity for more details.
4167 \labelwidthstring 00.00.0000
4176 Floating point library is compiled as reentrant.See section Installation
4179 \labelwidthstring 00.00.0000
4185 The compiler will not overlay parameters and local variables of any function,
4186 see section Parameters and local variables for more details.
4188 \labelwidthstring 00.00.0000
4194 This option can be used when the code generated is called by a monitor
4196 The compiler will generate a 'ret' upon return from the 'main' function.
4197 The default option is to lock up i.e.
4200 \labelwidthstring 00.00.0000
4206 Disable peep-hole optimization.
4208 \labelwidthstring 00.00.0000
4214 Pass the inline assembler code through the peep hole optimizer.
4215 This can cause unexpected changes to inline assembler code, please go through
4216 the peephole optimizer rules defined in the source file tree '<target>/peeph.def
4217 ' before using this option.
4219 \labelwidthstring 00.00.0000
4225 <Value> Causes the linker to check if the internal ram usage is within limits
4228 \labelwidthstring 00.00.0000
4234 <Value> Causes the linker to check if the external ram usage is within limits
4237 \labelwidthstring 00.00.0000
4243 <Value> Causes the linker to check if the code usage is within limits of
4246 \labelwidthstring 00.00.0000
4252 This will prevent the compiler from passing on the default include path
4253 to the preprocessor.
4255 \labelwidthstring 00.00.0000
4261 This will prevent the compiler from passing on the default library path
4264 \labelwidthstring 00.00.0000
4270 Shows the various actions the compiler is performing.
4272 \labelwidthstring 00.00.0000
4278 Shows the actual commands the compiler is executing.
4280 \labelwidthstring 00.00.0000
4286 Hides your ugly and inefficient c-code from the asm file, so you can always
4287 blame the compiler :).
4289 \labelwidthstring 00.00.0000
4295 Include i-codes in the asm file.
4296 Sounds like noise but is most helpfull for debugging the compiler itself.
4298 \labelwidthstring 00.00.0000
4304 Disable some of the more pedantic warnings (jwk burps: please be more specific
4307 \labelwidthstring 00.00.0000
4311 ---print-search-dirs
4313 Display the directories in the compiler's search path
4314 \layout Subsubsection
4316 Intermediate Dump Options
4319 The following options are provided for the purpose of retargetting and debugging
4321 These provided a means to dump the intermediate code (iCode) generated
4322 by the compiler in human readable form at various stages of the compilation
4326 \labelwidthstring 00.00.0000
4332 This option will cause the compiler to dump the intermediate code into
4335 <source filename>.dumpraw
4337 just after the intermediate code has been generated for a function, i.e.
4338 before any optimizations are done.
4339 The basic blocks at this stage ordered in the depth first number, so they
4340 may not be in sequence of execution.
4342 \labelwidthstring 00.00.0000
4348 Will create a dump of iCode's, after global subexpression elimination,
4351 <source filename>.dumpgcse.
4353 \labelwidthstring 00.00.0000
4359 Will create a dump of iCode's, after deadcode elimination, into a file
4362 <source filename>.dumpdeadcode.
4364 \labelwidthstring 00.00.0000
4373 Will create a dump of iCode's, after loop optimizations, into a file named
4376 <source filename>.dumploop.
4378 \labelwidthstring 00.00.0000
4387 Will create a dump of iCode's, after live range analysis, into a file named
4390 <source filename>.dumprange.
4392 \labelwidthstring 00.00.0000
4398 Will dump the life ranges for all symbols.
4400 \labelwidthstring 00.00.0000
4409 Will create a dump of iCode's, after register assignment, into a file named
4412 <source filename>.dumprassgn.
4414 \labelwidthstring 00.00.0000
4420 Will create a dump of the live ranges of iTemp's
4422 \labelwidthstring 00.00.0000
4433 Will cause all the above mentioned dumps to be created.
4436 Environment variables
4439 SDCC recognizes the following environment variables:
4441 \labelwidthstring 00.00.0000
4447 SDCC installs a signal handler to be able to delete temporary files after
4448 an user break (^C) or an exception.
4449 If this environment variable is set, SDCC won't install the signal handler
4450 in order to be able to debug SDCC.
4452 \labelwidthstring 00.00.0000
4460 Path, where temporary files will be created.
4461 The order of the variables is the search order.
4462 In a standard *nix environment these variables are not set, and there's
4463 no need to set them.
4464 On Windows it's recommended to set one of them.
4466 \labelwidthstring 00.00.0000
4473 \begin_inset Quotes sld
4476 2.3 Install and search paths
4477 \begin_inset Quotes srd
4482 \labelwidthstring 00.00.0000
4489 \begin_inset Quotes sld
4492 2.3 Install and search paths
4493 \begin_inset Quotes srd
4498 \labelwidthstring 00.00.0000
4505 \begin_inset Quotes sld
4508 2.3 Install and search paths
4509 \begin_inset Quotes srd
4515 There are some more environment variables recognized by SDCC, but these
4516 are solely used for debugging purposes.
4517 They can change or disappear very quickly, and will never be documentated.
4520 MCS51/DS390 Storage Class Language Extensions
4523 In addition to the ANSI storage classes SDCC allows the following MCS51
4524 specific storage classes.
4525 \layout Subsubsection
4530 Variables declared with this storage class will be placed in the extern
4536 storage class for Large Memory model, e.g.:
4542 xdata unsigned char xduc;
4543 \layout Subsubsection
4552 storage class for Small Memory model.
4553 Variables declared with this storage class will be allocated in the internal
4561 \layout Subsubsection
4566 Variables declared with this storage class will be allocated into the indirectly
4567 addressable portion of the internal ram of a 8051, e.g.:
4574 \layout Subsubsection
4579 This is a data-type and a storage class specifier.
4580 When a variable is declared as a bit, it is allocated into the bit addressable
4581 memory of 8051, e.g.:
4588 \layout Subsubsection
4593 Like the bit keyword,
4597 signifies both a data-type and storage class, they are used to describe
4598 the special function registers and special bit variables of a 8051, eg:
4604 sfr at 0x80 P0; /* special function register P0 at location 0x80 */
4606 sbit at 0xd7 CY; /* CY (Carry Flag) */
4612 SDCC allows (via language extensions) pointers to explicitly point to any
4613 of the memory spaces of the 8051.
4614 In addition to the explicit pointers, the compiler uses (by default) generic
4615 pointers which can be used to point to any of the memory spaces.
4619 Pointer declaration examples:
4628 /* pointer physically in xternal ram pointing to object in internal ram
4631 data unsigned char * xdata p;
4635 /* pointer physically in code rom pointing to data in xdata space */
4637 xdata unsigned char * code p;
4641 /* pointer physically in code space pointing to data in code space */
4643 code unsigned char * code p;
4647 /* the folowing is a generic pointer physically located in xdata space */
4658 Well you get the idea.
4663 All unqualified pointers are treated as 3-byte (4-byte for the ds390)
4676 The highest order byte of the
4680 pointers contains the data space information.
4681 Assembler support routines are called whenever data is stored or retrieved
4687 These are useful for developing reusable library routines.
4688 Explicitly specifying the pointer type will generate the most efficient
4692 Parameters & Local Variables
4695 Automatic (local) variables and parameters to functions can either be placed
4696 on the stack or in data-space.
4697 The default action of the compiler is to place these variables in the internal
4698 RAM (for small model) or external RAM (for large model).
4699 This in fact makes them
4703 so by default functions are non-reentrant.
4707 They can be placed on the stack either by using the
4711 option or by using the
4715 keyword in the function declaration, e.g.:
4724 unsigned char foo(char i) reentrant
4737 Since stack space on 8051 is limited, the
4745 option should be used sparingly.
4746 Note that the reentrant keyword just means that the parameters & local
4747 variables will be allocated to the stack, it
4751 mean that the function is register bank independent.
4755 Local variables can be assigned storage classes and absolute addresses,
4762 unsigned char foo() {
4768 xdata unsigned char i;
4780 data at 0x31 unsiged char j;
4795 In the above example the variable
4799 will be allocated in the external ram,
4803 in bit addressable space and
4812 or when a function is declared as
4816 this should only be done for static variables.
4819 Parameters however are not allowed any storage class, (storage classes for
4820 parameters will be ignored), their allocation is governed by the memory
4821 model in use, and the reentrancy options.
4827 For non-reentrant functions SDCC will try to reduce internal ram space usage
4828 by overlaying parameters and local variables of a function (if possible).
4829 Parameters and local variables of a function will be allocated to an overlayabl
4830 e segment if the function has
4832 no other function calls and the function is non-reentrant and the memory
4836 If an explicit storage class is specified for a local variable, it will
4840 Note that the compiler (not the linkage editor) makes the decision for overlayin
4842 Functions that are called from an interrupt service routine should be preceded
4843 by a #pragma\SpecialChar ~
4844 NOOVERLAY if they are not reentrant.
4847 Also note that the compiler does not do any processing of inline assembler
4848 code, so the compiler might incorrectly assign local variables and parameters
4849 of a function into the overlay segment if the inline assembler code calls
4850 other c-functions that might use the overlay.
4851 In that case the #pragma\SpecialChar ~
4852 NOOVERLAY should be used.
4855 Parameters and Local variables of functions that contain 16 or 32 bit multiplica
4856 tion or division will NOT be overlayed since these are implemented using
4857 external functions, e.g.:
4867 void set_error(unsigned char errcd)
4883 void some_isr () interrupt 2 using 1
4912 In the above example the parameter
4920 would be assigned to the overlayable segment if the #pragma\SpecialChar ~
4922 not present, this could cause unpredictable runtime behavior when called
4924 The #pragma\SpecialChar ~
4925 NOOVERLAY ensures that the parameters and local variables for
4926 the function are NOT overlayed.
4929 Interrupt Service Routines
4932 SDCC allows interrupt service routines to be coded in C, with some extended
4939 void timer_isr (void) interrupt 2 using 1
4952 The number following the
4956 keyword is the interrupt number this routine will service.
4957 The compiler will insert a call to this routine in the interrupt vector
4958 table for the interrupt number specified.
4963 keyword is used to tell the compiler to use the specified register bank
4964 (8051 specific) when generating code for this function.
4965 Note that when some function is called from an interrupt service routine
4966 it should be preceded by a #pragma\SpecialChar ~
4967 NOOVERLAY if it is not reentrant.
4968 A special note here, int (16 bit) and long (32 bit) integer division, multiplic
4969 ation & modulus operations are implemented using external support routines
4970 developed in ANSI-C, if an interrupt service routine needs to do any of
4971 these operations then the support routines (as mentioned in a following
4972 section) will have to be recompiled using the
4976 option and the source file will need to be compiled using the
4983 If you have multiple source files in your project, interrupt service routines
4984 can be present in any of them, but a prototype of the isr MUST be present
4985 or included in the file that contains the function
4992 Interrupt Numbers and the corresponding address & descriptions for the Standard
4993 8051 are listed below.
4994 SDCC will automatically adjust the interrupt vector table to the maximum
4995 interrupt number specified.
5001 \begin_inset Tabular
5002 <lyxtabular version="3" rows="6" columns="3">
5004 <column alignment="center" valignment="top" leftline="true" width="0in">
5005 <column alignment="center" valignment="top" leftline="true" width="0in">
5006 <column alignment="center" valignment="top" leftline="true" rightline="true" width="0in">
5007 <row topline="true" bottomline="true">
5008 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
5016 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
5024 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
5033 <row topline="true">
5034 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
5042 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
5050 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
5059 <row topline="true">
5060 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
5068 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
5076 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
5085 <row topline="true">
5086 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
5094 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
5102 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
5111 <row topline="true">
5112 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
5120 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
5128 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
5137 <row topline="true" bottomline="true">
5138 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
5146 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
5154 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
5171 If the interrupt service routine is defined without
5175 a register bank or with register bank 0 (using 0), the compiler will save
5176 the registers used by itself on the stack upon entry and restore them at
5177 exit, however if such an interrupt service routine calls another function
5178 then the entire register bank will be saved on the stack.
5179 This scheme may be advantageous for small interrupt service routines which
5180 have low register usage.
5183 If the interrupt service routine is defined to be using a specific register
5188 are save and restored, if such an interrupt service routine calls another
5189 function (using another register bank) then the entire register bank of
5190 the called function will be saved on the stack.
5191 This scheme is recommended for larger interrupt service routines.
5194 Calling other functions from an interrupt service routine is not recommended,
5195 avoid it if possible.
5199 Also see the _naked modifier.
5207 <TODO: this isn't implemented at all!>
5213 A special keyword may be associated with a function declaring it as
5218 SDCC will generate code to disable all interrupts upon entry to a critical
5219 function and enable them back before returning.
5220 Note that nesting critical functions may cause unpredictable results.
5245 The critical attribute maybe used with other attributes like
5253 A special keyword may be associated with a function declaring it as
5262 function modifier attribute prevents the compiler from generating prologue
5263 and epilogue code for that function.
5264 This means that the user is entirely responsible for such things as saving
5265 any registers that may need to be preserved, selecting the proper register
5266 bank, generating the
5270 instruction at the end, etc.
5271 Practically, this means that the contents of the function must be written
5272 in inline assembler.
5273 This is particularly useful for interrupt functions, which can have a large
5274 (and often unnecessary) prologue/epilogue.
5275 For example, compare the code generated by these two functions:
5281 data unsigned char counter;
5283 void simpleInterrupt(void) interrupt 1
5297 void nakedInterrupt(void) interrupt 2 _naked
5330 ; MUST explicitly include ret in _naked function.
5344 For an 8051 target, the generated simpleInterrupt looks like:
5489 whereas nakedInterrupt looks like:
5514 ; MUST explicitly include ret(i) in _naked function.
5520 While there is nothing preventing you from writing C code inside a _naked
5521 function, there are many ways to shoot yourself in the foot doing this,
5522 and it is recommended that you stick to inline assembler.
5525 Functions using private banks
5532 attribute (which tells the compiler to use a register bank other than the
5533 default bank zero) should only be applied to
5537 functions (see note 1 below).
5538 This will in most circumstances make the generated ISR code more efficient
5539 since it will not have to save registers on the stack.
5546 attribute will have no effect on the generated code for a
5550 function (but may occasionally be useful anyway
5556 possible exception: if a function is called ONLY from 'interrupt' functions
5557 using a particular bank, it can be declared with the same 'using' attribute
5558 as the calling 'interrupt' functions.
5559 For instance, if you have several ISRs using bank one, and all of them
5560 call memcpy(), it might make sense to create a specialized version of memcpy()
5561 'using 1', since this would prevent the ISR from having to save bank zero
5562 to the stack on entry and switch to bank zero before calling the function
5569 (pending: I don't think this has been done yet)
5576 function using a non-zero bank will assume that it can trash that register
5577 bank, and will not save it.
5578 Since high-priority interrupts can interrupt low-priority ones on the 8051
5579 and friends, this means that if a high-priority ISR
5583 a particular bank occurs while processing a low-priority ISR
5587 the same bank, terrible and bad things can happen.
5588 To prevent this, no single register bank should be
5592 by both a high priority and a low priority ISR.
5593 This is probably most easily done by having all high priority ISRs use
5594 one bank and all low priority ISRs use another.
5595 If you have an ISR which can change priority at runtime, you're on your
5596 own: I suggest using the default bank zero and taking the small performance
5600 It is most efficient if your ISR calls no other functions.
5601 If your ISR must call other functions, it is most efficient if those functions
5602 use the same bank as the ISR (see note 1 below); the next best is if the
5603 called functions use bank zero.
5604 It is very inefficient to call a function using a different, non-zero bank
5612 Data items can be assigned an absolute address with the
5616 keyword, in addition to a storage class, e.g.:
5622 xdata at 0x8000 unsigned char PORTA_8255 ;
5628 In the above example the PORTA_8255 will be allocated to the location 0x8000
5629 of the external ram.
5630 Note that this feature is provided to give the programmer access to
5634 devices attached to the controller.
5635 The compiler does not actually reserve any space for variables declared
5636 in this way (they are implemented with an equate in the assembler).
5637 Thus it is left to the programmer to make sure there are no overlaps with
5638 other variables that are declared without the absolute address.
5639 The assembler listing file (.lst) and the linker output files (.rst) and
5640 (.map) are a good places to look for such overlaps.
5644 Absolute address can be specified for variables in all storage classes,
5657 The above example will allocate the variable at offset 0x02 in the bit-addressab
5659 There is no real advantage to assigning absolute addresses to variables
5660 in this manner, unless you want strict control over all the variables allocated.
5666 The compiler inserts a call to the C routine
5668 _sdcc_external_startup()
5673 at the start of the CODE area.
5674 This routine is in the runtime library.
5675 By default this routine returns 0, if this routine returns a non-zero value,
5676 the static & global variable initialization will be skipped and the function
5677 main will be invoked Other wise static & global variables will be initialized
5678 before the function main is invoked.
5681 _sdcc_external_startup()
5683 routine to your program to override the default if you need to setup hardware
5684 or perform some other critical operation prior to static & global variable
5688 Inline Assembler Code
5691 SDCC allows the use of in-line assembler with a few restriction as regards
5693 All labels defined within inline assembler code
5701 where nnnn is a number less than 100 (which implies a limit of utmost 100
5702 inline assembler labels
5710 It is strongly recommended that each assembly instruction (including labels)
5711 be placed in a separate line (as the example shows).
5716 command line option is used, the inline assembler code will be passed through
5717 the peephole optimizer.
5718 This might cause some unexpected changes in the inline assembler code.
5719 Please go throught the peephole optimizer rules defined in file
5723 carefully before using this option.
5763 The inline assembler code can contain any valid code understood by the assembler
5764 , this includes any assembler directives and comment lines.
5765 The compiler does not do any validation of the code within the
5775 Inline assembler code cannot reference any C-Labels, however it can reference
5776 labels defined by the inline assembler, e.g.:
5802 ; some assembler code
5822 /* some more c code */
5824 clabel:\SpecialChar ~
5826 /* inline assembler cannot reference this label */
5838 $0003: ;label (can be reference by inline assembler only)
5850 /* some more c code */
5858 In other words inline assembly code can access labels defined in inline
5859 assembly within the scope of the funtion.
5863 The same goes the other way, ie.
5864 labels defines in inline assembly CANNOT be accessed by C statements.
5867 int (16 bit) and long (32 bit) Support
5870 For signed & unsigned int (16 bit) and long (32 bit) variables, division,
5871 multiplication and modulus operations are implemented by support routines.
5872 These support routines are all developed in ANSI-C to facilitate porting
5873 to other MCUs, although some model specific assembler optimations are used.
5874 The following files contain the described routine, all of them can be found
5875 in <installdir>/share/sdcc/lib.
5881 <pending: tabularise this>
5887 _mulsint.c - signed 16 bit multiplication (calls _muluint)
5889 _muluint.c - unsigned 16 bit multiplication
5891 _divsint.c - signed 16 bit division (calls _divuint)
5893 _divuint.c - unsigned 16 bit division
5895 _modsint.c - signed 16 bit modulus (call _moduint)
5897 _moduint.c - unsigned 16 bit modulus
5899 _mulslong.c - signed 32 bit multiplication (calls _mululong)
5901 _mululong.c - unsigned32 bit multiplication
5903 _divslong.c - signed 32 division (calls _divulong)
5905 _divulong.c - unsigned 32 division
5907 _modslong.c - signed 32 bit modulus (calls _modulong)
5909 _modulong.c - unsigned 32 bit modulus
5917 Since they are compiled as
5921 , interrupt service routines should not do any of the above operations.
5922 If this is unavoidable then the above routines will need to be compiled
5927 option, after which the source program will have to be compiled with
5934 Floating Point Support
5937 SDCC supports IEEE (single precision 4bytes) floating point numbers.The floating
5938 point support routines are derived from gcc's floatlib.c and consists of
5939 the following routines:
5945 <pending: tabularise this>
5951 _fsadd.c - add floating point numbers
5953 _fssub.c - subtract floating point numbers
5955 _fsdiv.c - divide floating point numbers
5957 _fsmul.c - multiply floating point numbers
5959 _fs2uchar.c - convert floating point to unsigned char
5961 _fs2char.c - convert floating point to signed char
5963 _fs2uint.c - convert floating point to unsigned int
5965 _fs2int.c - convert floating point to signed int
5967 _fs2ulong.c - convert floating point to unsigned long
5969 _fs2long.c - convert floating point to signed long
5971 _uchar2fs.c - convert unsigned char to floating point
5973 _char2fs.c - convert char to floating point number
5975 _uint2fs.c - convert unsigned int to floating point
5977 _int2fs.c - convert int to floating point numbers
5979 _ulong2fs.c - convert unsigned long to floating point number
5981 _long2fs.c - convert long to floating point number
5989 Note if all these routines are used simultaneously the data space might
5991 For serious floating point usage it is strongly recommended that the large
5998 SDCC allows two memory models for MCS51 code, small and large.
5999 Modules compiled with different memory models should
6003 be combined together or the results would be unpredictable.
6004 The library routines supplied with the compiler are compiled as both small
6006 The compiled library modules are contained in seperate directories as small
6007 and large so that you can link to either set.
6011 When the large model is used all variables declared without a storage class
6012 will be allocated into the external ram, this includes all parameters and
6013 local variables (for non-reentrant functions).
6014 When the small model is used variables without storage class are allocated
6015 in the internal ram.
6018 Judicious usage of the processor specific storage classes and the 'reentrant'
6019 function type will yield much more efficient code, than using the large
6021 Several optimizations are disabled when the program is compiled using the
6022 large model, it is therefore strongly recommdended that the small model
6023 be used unless absolutely required.
6029 The only model supported is Flat 24.
6030 This generates code for the 24 bit contiguous addressing mode of the Dallas
6032 In this mode, up to four meg of external RAM or code space can be directly
6034 See the data sheets at www.dalsemi.com for further information on this part.
6038 In older versions of the compiler, this option was used with the MCS51 code
6044 Now, however, the '390 has it's own code generator, selected by the
6053 Note that the compiler does not generate any code to place the processor
6054 into 24 bitmode (although
6058 in the ds390 libraries will do that for you).
6063 , the boot loader or similar code must ensure that the processor is in 24
6064 bit contiguous addressing mode before calling the SDCC startup code.
6072 option, variables will by default be placed into the XDATA segment.
6077 Segments may be placed anywhere in the 4 meg address space using the usual
6079 Note that if any segments are located above 64K, the -r flag must be passed
6080 to the linker to generate the proper segment relocations, and the Intel
6081 HEX output format must be used.
6082 The -r flag can be passed to the linker by using the option
6086 on the sdcc command line.
6087 However, currently the linker can not handle code segments > 64k.
6090 Defines Created by the Compiler
6093 The compiler creates the following #defines.
6096 SDCC - this Symbol is always defined.
6099 SDCC_mcs51 or SDCC_ds390 or SDCC_z80, etc - depending on the model used
6103 __mcs51 or __ds390 or __z80, etc - depending on the model used (e.g.
6107 SDCC_STACK_AUTO - this symbol is defined when
6114 SDCC_MODEL_SMALL - when
6121 SDCC_MODEL_LARGE - when
6128 SDCC_USE_XSTACK - when
6135 SDCC_STACK_TENBIT - when
6142 SDCC_MODEL_FLAT24 - when
6155 SDCC performs a host of standard optimizations in addition to some MCU specific
6158 \layout Subsubsection
6160 Sub-expression Elimination
6163 The compiler does local and global common subexpression elimination, e.g.:
6178 will be translated to
6194 Some subexpressions are not as obvious as the above example, e.g.:
6208 In this case the address arithmetic a->b[i] will be computed only once;
6209 the equivalent code in C would be.
6225 The compiler will try to keep these temporary variables in registers.
6226 \layout Subsubsection
6228 Dead-Code Elimination
6243 i = 1; \SpecialChar ~
6248 global = 1;\SpecialChar ~
6261 global = 3;\SpecialChar ~
6276 int global; void f ()
6289 \layout Subsubsection
6350 Note: the dead stores created by this copy propagation will be eliminated
6351 by dead-code elimination.
6352 \layout Subsubsection
6357 Two types of loop optimizations are done by SDCC loop invariant lifting
6358 and strength reduction of loop induction variables.
6359 In addition to the strength reduction the optimizer marks the induction
6360 variables and the register allocator tries to keep the induction variables
6361 in registers for the duration of the loop.
6362 Because of this preference of the register allocator, loop induction optimizati
6363 on causes an increase in register pressure, which may cause unwanted spilling
6364 of other temporary variables into the stack / data space.
6365 The compiler will generate a warning message when it is forced to allocate
6366 extra space either on the stack or data space.
6367 If this extra space allocation is undesirable then induction optimization
6368 can be eliminated either for the entire source file (with ---noinduction
6369 option) or for a given function only using #pragma\SpecialChar ~
6380 for (i = 0 ; i < 100 ; i ++)
6398 for (i = 0; i < 100; i++)
6408 As mentioned previously some loop invariants are not as apparent, all static
6409 address computations are also moved out of the loop.
6413 Strength Reduction, this optimization substitutes an expression by a cheaper
6420 for (i=0;i < 100; i++)
6440 for (i=0;i< 100;i++) {
6444 ar[itemp1] = itemp2;
6460 The more expensive multiplication is changed to a less expensive addition.
6461 \layout Subsubsection
6466 This optimization is done to reduce the overhead of checking loop boundaries
6467 for every iteration.
6468 Some simple loops can be reversed and implemented using a
6469 \begin_inset Quotes eld
6472 decrement and jump if not zero
6473 \begin_inset Quotes erd
6477 SDCC checks for the following criterion to determine if a loop is reversible
6478 (note: more sophisticated compilers use data-dependency analysis to make
6479 this determination, SDCC uses a more simple minded analysis).
6482 The 'for' loop is of the form
6488 for (<symbol> = <expression> ; <sym> [< | <=] <expression> ; [<sym>++ |
6498 The <for body> does not contain
6499 \begin_inset Quotes eld
6503 \begin_inset Quotes erd
6507 \begin_inset Quotes erd
6513 All goto's are contained within the loop.
6516 No function calls within the loop.
6519 The loop control variable <sym> is not assigned any value within the loop
6522 The loop control variable does NOT participate in any arithmetic operation
6526 There are NO switch statements in the loop.
6527 \layout Subsubsection
6529 Algebraic Simplifications
6532 SDCC does numerous algebraic simplifications, the following is a small sub-set
6533 of these optimizations.
6539 i = j + 0 ; /* changed to */ i = j;
6541 i /= 2; /* changed to */ i >>= 1;
6543 i = j - j ; /* changed to */ i = 0;
6545 i = j / 1 ; /* changed to */ i = j;
6551 Note the subexpressions given above are generally introduced by macro expansions
6552 or as a result of copy/constant propagation.
6553 \layout Subsubsection
6558 SDCC changes switch statements to jump tables when the following conditions
6563 The case labels are in numerical sequence, the labels need not be in order,
6564 and the starting number need not be one or zero.
6570 switch(i) {\SpecialChar ~
6677 Both the above switch statements will be implemented using a jump-table.
6680 The number of case labels is at least three, since it takes two conditional
6681 statements to handle the boundary conditions.
6684 The number of case labels is less than 84, since each label takes 3 bytes
6685 and a jump-table can be utmost 256 bytes long.
6689 Switch statements which have gaps in the numeric sequence or those that
6690 have more that 84 case labels can be split into more than one switch statement
6691 for efficient code generation, e.g.:
6729 If the above switch statement is broken down into two switch statements
6763 case 9: \SpecialChar ~
6773 case 12:\SpecialChar ~
6783 then both the switch statements will be implemented using jump-tables whereas
6784 the unmodified switch statement will not be.
6785 \layout Subsubsection
6787 Bit-shifting Operations.
6790 Bit shifting is one of the most frequently used operation in embedded programmin
6792 SDCC tries to implement bit-shift operations in the most efficient way
6812 generates the following code:
6830 In general SDCC will never setup a loop if the shift count is known.
6870 Note that SDCC stores numbers in little-endian format (i.e.
6871 lowest order first).
6872 \layout Subsubsection
6877 A special case of the bit-shift operation is bit rotation, SDCC recognizes
6878 the following expression to be a left bit-rotation:
6889 i = ((i << 1) | (i >> 7));
6897 will generate the following code:
6913 SDCC uses pattern matching on the parse tree to determine this operation.Variatio
6914 ns of this case will also be recognized as bit-rotation, i.e.:
6920 i = ((i >> 7) | (i << 1)); /* left-bit rotation */
6921 \layout Subsubsection
6926 It is frequently required to obtain the highest order bit of an integral
6927 type (long, int, short or char types).
6928 SDCC recognizes the following expression to yield the highest order bit
6929 and generates optimized code for it, e.g.:
6950 hob = (gint >> 15) & 1;
6963 will generate the following code:
7002 000A E5*01\SpecialChar ~
7030 000C 33\SpecialChar ~
7061 000D E4\SpecialChar ~
7092 000E 13\SpecialChar ~
7123 000F F5*02\SpecialChar ~
7153 Variations of this case however will
7158 It is a standard C expression, so I heartily recommend this be the only
7159 way to get the highest order bit, (it is portable).
7160 Of course it will be recognized even if it is embedded in other expressions,
7167 xyz = gint + ((gint >> 15) & 1);
7173 will still be recognized.
7174 \layout Subsubsection
7179 The compiler uses a rule based, pattern matching and re-writing mechanism
7180 for peep-hole optimization.
7185 a peep-hole optimizer by Christopher W.
7186 Fraser (cwfraser@microsoft.com).
7187 A default set of rules are compiled into the compiler, additional rules
7188 may be added with the
7190 ---peep-file <filename>
7193 The rule language is best illustrated with examples.
7221 The above rule will change the following assembly sequence:
7251 Note: All occurrences of a
7255 (pattern variable) must denote the same string.
7256 With the above rule, the assembly sequence:
7274 will remain unmodified.
7278 Other special case optimizations may be added by the user (via
7284 some variants of the 8051 MCU allow only
7293 The following two rules will change all
7315 replace { lcall %1 } by { acall %1 }
7317 replace { ljmp %1 } by { ajmp %1 }
7325 inline-assembler code
7327 is also passed through the peep hole optimizer, thus the peephole optimizer
7328 can also be used as an assembly level macro expander.
7329 The rules themselves are MCU dependent whereas the rule language infra-structur
7330 e is MCU independent.
7331 Peephole optimization rules for other MCU can be easily programmed using
7336 The syntax for a rule is as follows:
7342 rule := replace [ restart ] '{' <assembly sequence> '
7380 <assembly sequence> '
7398 '}' [if <functionName> ] '
7406 <assembly sequence> := assembly instruction (each instruction including
7407 labels must be on a separate line).
7411 The optimizer will apply to the rules one by one from the top in the sequence
7412 of their appearance, it will terminate when all rules are exhausted.
7413 If the 'restart' option is specified, then the optimizer will start matching
7414 the rules again from the top, this option for a rule is expensive (performance)
7415 , it is intended to be used in situations where a transformation will trigger
7416 the same rule again.
7417 An example of this (not a good one, it has side effects) is the following
7444 Note that the replace pattern cannot be a blank, but can be a comment line.
7445 Without the 'restart' option only the inner most 'pop' 'push' pair would
7446 be eliminated, i.e.:
7498 the restart option the rule will be applied again to the resulting code
7499 and then all the pop-push pairs will be eliminated to yield:
7517 A conditional function can be attached to a rule.
7518 Attaching rules are somewhat more involved, let me illustrate this with
7549 The optimizer does a look-up of a function name table defined in function
7554 in the source file SDCCpeeph.c, with the name
7559 If it finds a corresponding entry the function is called.
7560 Note there can be no parameters specified for these functions, in this
7565 is crucial, since the function
7569 expects to find the label in that particular variable (the hash table containin
7570 g the variable bindings is passed as a parameter).
7571 If you want to code more such functions, take a close look at the function
7572 labelInRange and the calling mechanism in source file SDCCpeeph.c.
7573 I know this whole thing is a little kludgey, but maybe some day we will
7574 have some better means.
7575 If you are looking at this file, you will also see the default rules that
7576 are compiled into the compiler, you can add your own rules in the default
7577 set there if you get tired of specifying the ---peep-file option.
7583 SDCC supports the following #pragma directives.
7586 SAVE - this will save all current options to the SAVE/RESTORE stack.
7590 RESTORE - will restore saved options from the last save.
7591 SAVEs & RESTOREs can be nested.
7592 SDCC uses a SAVE/RESTORE stack: SAVE pushes current options to the stack,
7593 RESTORE pulls current options from the stack.
7597 NOGCSE - will stop global subexpression elimination.
7600 NOINDUCTION - will stop loop induction optimizations.
7603 NOJTBOUND - will not generate code for boundary value checking, when switch
7604 statements are turned into jump-tables.
7607 NOOVERLAY - the compiler will not overlay the parameters and local variables
7611 LESS_PEDANTIC - the compiler will not warn you anymore for obvious mistakes,
7612 you'r on your own now ;-(
7615 NOLOOPREVERSE - Will not do loop reversal optimization
7618 EXCLUDE NONE | {acc[,b[,dpl[,dph]]] - The exclude pragma disables generation
7619 of pair of push/pop instruction in ISR function (using interrupt keyword).
7620 The directive should be placed immediately before the ISR function definition
7621 and it affects ALL ISR functions following it.
7622 To enable the normal register saving for ISR functions use #pragma\SpecialChar ~
7623 EXCLUDE\SpecialChar ~
7627 NOIV - Do not generate interrupt vector table entries for all ISR functions
7628 defined after the pragma.
7629 This is useful in cases where the interrupt vector table must be defined
7630 manually, or when there is a secondary, manually defined interrupt vector
7632 for the autovector feature of the Cypress EZ-USB FX2).
7635 CALLEE-SAVES function1[,function2[,function3...]] - The compiler by default
7636 uses a caller saves convention for register saving across function calls,
7637 however this can cause unneccessary register pushing & popping when calling
7638 small functions from larger functions.
7639 This option can be used to switch off the register saving convention for
7640 the function names specified.
7641 The compiler will not save registers when calling these functions, extra
7642 code need to be manually inserted at the entry & exit for these functions
7643 to save & restore the registers used by these functions, this can SUBSTANTIALLY
7644 reduce code & improve run time performance of the generated code.
7645 In the future the compiler (with interprocedural analysis) may be able
7646 to determine the appropriate scheme to use for each function call.
7647 If ---callee-saves command line option is used, the function names specified
7648 in #pragma\SpecialChar ~
7649 CALLEE-SAVES is appended to the list of functions specified in
7653 The pragma's are intended to be used to turn-off certain optimizations which
7654 might cause the compiler to generate extra stack / data space to store
7655 compiler generated temporary variables.
7656 This usually happens in large functions.
7657 Pragma directives should be used as shown in the following example, they
7658 are used to control options & optimizations for a given function; pragmas
7659 should be placed before and/or after a function, placing pragma's inside
7660 a function body could have unpredictable results.
7666 #pragma SAVE /* save the current settings */
7668 #pragma NOGCSE /* turnoff global subexpression elimination */
7670 #pragma NOINDUCTION /* turn off induction optimizations */
7692 #pragma RESTORE /* turn the optimizations back on */
7698 The compiler will generate a warning message when extra space is allocated.
7699 It is strongly recommended that the SAVE and RESTORE pragma's be used when
7700 changing options for a function.
7705 <pending: this is messy and incomplete>
7710 Compiler support routines (_gptrget, _mulint etc)
7713 Stdclib functions (puts, printf, strcat etc)
7716 Math functions (sin, pow, sqrt etc)
7719 Interfacing with Assembly Routines
7720 \layout Subsubsection
7722 Global Registers used for Parameter Passing
7725 The compiler always uses the global registers
7733 to pass the first parameter to a routine.
7734 The second parameter onwards is either allocated on the stack (for reentrant
7735 routines or if ---stack-auto is used) or in the internal / external ram
7736 (depending on the memory model).
7738 \layout Subsubsection
7740 Assembler Routine(non-reentrant)
7743 In the following example the function cfunc calls an assembler routine asm_func,
7744 which takes two parameters.
7750 extern int asm_func(unsigned char, unsigned char);
7754 int c_func (unsigned char i, unsigned char j)
7762 return asm_func(i,j);
7776 return c_func(10,9);
7784 The corresponding assembler function is:
7790 .globl _asm_func_PARM_2
7854 add a,_asm_func_PARM_2
7890 Note here that the return values are placed in 'dpl' - One byte return value,
7891 'dpl' LSB & 'dph' MSB for two byte values.
7892 'dpl', 'dph' and 'b' for three byte values (generic pointers) and 'dpl','dph','
7893 b' & 'acc' for four byte values.
7896 The parameter naming convention is _<function_name>_PARM_<n>, where n is
7897 the parameter number starting from 1, and counting from the left.
7898 The first parameter is passed in
7899 \begin_inset Quotes eld
7903 \begin_inset Quotes erd
7906 for One bye parameter,
7907 \begin_inset Quotes eld
7911 \begin_inset Quotes erd
7915 \begin_inset Quotes eld
7919 \begin_inset Quotes erd
7923 \begin_inset Quotes eld
7927 \begin_inset Quotes erd
7930 for four bytes, the varible name for the second parameter will be _<function_na
7935 Assemble the assembler routine with the following command:
7942 asx8051 -losg asmfunc.asm
7949 Then compile and link the assembler routine to the C source file with the
7957 sdcc cfunc.c asmfunc.rel
7958 \layout Subsubsection
7960 Assembler Routine(reentrant)
7963 In this case the second parameter onwards will be passed on the stack, the
7964 parameters are pushed from right to left i.e.
7965 after the call the left most parameter will be on the top of the stack.
7972 extern int asm_func(unsigned char, unsigned char);
7976 int c_func (unsigned char i, unsigned char j) reentrant
7984 return asm_func(i,j);
7998 return c_func(10,9);
8006 The corresponding assembler routine is:
8116 The compiling and linking procedure remains the same, however note the extra
8117 entry & exit linkage required for the assembler code, _bp is the stack
8118 frame pointer and is used to compute the offset into the stack for parameters
8119 and local variables.
8125 The external stack is located at the start of the external ram segment,
8126 and is 256 bytes in size.
8127 When ---xstack option is used to compile the program, the parameters and
8128 local variables of all reentrant functions are allocated in this area.
8129 This option is provided for programs with large stack space requirements.
8130 When used with the ---stack-auto option, all parameters and local variables
8131 are allocated on the external stack (note support libraries will need to
8132 be recompiled with the same options).
8135 The compiler outputs the higher order address byte of the external ram segment
8136 into PORT P2, therefore when using the External Stack option, this port
8137 MAY NOT be used by the application program.
8143 Deviations from the compliancy.
8146 functions are not always reentrant.
8149 structures cannot be assigned values directly, cannot be passed as function
8150 parameters or assigned to each other and cannot be a return value from
8177 s1 = s2 ; /* is invalid in SDCC although allowed in ANSI */
8188 struct s foo1 (struct s parms) /* is invalid in SDCC although allowed in
8210 return rets;/* is invalid in SDCC although allowed in ANSI */
8215 'long long' (64 bit integers) not supported.
8218 'double' precision floating point not supported.
8221 No support for setjmp and longjmp (for now).
8224 Old K&R style function declarations are NOT allowed.
8230 foo(i,j) /* this old style of function declarations */
8232 int i,j; /* are valid in ANSI but not valid in SDCC */
8246 functions declared as pointers must be dereferenced during the call.
8257 /* has to be called like this */
8259 (*foo)(); /* ansi standard allows calls to be made like 'foo()' */
8262 Cyclomatic Complexity
8265 Cyclomatic complexity of a function is defined as the number of independent
8266 paths the program can take during execution of the function.
8267 This is an important number since it defines the number test cases you
8268 have to generate to validate the function.
8269 The accepted industry standard for complexity number is 10, if the cyclomatic
8270 complexity reported by SDCC exceeds 10 you should think about simplification
8271 of the function logic.
8272 Note that the complexity level is not related to the number of lines of
8274 Large functions can have low complexity, and small functions can have large
8280 SDCC uses the following formula to compute the complexity:
8285 complexity = (number of edges in control flow graph) - (number of nodes
8286 in control flow graph) + 2;
8290 Having said that the industry standard is 10, you should be aware that in
8291 some cases it be may unavoidable to have a complexity level of less than
8293 For example if you have switch statement with more than 10 case labels,
8294 each case label adds one to the complexity level.
8295 The complexity level is by no means an absolute measure of the algorithmic
8296 complexity of the function, it does however provide a good starting point
8297 for which functions you might look at for further optimization.
8303 Here are a few guidelines that will help the compiler generate more efficient
8304 code, some of the tips are specific to this compiler others are generally
8305 good programming practice.
8308 Use the smallest data type to represent your data-value.
8309 If it is known in advance that the value is going to be less than 256 then
8310 use an 'unsigned char' instead of a 'short' or 'int'.
8313 Use unsigned when it is known in advance that the value is not going to
8315 This helps especially if you are doing division or multiplication.
8318 NEVER jump into a LOOP.
8321 Declare the variables to be local whenever possible, especially loop control
8322 variables (induction).
8325 Since the compiler does not always do implicit integral promotion, the programme
8326 r should do an explicit cast when integral promotion is required.
8329 Reducing the size of division, multiplication & modulus operations can reduce
8330 code size substantially.
8331 Take the following code for example.
8337 foobar(unsigned int p1, unsigned char ch)
8341 unsigned char ch1 = p1 % ch ;
8352 For the modulus operation the variable ch will be promoted to unsigned int
8353 first then the modulus operation will be performed (this will lead to a
8354 call to support routine _moduint()), and the result will be casted to a
8356 If the code is changed to
8362 foobar(unsigned int p1, unsigned char ch)
8366 unsigned char ch1 = (unsigned char)p1 % ch ;
8377 It would substantially reduce the code generated (future versions of the
8378 compiler will be smart enough to detect such optimization oppurtunities).
8381 Notes on MCS51 memory layout
8384 The 8051 family of micro controller have a minimum of 128 bytes of internal
8385 memory which is structured as follows
8389 - Bytes 00-1F - 32 bytes to hold up to 4 banks of the registers R7 to R7
8392 - Bytes 20-2F - 16 bytes to hold 128 bit variables and
8394 - Bytes 30-7F - 60 bytes for general purpose use.
8398 Normally the SDCC compiler will only utilise the first bank of registers,
8399 but it is possible to specify that other banks of registers should be used
8400 in interrupt routines.
8401 By default, the compiler will place the stack after the last bank of used
8403 if the first 2 banks of registers are used, it will position the base of
8404 the internal stack at address 16 (0X10).
8405 This implies that as the stack grows, it will use up the remaining register
8406 banks, and the 16 bytes used by the 128 bit variables, and 60 bytes for
8407 general purpose use.
8410 By default, the compiler uses the 60 general purpose bytes to hold "near
8412 The compiler/optimiser may also declare some Local Variables in this area
8417 If any of the 128 bit variables are used, or near data is being used then
8418 care needs to be taken to ensure that the stack does not grow so much that
8419 it starts to over write either your bit variables or "near data".
8420 There is no runtime checking to prevent this from happening.
8423 The amount of stack being used is affected by the use of the "internal stack"
8424 to save registers before a subroutine call is made (---stack-auto will
8425 declare parameters and local variables on the stack) and the number of
8429 If you detect that the stack is over writing you data, then the following
8431 ---xstack will cause an external stack to be used for saving registers
8432 and (if ---stack-auto is being used) storing parameters and local variables.
8433 However this will produce more code which will be slower to execute.
8437 ---stack-loc will allow you specify the start of the stack, i.e.
8438 you could start it after any data in the general purpose area.
8439 However this may waste the memory not used by the register banks and if
8440 the size of the "near data" increases, it may creep into the bottom of
8444 ---stack-after-data, similar to the ---stack-loc, but it automatically places
8445 the stack after the end of the "near data".
8446 Again this could waste any spare register space.
8449 ---data-loc allows you to specify the start address of the near data.
8450 This could be used to move the "near data" further away from the stack
8451 giving it more room to grow.
8452 This will only work if no bit variables are being used and the stack can
8453 grow to use the bit variable space.
8461 If you find that the stack is over writing your bit variables or "near data"
8462 then the approach which best utilised the internal memory is to position
8463 the "near data" after the last bank of used registers or, if you use bit
8464 variables, after the last bit variable by using the ---data-loc, e.g.
8465 if two register banks are being used and no bit variables, ---data-loc
8466 16, and use the ---stack-after-data option.
8469 If bit variables are being used, another method would be to try and squeeze
8470 the data area in the unused register banks if it will fit, and start the
8471 stack after the last bit variable.
8474 Retargetting for other MCUs.
8477 The issues for retargetting the compiler are far too numerous to be covered
8479 What follows is a brief description of each of the seven phases of the
8480 compiler and its MCU dependency.
8483 Parsing the source and building the annotated parse tree.
8484 This phase is largely MCU independent (except for the language extensions).
8485 Syntax & semantic checks are also done in this phase, along with some initial
8486 optimizations like back patching labels and the pattern matching optimizations
8487 like bit-rotation etc.
8490 The second phase involves generating an intermediate code which can be easy
8491 manipulated during the later phases.
8492 This phase is entirely MCU independent.
8493 The intermediate code generation assumes the target machine has unlimited
8494 number of registers, and designates them with the name iTemp.
8495 The compiler can be made to dump a human readable form of the code generated
8496 by using the ---dumpraw option.
8499 This phase does the bulk of the standard optimizations and is also MCU independe
8501 This phase can be broken down into several sub-phases:
8505 Break down intermediate code (iCode) into basic blocks.
8507 Do control flow & data flow analysis on the basic blocks.
8509 Do local common subexpression elimination, then global subexpression elimination
8511 Dead code elimination
8515 If loop optimizations caused any changes then do 'global subexpression eliminati
8516 on' and 'dead code elimination' again.
8519 This phase determines the live-ranges; by live range I mean those iTemp
8520 variables defined by the compiler that still survive after all the optimization
8522 Live range analysis is essential for register allocation, since these computati
8523 on determines which of these iTemps will be assigned to registers, and for
8527 Phase five is register allocation.
8528 There are two parts to this process.
8532 The first part I call 'register packing' (for lack of a better term).
8533 In this case several MCU specific expression folding is done to reduce
8538 The second part is more MCU independent and deals with allocating registers
8539 to the remaining live ranges.
8540 A lot of MCU specific code does creep into this phase because of the limited
8541 number of index registers available in the 8051.
8544 The Code generation phase is (unhappily), entirely MCU dependent and very
8545 little (if any at all) of this code can be reused for other MCU.
8546 However the scheme for allocating a homogenized assembler operand for each
8547 iCode operand may be reused.
8550 As mentioned in the optimization section the peep-hole optimizer is rule
8551 based system, which can reprogrammed for other MCUs.
8554 SDCDB - Source Level Debugger
8557 SDCC is distributed with a source level debugger.
8558 The debugger uses a command line interface, the command repertoire of the
8559 debugger has been kept as close to gdb (the GNU debugger) as possible.
8560 The configuration and build process is part of the standard compiler installati
8561 on, which also builds and installs the debugger in the target directory
8562 specified during configuration.
8563 The debugger allows you debug BOTH at the C source and at the ASM source
8567 Compiling for Debugging
8572 debug option must be specified for all files for which debug information
8574 The complier generates a .adb file for each of these files.
8575 The linker creates the .cdb file from the .adb files and the address information.
8576 This .cdb is used by the debugger.
8579 How the Debugger Works
8582 When the ---debug option is specified the compiler generates extra symbol
8583 information some of which are put into the the assembler source and some
8584 are put into the .adb file.
8585 Then the linker creates the .cdb file from the individual .adb files with
8586 the address information for the symbols.
8587 The debugger reads the symbolic information generated by the compiler &
8588 the address information generated by the linker.
8589 It uses the SIMULATOR (Daniel's S51) to execute the program, the program
8590 execution is controlled by the debugger.
8591 When a command is issued for the debugger, it translates it into appropriate
8592 commands for the simulator.
8595 Starting the Debugger
8598 The debugger can be started using the following command line.
8599 (Assume the file you are debugging has the file name foo).
8613 The debugger will look for the following files.
8616 foo.c - the source file.
8619 foo.cdb - the debugger symbol information file.
8622 foo.ihx - the intel hex format object file.
8625 Command Line Options.
8628 ---directory=<source file directory> this option can used to specify the
8629 directory search list.
8630 The debugger will look into the directory list specified for source, cdb
8632 The items in the directory list must be separated by ':', e.g.
8633 if the source files can be in the directories /home/src1 and /home/src2,
8634 the ---directory option should be ---directory=/home/src1:/home/src2.
8635 Note there can be no spaces in the option.
8639 -cd <directory> - change to the <directory>.
8642 -fullname - used by GUI front ends.
8645 -cpu <cpu-type> - this argument is passed to the simulator please see the
8646 simulator docs for details.
8649 -X <Clock frequency > this options is passed to the simulator please see
8650 the simulator docs for details.
8653 -s <serial port file> passed to simulator see the simulator docs for details.
8656 -S <serial in,out> passed to simulator see the simulator docs for details.
8662 As mention earlier the command interface for the debugger has been deliberately
8663 kept as close the GNU debugger gdb, as possible.
8664 This will help the integration with existing graphical user interfaces
8665 (like ddd, xxgdb or xemacs) existing for the GNU debugger.
8666 \layout Subsubsection
8668 break [line | file:line | function | file:function]
8671 Set breakpoint at specified line or function:
8680 sdcdb>break foo.c:100
8684 sdcdb>break foo.c:funcfoo
8685 \layout Subsubsection
8687 clear [line | file:line | function | file:function ]
8690 Clear breakpoint at specified line or function:
8699 sdcdb>clear foo.c:100
8703 sdcdb>clear foo.c:funcfoo
8704 \layout Subsubsection
8709 Continue program being debugged, after breakpoint.
8710 \layout Subsubsection
8715 Execute till the end of the current function.
8716 \layout Subsubsection
8721 Delete breakpoint number 'n'.
8722 If used without any option clear ALL user defined break points.
8723 \layout Subsubsection
8725 info [break | stack | frame | registers ]
8728 info break - list all breakpoints
8731 info stack - show the function call stack.
8734 info frame - show information about the current execution frame.
8737 info registers - show content of all registers.
8738 \layout Subsubsection
8743 Step program until it reaches a different source line.
8744 \layout Subsubsection
8749 Step program, proceeding through subroutine calls.
8750 \layout Subsubsection
8755 Start debugged program.
8756 \layout Subsubsection
8761 Print type information of the variable.
8762 \layout Subsubsection
8767 print value of variable.
8768 \layout Subsubsection
8773 load the given file name.
8774 Note this is an alternate method of loading file for debugging.
8775 \layout Subsubsection
8780 print information about current frame.
8781 \layout Subsubsection
8786 Toggle between C source & assembly source.
8787 \layout Subsubsection
8792 Send the string following '!' to the simulator, the simulator response is
8794 Note the debugger does not interpret the command being sent to the simulator,
8795 so if a command like 'go' is sent the debugger can loose its execution
8796 context and may display incorrect values.
8797 \layout Subsubsection
8804 My name is Bobby Brown"
8807 Interfacing with XEmacs.
8810 Two files (in emacs lisp) are provided for the interfacing with XEmacs,
8811 sdcdb.el and sdcdbsrc.el.
8812 These two files can be found in the $(prefix)/bin directory after the installat
8814 These files need to be loaded into XEmacs for the interface to work.
8815 This can be done at XEmacs startup time by inserting the following into
8816 your '.xemacs' file (which can be found in your HOME directory):
8822 (load-file sdcdbsrc.el)
8828 .xemacs is a lisp file so the () around the command is REQUIRED.
8829 The files can also be loaded dynamically while XEmacs is running, set the
8830 environment variable 'EMACSLOADPATH' to the installation bin directory
8831 (<installdir>/bin), then enter the following command ESC-x load-file sdcdbsrc.
8832 To start the interface enter the following command:
8846 You will prompted to enter the file name to be debugged.
8851 The command line options that are passed to the simulator directly are bound
8852 to default values in the file sdcdbsrc.el.
8853 The variables are listed below, these values maybe changed as required.
8856 sdcdbsrc-cpu-type '51
8859 sdcdbsrc-frequency '11059200
8865 The following is a list of key mapping for the debugger interface.
8873 ;; Current Listing ::
8890 binding\SpecialChar ~
8929 ------\SpecialChar ~
8969 sdcdb-next-from-src\SpecialChar ~
8995 sdcdb-back-from-src\SpecialChar ~
9021 sdcdb-cont-from-src\SpecialChar ~
9031 SDCDB continue command
9047 sdcdb-step-from-src\SpecialChar ~
9073 sdcdb-whatis-c-sexp\SpecialChar ~
9083 SDCDB ptypecommand for data at
9147 sdcdbsrc-delete\SpecialChar ~
9161 SDCDB Delete all breakpoints if no arg
9209 given or delete arg (C-u arg x)
9225 sdcdbsrc-frame\SpecialChar ~
9240 SDCDB Display current frame if no arg,
9289 given or display frame arg
9354 sdcdbsrc-goto-sdcdb\SpecialChar ~
9364 Goto the SDCDB output buffer
9380 sdcdb-print-c-sexp\SpecialChar ~
9391 SDCDB print command for data at
9455 sdcdbsrc-goto-sdcdb\SpecialChar ~
9465 Goto the SDCDB output buffer
9481 sdcdbsrc-mode\SpecialChar ~
9497 Toggles Sdcdbsrc mode (turns it off)
9501 ;; C-c C-f\SpecialChar ~
9509 sdcdb-finish-from-src\SpecialChar ~
9517 SDCDB finish command
9521 ;; C-x SPC\SpecialChar ~
9529 sdcdb-break\SpecialChar ~
9547 Set break for line with point
9549 ;; ESC t\SpecialChar ~
9559 sdcdbsrc-mode\SpecialChar ~
9575 Toggle Sdcdbsrc mode
9577 ;; ESC m\SpecialChar ~
9587 sdcdbsrc-srcmode\SpecialChar ~
9611 The Z80 and gbz80 port
9614 SDCC can target both the Zilog Z80 and the Nintendo Gameboy's Z80-like gbz80.
9615 The port is incomplete - long support is incomplete (mul, div and mod are
9616 unimplimented), and both float and bitfield support is missing.
9617 Apart from that the code generated is correct.
9620 As always, the code is the authoritave reference - see z80/ralloc.c and z80/gen.c.
9621 The stack frame is similar to that generated by the IAR Z80 compiler.
9622 IX is used as the base pointer, HL is used as a temporary register, and
9623 BC and DE are available for holding varibles.
9624 IY is currently unusued.
9625 Return values are stored in HL.
9626 One bad side effect of using IX as the base pointer is that a functions
9627 stack frame is limited to 127 bytes - this will be fixed in a later version.
9633 SDCC has grown to be a large project.
9634 The compiler alone (without the preprocessor, assembler and linker) is
9635 about 40,000 lines of code (blank stripped).
9636 The open source nature of this project is a key to its continued growth
9638 You gain the benefit and support of many active software developers and
9640 Is SDCC perfect? No, that's why we need your help.
9641 The developers take pride in fixing reported bugs.
9642 You can help by reporting the bugs and helping other SDCC users.
9643 There are lots of ways to contribute, and we encourage you to take part
9644 in making SDCC a great software package.
9650 Send an email to the mailing list at 'user-sdcc@sdcc.sourceforge.net' or 'devel-sd
9651 cc@sdcc.sourceforge.net'.
9652 Bugs will be fixed ASAP.
9653 When reporting a bug, it is very useful to include a small test program
9654 which reproduces the problem.
9655 If you can isolate the problem by looking at the generated assembly code,
9656 this can be very helpful.
9657 Compiling your program with the ---dumpall option can sometimes be useful
9658 in locating optimization problems.
9664 The anatomy of the compiler
9669 This is an excerpt from an atricle published in Circuit Cellar MagaZine
9671 It's a little outdated (the compiler is much more efficient now and user/devell
9672 oper friendly), but pretty well exposes the guts of it all.
9678 The current version of SDCC can generate code for Intel 8051 and Z80 MCU.
9679 It is fairly easy to retarget for other 8-bit MCU.
9680 Here we take a look at some of the internals of the compiler.
9687 Parsing the input source file and creating an AST (Annotated Syntax Tree).
9688 This phase also involves propagating types (annotating each node of the
9689 parse tree with type information) and semantic analysis.
9690 There are some MCU specific parsing rules.
9691 For example the storage classes, the extended storage classes are MCU specific
9692 while there may be a xdata storage class for 8051 there is no such storage
9693 class for z80 or Atmel AVR.
9694 SDCC allows MCU specific storage class extensions, i.e.
9695 xdata will be treated as a storage class specifier when parsing 8051 C
9696 code but will be treated as a C identifier when parsing z80 or ATMEL AVR
9703 Intermediate code generation.
9704 In this phase the AST is broken down into three-operand form (iCode).
9705 These three operand forms are represented as doubly linked lists.
9706 ICode is the term given to the intermediate form generated by the compiler.
9707 ICode example section shows some examples of iCode generated for some simple
9714 Bulk of the target independent optimizations is performed in this phase.
9715 The optimizations include constant propagation, common sub-expression eliminati
9716 on, loop invariant code movement, strength reduction of loop induction variables
9717 and dead-code elimination.
9723 During intermediate code generation phase, the compiler assumes the target
9724 machine has infinite number of registers and generates a lot of temporary
9726 The live range computation determines the lifetime of each of these compiler-ge
9727 nerated temporaries.
9728 A picture speaks a thousand words.
9729 ICode example sections show the live range annotations for each of the
9731 It is important to note here, each iCode is assigned a number in the order
9732 of its execution in the function.
9733 The live ranges are computed in terms of these numbers.
9734 The from number is the number of the iCode which first defines the operand
9735 and the to number signifies the iCode which uses this operand last.
9741 The register allocation determines the type and number of registers needed
9743 In most MCUs only a few registers can be used for indirect addressing.
9744 In case of 8051 for example the registers R0 & R1 can be used to indirectly
9745 address the internal ram and DPTR to indirectly address the external ram.
9746 The compiler will try to allocate the appropriate register to pointer variables
9748 ICode example section shows the operands annotated with the registers assigned
9750 The compiler will try to keep operands in registers as much as possible;
9751 there are several schemes the compiler uses to do achieve this.
9752 When the compiler runs out of registers the compiler will check to see
9753 if there are any live operands which is not used or defined in the current
9754 basic block being processed, if there are any found then it will push that
9755 operand and use the registers in this block, the operand will then be popped
9756 at the end of the basic block.
9760 There are other MCU specific considerations in this phase.
9761 Some MCUs have an accumulator; very short-lived operands could be assigned
9762 to the accumulator instead of general-purpose register.
9768 Figure II gives a table of iCode operations supported by the compiler.
9769 The code generation involves translating these operations into corresponding
9770 assembly code for the processor.
9771 This sounds overly simple but that is the essence of code generation.
9772 Some of the iCode operations are generated on a MCU specific manner for
9773 example, the z80 port does not use registers to pass parameters so the
9774 SEND and RECV iCode operations will not be generated, and it also does
9775 not support JUMPTABLES.
9782 <Where is Figure II ?>
9788 This section shows some details of iCode.
9789 The example C code does not do anything useful; it is used as an example
9790 to illustrate the intermediate code generated by the compiler.
9803 /* This function does nothing useful.
9810 for the purpose of explaining iCode */
9813 short function (data int *x)
9821 short i=10; /* dead initialization eliminated */
9826 short sum=10; /* dead initialization eliminated */
9839 while (*x) *x++ = *p++;
9853 /* compiler detects i,j to be induction variables */
9857 for (i = 0, j = 10 ; i < 10 ; i++, j---) {
9869 mul += i * 3; /* this multiplication remains */
9875 gint += j * 3;/* this multiplication changed to addition */
9892 In addition to the operands each iCode contains information about the filename
9893 and line it corresponds to in the source file.
9894 The first field in the listing should be interpreted as follows:
9899 Filename(linenumber: iCode Execution sequence number : ICode hash table
9900 key : loop depth of the iCode).
9905 Then follows the human readable form of the ICode operation.
9906 Each operand of this triplet form can be of three basic types a) compiler
9907 generated temporary b) user defined variable c) a constant value.
9908 Note that local variables and parameters are replaced by compiler generated
9910 Live ranges are computed only for temporaries (i.e.
9911 live ranges are not computed for global variables).
9912 Registers are allocated for temporaries only.
9913 Operands are formatted in the following manner:
9918 Operand Name [lr live-from : live-to ] { type information } [ registers
9924 As mentioned earlier the live ranges are computed in terms of the execution
9925 sequence number of the iCodes, for example
9927 the iTemp0 is live from (i.e.
9928 first defined in iCode with execution sequence number 3, and is last used
9929 in the iCode with sequence number 5).
9930 For induction variables such as iTemp21 the live range computation extends
9931 the lifetime from the start to the end of the loop.
9933 The register allocator used the live range information to allocate registers,
9934 the same registers may be used for different temporaries if their live
9935 ranges do not overlap, for example r0 is allocated to both iTemp6 and to
9936 iTemp17 since their live ranges do not overlap.
9937 In addition the allocator also takes into consideration the type and usage
9938 of a temporary, for example itemp6 is a pointer to near space and is used
9939 as to fetch data from (i.e.
9940 used in GET_VALUE_AT_ADDRESS) so it is allocated a pointer registers (r0).
9941 Some short lived temporaries are allocated to special registers which have
9942 meaning to the code generator e.g.
9943 iTemp13 is allocated to a pseudo register CC which tells the back end that
9944 the temporary is used only for a conditional jump the code generation makes
9945 use of this information to optimize a compare and jump ICode.
9947 There are several loop optimizations performed by the compiler.
9948 It can detect induction variables iTemp21(i) and iTemp23(j).
9949 Also note the compiler does selective strength reduction, i.e.
9950 the multiplication of an induction variable in line 18 (gint = j * 3) is
9951 changed to addition, a new temporary iTemp17 is allocated and assigned
9952 a initial value, a constant 3 is then added for each iteration of the loop.
9953 The compiler does not change the multiplication in line 17 however since
9954 the processor does support an 8 * 8 bit multiplication.
9956 Note the dead code elimination optimization eliminated the dead assignments
9957 in line 7 & 8 to I and sum respectively.
9964 Sample.c (5:1:0:0) _entry($9) :
9969 Sample.c(5:2:1:0) proc _function [lr0:0]{function short}
9974 Sample.c(11:3:2:0) iTemp0 [lr3:5]{_near * int}[r2] = recv
9979 Sample.c(11:4:53:0) preHeaderLbl0($11) :
9984 Sample.c(11:5:55:0) iTemp6 [lr5:16]{_near * int}[r0] := iTemp0 [lr3:5]{_near
9990 Sample.c(11:6:5:1) _whilecontinue_0($1) :
9995 Sample.c(11:7:7:1) iTemp4 [lr7:8]{int}[r2 r3] = @[iTemp6 [lr5:16]{_near *
10001 Sample.c(11:8:8:1) if iTemp4 [lr7:8]{int}[r2 r3] == 0 goto _whilebreak_0($3)
10006 Sample.c(11:9:14:1) iTemp7 [lr9:13]{_far * int}[DPTR] := _p [lr0:0]{_far
10012 Sample.c(11:10:15:1) _p [lr0:0]{_far * int} = _p [lr0:0]{_far * int} + 0x2
10018 Sample.c(11:13:18:1) iTemp10 [lr13:14]{int}[r2 r3] = @[iTemp7 [lr9:13]{_far
10024 Sample.c(11:14:19:1) *(iTemp6 [lr5:16]{_near * int}[r0]) := iTemp10 [lr13:14]{int
10030 Sample.c(11:15:12:1) iTemp6 [lr5:16]{_near * int}[r0] = iTemp6 [lr5:16]{_near
10031 * int}[r0] + 0x2 {short}
10036 Sample.c(11:16:20:1) goto _whilecontinue_0($1)
10041 Sample.c(11:17:21:0)_whilebreak_0($3) :
10046 Sample.c(12:18:22:0) iTemp2 [lr18:40]{short}[r2] := 0x0 {short}
10051 Sample.c(13:19:23:0) iTemp11 [lr19:40]{short}[r3] := 0x0 {short}
10056 Sample.c(15:20:54:0)preHeaderLbl1($13) :
10061 Sample.c(15:21:56:0) iTemp21 [lr21:38]{short}[r4] := 0x0 {short}
10066 Sample.c(15:22:57:0) iTemp23 [lr22:38]{int}[r5 r6] := 0xa {int}
10071 Sample.c(15:23:58:0) iTemp17 [lr23:38]{int}[r7 r0] := 0x1e {int}
10076 Sample.c(15:24:26:1)_forcond_0($4) :
10081 Sample.c(15:25:27:1) iTemp13 [lr25:26]{char}[CC] = iTemp21 [lr21:38]{short}[r4]
10087 Sample.c(15:26:28:1) if iTemp13 [lr25:26]{char}[CC] == 0 goto _forbreak_0($7)
10092 Sample.c(16:27:31:1) iTemp2 [lr18:40]{short}[r2] = iTemp2 [lr18:40]{short}[r2]
10093 + ITemp21 [lr21:38]{short}[r4]
10098 Sample.c(17:29:33:1) iTemp15 [lr29:30]{short}[r1] = iTemp21 [lr21:38]{short}[r4]
10104 Sample.c(17:30:34:1) iTemp11 [lr19:40]{short}[r3] = iTemp11 [lr19:40]{short}[r3]
10105 + iTemp15 [lr29:30]{short}[r1]
10110 Sample.c(18:32:36:1:1) iTemp17 [lr23:38]{int}[r7 r0]= iTemp17 [lr23:38]{int}[r7
10116 Sample.c(18:33:37:1) _gint [lr0:0]{int} = _gint [lr0:0]{int} + iTemp17 [lr23:38]{
10122 Sample.c(15:36:42:1) iTemp21 [lr21:38]{short}[r4] = iTemp21 [lr21:38]{short}[r4]
10128 Sample.c(15:37:45:1) iTemp23 [lr22:38]{int}[r5 r6]= iTemp23 [lr22:38]{int}[r5
10134 Sample.c(19:38:47:1) goto _forcond_0($4)
10139 Sample.c(19:39:48:0)_forbreak_0($7) :
10144 Sample.c(20:40:49:0) iTemp24 [lr40:41]{short}[DPTR] = iTemp2 [lr18:40]{short}[r2]
10145 + ITemp11 [lr19:40]{short}[r3]
10150 Sample.c(20:41:50:0) ret iTemp24 [lr40:41]{short}
10155 Sample.c(20:42:51:0)_return($8) :
10160 Sample.c(20:43:52:0) eproc _function [lr0:0]{ ia0 re0 rm0}{function short}
10166 Finally the code generated for this function:
10207 ; ----------------------------------------------
10212 ; function function
10217 ; ----------------------------------------------
10227 ; iTemp0 [lr3:5]{_near * int}[r2] = recv
10239 ; iTemp6 [lr5:16]{_near * int}[r0] := iTemp0 [lr3:5]{_near * int}[r2]
10251 ;_whilecontinue_0($1) :
10261 ; iTemp4 [lr7:8]{int}[r2 r3] = @[iTemp6 [lr5:16]{_near * int}[r0]]
10266 ; if iTemp4 [lr7:8]{int}[r2 r3] == 0 goto _whilebreak_0($3)
10325 ; iTemp7 [lr9:13]{_far * int}[DPTR] := _p [lr0:0]{_far * int}
10344 ; _p [lr0:0]{_far * int} = _p [lr0:0]{_far * int} + 0x2 {short}
10391 ; iTemp10 [lr13:14]{int}[r2 r3] = @[iTemp7 [lr9:13]{_far * int}[DPTR]]
10431 ; *(iTemp6 [lr5:16]{_near * int}[r0]) := iTemp10 [lr13:14]{int}[r2 r3]
10457 ; iTemp6 [lr5:16]{_near * int}[r0] =
10462 ; iTemp6 [lr5:16]{_near * int}[r0] +
10479 ; goto _whilecontinue_0($1)
10491 ; _whilebreak_0($3) :
10501 ; iTemp2 [lr18:40]{short}[r2] := 0x0 {short}
10513 ; iTemp11 [lr19:40]{short}[r3] := 0x0 {short}
10525 ; iTemp21 [lr21:38]{short}[r4] := 0x0 {short}
10537 ; iTemp23 [lr22:38]{int}[r5 r6] := 0xa {int}
10556 ; iTemp17 [lr23:38]{int}[r7 r0] := 0x1e {int}
10585 ; iTemp13 [lr25:26]{char}[CC] = iTemp21 [lr21:38]{short}[r4] < 0xa {short}
10590 ; if iTemp13 [lr25:26]{char}[CC] == 0 goto _forbreak_0($7)
10635 ; iTemp2 [lr18:40]{short}[r2] = iTemp2 [lr18:40]{short}[r2] +
10640 ; iTemp21 [lr21:38]{short}[r4]
10666 ; iTemp15 [lr29:30]{short}[r1] = iTemp21 [lr21:38]{short}[r4] * 0x3 {short}
10699 ; iTemp11 [lr19:40]{short}[r3] = iTemp11 [lr19:40]{short}[r3] +
10704 ; iTemp15 [lr29:30]{short}[r1]
10723 ; iTemp17 [lr23:38]{int}[r7 r0]= iTemp17 [lr23:38]{int}[r7 r0]- 0x3 {short}
10770 ; _gint [lr0:0]{int} = _gint [lr0:0]{int} + iTemp17 [lr23:38]{int}[r7 r0]
10817 ; iTemp21 [lr21:38]{short}[r4] = iTemp21 [lr21:38]{short}[r4] + 0x1 {short}
10829 ; iTemp23 [lr22:38]{int}[r5 r6]= iTemp23 [lr22:38]{int}[r5 r6]- 0x1 {short}
10843 cjne r5,#0xff,00104$
10855 ; goto _forcond_0($4)
10867 ; _forbreak_0($7) :
10877 ; ret iTemp24 [lr40:41]{short}
10920 A few words about basic block successors, predecessors and dominators
10923 Successors are basic blocks that might execute after this basic block.
10925 Predecessors are basic blocks that might execute before reaching this basic
10928 Dominators are basic blocks that WILL execute before reaching this basic
10954 a) succList of [BB2] = [BB4], of [BB3] = [BB4], of [BB1] = [BB2,BB3]
10957 b) predList of [BB2] = [BB1], of [BB3] = [BB1], of [BB4] = [BB2,BB3]
10960 c) domVect of [BB4] = BB1 ...
10961 here we are not sure if BB2 or BB3 was executed but we are SURE that BB1
10969 \begin_inset LatexCommand \url{http://sdcc.sourceforge.net#Who}
10979 Thanks to all the other volunteer developers who have helped with coding,
10980 testing, web-page creation, distribution sets, etc.
10981 You know who you are :-)
10988 This document was initially written by Sandeep Dutta
10991 All product names mentioned herein may be trademarks of their respective
10997 \begin_inset LatexCommand \printindex{}