1 #LyX 1.2 created this file. For more info see http://www.lyx.org/
15 \use_numerical_citations 0
16 \paperorientation portrait
19 \paragraph_separation indent
21 \quotes_language swedish
29 SDCC Compiler User Guide
33 \begin_inset LatexCommand \tableofcontents{}
50 is a Freeware, retargettable, optimizing ANSI-C compiler by
54 designed for 8 bit Microprocessors.
55 The current version targets Intel MCS51 based Microprocessors(8051,8052,
56 etc), Zilog Z80 based MCUs, and the Dallas DS80C390 variant.
57 It can be retargetted for other microprocessors, support for PIC, AVR and
58 186 is under development.
59 The entire source code for the compiler is distributed under GPL.
60 SDCC uses ASXXXX & ASLINK, a Freeware, retargettable assembler & linker.
61 SDCC has extensive language extensions suitable for utilizing various microcont
62 rollers and underlying hardware effectively.
67 In addition to the MCU specific optimizations SDCC also does a host of standard
71 global sub expression elimination,
74 loop optimizations (loop invariant, strength reduction of induction variables
78 constant folding & propagation,
94 For the back-end SDCC uses a global register allocation scheme which should
95 be well suited for other 8 bit MCUs.
100 The peep hole optimizer uses a rule based substitution mechanism which is
106 Supported data-types are:
109 char (8 bits, 1 byte),
112 short and int (16 bits, 2 bytes),
115 long (32 bit, 4 bytes)
122 The compiler also allows
124 inline assembler code
126 to be embedded anywhere in a function.
127 In addition, routines developed in assembly can also be called.
131 SDCC also provides an option (---cyclomatic) to report the relative complexity
133 These functions can then be further optimized, or hand coded in assembly
139 SDCC also comes with a companion source level debugger SDCDB, the debugger
140 currently uses ucSim a freeware simulator for 8051 and other micro-controllers.
145 The latest version can be downloaded from
146 \begin_inset LatexCommand \htmlurl{http://sdcc.sourceforge.net/}
158 All packages used in this compiler system are
166 ; source code for all the sub-packages (pre-processor, assemblers, linkers
167 etc) is distributed with the package.
168 This documentation is maintained using a freeware word processor (LyX).
170 This program is free software; you can redistribute it and/or modify it
171 under the terms of the GNU General Public License as published by the Free
172 Software Foundation; either version 2, or (at your option) any later version.
173 This program is distributed in the hope that it will be useful, but WITHOUT
174 ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
175 FOR A PARTICULAR PURPOSE.
176 See the GNU General Public License for more details.
177 You should have received a copy of the GNU General Public License along
178 with this program; if not, write to the Free Software Foundation, 59 Temple
179 Place - Suite 330, Boston, MA 02111-1307, USA.
180 In other words, you are welcome to use, share and improve this program.
181 You are forbidden to forbid anyone else to use, share and improve what
183 Help stamp out software-hoarding!
186 Typographic conventions
189 Throughout this manual, we will use the following convention.
190 Commands you have to type in are printed in
198 Code samples are printed in
203 Interesting items and new terms are printed in
208 Compatibility with previous versions
211 This version has numerous bug fixes compared with the previous version.
212 But we also introduced some incompatibilities with older versions.
213 Not just for the fun of it, but to make the compiler more stable, efficient
220 short is now equivalent to int (16 bits), it used to be equivalent to char
221 (8 bits) which is not ANSI compliant
224 the default directory where include, library and documention files are stored
225 is now in /usr/local/share
228 char type parameters to vararg functions are casted to int unless explicitly
245 will push a as an int and as a char resp.
248 option ---regextend has been removed
251 option ---noregparms has been removed
254 option ---stack-after-data has been removed
259 <pending: more incompatibilities?>
265 What do you need before you start installation of SDCC? A computer, and
267 The preferred method of installation is to compile SDCC from source using
269 For Windows some pre-compiled binary distributions are available for your
271 You should have some experience with command line tools and compiler use.
277 The SDCC home page at
278 \begin_inset LatexCommand \htmlurl{http://sdcc.sourceforge.net/}
282 is a great place to find distribution sets.
283 You can also find links to the user mailing lists that offer help or discuss
284 SDCC with other SDCC users.
285 Web links to other SDCC related sites can also be found here.
286 This document can be found in the DOC directory of the source package as
288 Some of the other tools (simulator and assembler) included with SDCC contain
289 their own documentation and can be found in the source distribution.
290 If you want the latest unreleased software, the complete source package
291 is available directly by anonymous CVS on cvs.sdcc.sourceforge.net.
294 Wishes for the future
297 There are (and always will be) some things that could be done.
298 Here are some I can think of:
305 char KernelFunction3(char p) at 0x340;
311 If you can think of some more, please send them to the list.
317 <pending: And then of course a proper index-table
318 \begin_inset LatexCommand \index{index}
328 Install and search paths
331 Linux (and other gcc-builds like Solaris, Cygwin, Mingw and OSX) by default
332 install in /usr/local.
333 You can override this when configuring with ---prefix-path.
334 Subdirs used will be bin, share/sdcc/include, share/sdcc/lib and share/sdcc/doc.
336 Windows MSVC and Borland builds will install in one single tree (e.g.
337 /sdcc) with subdirs bin, lib, include and doc.
341 The paths searched when running the compiler are as follows (the first catch
345 Binary files (preprocessor, assembler and linker):
347 - the path of argv[0] (if available)
350 \begin_inset Quotes sld
354 \begin_inset Quotes srd
360 \begin_inset Quotes sld
364 \begin_inset Quotes srd
377 \begin_inset Quotes sld
381 \begin_inset Quotes srd
387 \begin_inset Quotes sld
392 - /usr/local/share/sdcc/include (gcc builds)
394 - path(arv[0])/../include and then /sdcc/include (windoze msvc and borland
402 is auto-appended by the compiler, e.g.
403 small, large, z80, ds390 etc.):
408 \begin_inset Quotes sld
412 \begin_inset Quotes srd
422 \begin_inset Quotes sld
426 \begin_inset Quotes srd
435 - /usr/local/share/sdcc/lib/
441 - path(argv[0])/../lib/
449 (windoze msvc and borland builds)
452 Documentation (although never really searched for, you have to do that yourself
456 \begin_inset Quotes sld
460 \begin_inset Quotes srd
465 - /usr/local/share/sdcc/doc (gcc builds)
467 - /sdcc/doc (windoze msvc and borland builds)
470 So, for windoze it is highly recommended to set the environment variable
471 SDCCHOME to prevent needless usage of -I and -L.
474 Linux and other gcc-based systems (cygwin, mingw, osx)
479 Download the source package
481 either from the SDCC CVS repository or from the
482 \begin_inset LatexCommand \url[nightly snapshots]{http://sdcc.sourceforge.net/snap.php}
488 , it will be named something like sdcc
497 Bring up a command line terminal, such as xterm.
502 Unpack the file using a command like:
505 "tar -xzf sdcc.src.tgz
510 , this will create a sub-directory called sdcc with all of the sources.
513 Change directory into the main SDCC directory, for example type:
530 This configures the package for compilation on your system.
546 All of the source packages will compile, this can take a while.
562 This copies the binary executables, the include files, the libraries and
563 the documentation to the install directories.
567 \layout Subsubsection
569 Windows Install Using a Binary Package
572 Download the binary package and unpack it using your favorite unpacking
573 tool (gunzip, WinZip, etc).
574 This should unpack to a group of sub-directories.
575 An example directory structure after unpacking the mingw package is: c:
581 bin for the executables, c:
601 lib for the include and libraries.
604 Adjust your environment variable PATH to include the location of the bin
605 directory or start sdcc using the full path.
606 \layout Subsubsection
608 Windows Install Using Cygwin and Mingw
611 Follow the instruction in
613 Linux and other gcc-based systems
616 \layout Subsubsection
618 Windows Install Using Microsoft Visual C++ 6.0/NET
623 Download the source package
625 either from the SDCC CVS repository or from the
626 \begin_inset LatexCommand \url[nightly snapshots]{http://sdcc.sourceforge.net/snap.php}
632 , it will be named something like sdcc
639 SDCC is distributed with all the projects, workspaces, and files you need
640 to build it using Visual C++ 6.0/NET.
641 The workspace name is 'sdcc.dsw'.
642 Please note that as it is now, all the executables are created in a folder
646 Once built you need to copy the executables from sdcc
650 bin before runnng SDCC.
655 In order to build SDCC with Visual C++ 6.0/NET you need win32 executables
656 of bison.exe, flex.exe, and gawk.exe.
657 One good place to get them is
658 \begin_inset LatexCommand \url[here]{http://unxutils.sourceforge.net}
666 Download the file UnxUtils.zip.
667 Now you have to install the utilities and setup Visual C++ so it can locate
668 the required programs.
669 Here there are two alternatives (choose one!):
676 a) Extract UnxUtils.zip to your C:
678 hard disk PRESERVING the original paths, otherwise bison won't work.
679 (If you are using WinZip make certain that 'Use folder names' is selected)
683 b) In the Visual C++ IDE click Tools, Options, select the Directory tab,
684 in 'Show directories for:' select 'Executable files', and in the directories
685 window add a new path: 'C:
695 (As a side effect, you get a bunch of Unix utilities that could be useful,
696 such as diff and patch.)
703 This one avoids extracting a bunch of files you may not use, but requires
708 a) Create a directory were to put the tools needed, or use a directory already
716 b) Extract 'bison.exe', 'bison.hairy', 'bison.simple', 'flex.exe', and gawk.exe
717 to such directory WITHOUT preserving the original paths.
718 (If you are using WinZip make certain that 'Use folder names' is not selected)
722 c) Rename bison.exe to '_bison.exe'.
726 d) Create a batch file 'bison.bat' in 'C:
730 ' and add these lines:
750 _bison %1 %2 %3 %4 %5 %6 %7 %8 %9
754 Steps 'c' and 'd' are needed because bison requires by default that the
755 files 'bison.simple' and 'bison.hairy' reside in some weird Unix directory,
756 '/usr/local/share/' I think.
757 So it is necessary to tell bison where those files are located if they
758 are not in such directory.
759 That is the function of the environment variables BISON_SIMPLE and BISON_HAIRY.
763 e) In the Visual C++ IDE click Tools, Options, select the Directory tab,
764 in 'Show directories for:' select 'Executable files', and in the directories
765 window add a new path: 'c:
768 Note that you can use any other path instead of 'c:
770 util', even the path where the Visual C++ tools are, probably: 'C:
774 Microsoft Visual Studio
779 So you don't have to execute step 'e' :)
783 Open 'sdcc.dsw' in Visual Studio, click 'build all', when it finishes copy
784 the executables from sdcc
788 bin, and you can compile using sdcc.
789 \layout Subsubsection
791 Windows Install Using Borland ......
799 Testing out the SDCC Compiler
802 The first thing you should do after installing your SDCC compiler is to
810 at the prompt, and the program should run and tell you the version.
811 If it doesn't run, or gives a message about not finding sdcc program, then
812 you need to check over your installation.
813 Make sure that the sdcc bin directory is in your executable search path
814 defined by the PATH environment setting (see the Trouble-shooting section
816 Make sure that the sdcc program is in the bin folder, if not perhaps something
817 did not install correctly.
823 SDCC binaries are commonly installed in a directory arrangement like this:
831 <lyxtabular version="3" rows="3" columns="2">
833 <column alignment="left" valignment="top" leftline="true" width="0(null)">
834 <column alignment="left" valignment="top" leftline="true" rightline="true" width="0(null)">
835 <row topline="true" bottomline="true">
836 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
846 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
853 Holds executables(sdcc, s51, aslink,
862 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
869 usr/local/share/sdcc/lib
872 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
885 <row topline="true" bottomline="true">
886 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
893 usr/local/share/sdcc/include
896 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
903 Holds common C header files
917 Make sure the compiler works on a very simple example.
918 Type in the following test.c program using your favorite editor:
949 Compile this using the following command:
958 If all goes well, the compiler will generate a test.asm and test.rel file.
959 Congratulations, you've just compiled your first program with SDCC.
960 We used the -c option to tell SDCC not to link the generated code, just
961 to keep things simple for this step.
969 The next step is to try it with the linker.
979 If all goes well the compiler will link with the libraries and produce
980 a test.ihx output file.
985 (no test.ihx, and the linker generates warnings), then the problem is most
986 likely that sdcc cannot find the
990 usr/local/share/sdcc/lib directory
994 (see the Install trouble-shooting section for suggestions).
1002 The final test is to ensure sdcc can use the
1006 header files and libraries.
1007 Edit test.c and change it to the following:
1027 strcpy(str1, "testing");
1036 Compile this by typing
1043 This should generate a test.ihx output file, and it should give no warnings
1044 such as not finding the string.h file.
1045 If it cannot find the string.h file, then the problem is that sdcc cannot
1046 find the /usr/local/share/sdcc/include directory
1050 (see the Install trouble-shooting section for suggestions).
1053 Install Trouble-shooting
1054 \layout Subsubsection
1056 SDCC does not build correctly.
1059 A thing to try is starting from scratch by unpacking the .tgz source package
1060 again in an empty directory.
1067 ./configure 2>&1 | tee configure.log
1079 make 2>&1 | tee make.log
1085 If anything goes wrong, you can review the log files to locate the problem.
1086 Or a relevant part of this can be attached to an email that could be helpful
1087 when requesting help from the mailing list.
1088 \layout Subsubsection
1091 \begin_inset Quotes sld
1095 \begin_inset Quotes srd
1102 \begin_inset Quotes sld
1106 \begin_inset Quotes srd
1109 command is a script that analyzes your system and performs some configuration
1110 to ensure the source package compiles on your system.
1111 It will take a few minutes to run, and will compile a few tests to determine
1112 what compiler features are installed.
1113 \layout Subsubsection
1116 \begin_inset Quotes sld
1120 \begin_inset Quotes srd
1126 This runs the GNU make tool, which automatically compiles all the source
1127 packages into the final installed binary executables.
1128 \layout Subsubsection
1131 \begin_inset Quotes sld
1135 \begin_inset Quotes erd
1141 This will install the compiler, other executables and libraries in to the
1142 appropriate system directories.
1143 The default is to copy the executables to /usr/local/bin and the libraries
1144 and header files to /usr/local/share/sdcc/lib and /usr/local/share/sdcc/include.
1145 On most systems you will need super-user privilages to do this.
1148 Advanced Install Options
1152 \begin_inset Quotes eld
1156 \begin_inset Quotes erd
1159 command has several options.
1160 The most commonly used option is ---prefix=<directory name>, where <directory
1161 name> is the final location for the sdcc executables and libraries, (default
1162 location is /usr/local).
1163 The installation process will create the following directory structure
1164 under the <directory name> specified (if they do not already exist).
1169 bin/ - binary exectables (add to PATH environment variable)
1173 bin/share/sdcc/include/ - include header files
1177 bin/share/sdcc/lib/small/ - Object & library files for small model library
1179 bin/share/sdcc/lib/large/ - Object & library files for large model library
1181 bin/share/sdcc/lib/ds390/ - Object & library files for DS80C390 library
1183 bin/share/sdcc/lib/z80/ - Object & library files for Z80 library
1191 \begin_inset Quotes sld
1194 ./configure ---prefix=/usr/local
1195 \begin_inset Quotes erd
1201 will configure the compiler to be installed in directory /usr/local.
1207 SDCC is not just a compiler, but a collection of tools by various developers.
1208 These include linkers, assemblers, simulators and other components.
1209 Here is a summary of some of the components.
1210 Note that the included simulator and assembler have separate documentation
1211 which you can find in the source package in their respective directories.
1212 As SDCC grows to include support for other processors, other packages from
1213 various developers are included and may have their own sets of documentation.
1217 You might want to look at the files which are installed in <installdir>.
1218 At the time of this writing, we find the following programs:
1222 In <installdir>/bin:
1225 sdcc - The compiler.
1228 sdcpp - The C preprocessor.
1231 asx8051 - The assembler for 8051 type processors.
1238 as-gbz80 - The Z80 and GameBoy Z80 assemblers.
1241 aslink -The linker for 8051 type processors.
1248 link-gbz80 - The Z80 and GameBoy Z80 linkers.
1251 s51 - The ucSim 8051 simulator.
1254 sdcdb - The source debugger.
1257 packihx - A tool to pack (compress) Intel hex files.
1260 In <installdir>/share/sdcc/include
1266 In <installdir>/share/sdcc/lib
1269 the sources of the runtime library and the subdirs small large and ds390
1270 with the precompiled relocatables.
1273 In <installdir>/share/sdcc/doc
1279 As development for other processors proceeds, this list will expand to include
1280 executables to support processors like AVR, PIC, etc.
1281 \layout Subsubsection
1286 This is the actual compiler, it in turn uses the c-preprocessor and invokes
1287 the assembler and linkage editor.
1288 \layout Subsubsection
1290 sdcpp - The C-Preprocessor
1293 The preprocessor is a modified version of the GNU preprocessor.
1294 The C preprocessor is used to pull in #include sources, process #ifdef
1295 statements, #defines and so on.
1296 \layout Subsubsection
1298 asx8051, as-z80, as-gbz80, aslink, link-z80, link-gbz80 - The Assemblers
1302 This is retargettable assembler & linkage editor, it was developed by Alan
1304 John Hartman created the version for 8051, and I (Sandeep) have made some
1305 enhancements and bug fixes for it to work properly with the SDCC.
1306 \layout Subsubsection
1311 S51 is a freeware, opensource simulator developed by Daniel Drotos (
1312 \begin_inset LatexCommand \url{mailto:drdani@mazsola.iit.uni-miskolc.hu}
1317 The simulator is built as part of the build process.
1318 For more information visit Daniel's website at:
1319 \begin_inset LatexCommand \url{http://mazsola.iit.uni-miskolc.hu/~drdani/embedded/s51}
1324 It currently support the core mcs51, the Dallas DS80C390 and the Philips
1326 \layout Subsubsection
1328 sdcdb - Source Level Debugger
1334 <todo: is this thing alive?>
1341 Sdcdb is the companion source level debugger.
1342 The current version of the debugger uses Daniel's Simulator S51, but can
1343 be easily changed to use other simulators.
1350 \layout Subsubsection
1352 Single Source File Projects
1355 For single source file 8051 projects the process is very simple.
1356 Compile your programs with the following command
1359 "sdcc sourcefile.c".
1363 This will compile, assemble and link your source file.
1364 Output files are as follows
1368 sourcefile.asm - Assembler source file created by the compiler
1370 sourcefile.lst - Assembler listing file created by the Assembler
1372 sourcefile.rst - Assembler listing file updated with linkedit information,
1373 created by linkage editor
1375 sourcefile.sym - symbol listing for the sourcefile, created by the assembler
1377 sourcefile.rel - Object file created by the assembler, input to Linkage editor
1379 sourcefile.map - The memory map for the load module, created by the Linker
1381 sourcefile.ihx - The load module in Intel hex format (you can select the
1382 Motorola S19 format with ---out-fmt-s19)
1384 sourcefile.cdb - An optional file (with ---debug) containing debug information
1387 \layout Subsubsection
1389 Projects with Multiple Source Files
1392 SDCC can compile only ONE file at a time.
1393 Let us for example assume that you have a project containing the following
1398 foo1.c (contains some functions)
1400 foo2.c (contains some more functions)
1402 foomain.c (contains more functions and the function main)
1410 The first two files will need to be compiled separately with the commands:
1442 Then compile the source file containing the
1446 function and link the files together with the following command:
1454 foomain.c\SpecialChar ~
1455 foo1.rel\SpecialChar ~
1467 can be separately compiled as well:
1478 sdcc foomain.rel foo1.rel foo2.rel
1485 The file containing the
1500 file specified in the command line, since the linkage editor processes
1501 file in the order they are presented to it.
1502 \layout Subsubsection
1504 Projects with Additional Libraries
1507 Some reusable routines may be compiled into a library, see the documentation
1508 for the assembler and linkage editor (which are in <installdir>/share/sdcc/doc)
1514 Libraries created in this manner can be included in the command line.
1515 Make sure you include the -L <library-path> option to tell the linker where
1516 to look for these files if they are not in the current directory.
1517 Here is an example, assuming you have the source file
1529 (if that is not the same as your current project):
1536 sdcc foomain.c foolib.lib -L mylib
1547 must be an absolute path name.
1551 The most efficient way to use libraries is to keep seperate modules in seperate
1553 The lib file now should name all the modules.rel files.
1554 For an example see the standard library file
1558 in the directory <installdir>/share/lib/small.
1561 Command Line Options
1562 \layout Subsubsection
1564 Processor Selection Options
1566 \labelwidthstring 00.00.0000
1572 Generate code for the MCS51 (8051) family of processors.
1573 This is the default processor target.
1575 \labelwidthstring 00.00.0000
1581 Generate code for the DS80C390 processor.
1583 \labelwidthstring 00.00.0000
1589 Generate code for the Z80 family of processors.
1591 \labelwidthstring 00.00.0000
1597 Generate code for the GameBoy Z80 processor.
1599 \labelwidthstring 00.00.0000
1605 Generate code for the Atmel AVR processor (In development, not complete).
1607 \labelwidthstring 00.00.0000
1613 Generate code for the PIC 14-bit processors (In development, not complete).
1615 \labelwidthstring 00.00.0000
1621 Generate code for the Toshiba TLCS-900H processor (In development, not
1624 \labelwidthstring 00.00.0000
1630 Generate code for the Philips XA51 processor (In development, not complete).
1631 \layout Subsubsection
1633 Preprocessor Options
1635 \labelwidthstring 00.00.0000
1641 The additional location where the pre processor will look for <..h> or
1642 \begin_inset Quotes eld
1646 \begin_inset Quotes erd
1651 \labelwidthstring 00.00.0000
1657 Command line definition of macros.
1658 Passed to the pre processor.
1660 \labelwidthstring 00.00.0000
1666 Tell the preprocessor to output a rule suitable for make describing the
1667 dependencies of each object file.
1668 For each source file, the preprocessor outputs one make-rule whose target
1669 is the object file name for that source file and whose dependencies are
1670 all the files `#include'd in it.
1671 This rule may be a single line or may be continued with `
1673 '-newline if it is long.
1674 The list of rules is printed on standard output instead of the preprocessed
1678 \labelwidthstring 00.00.0000
1684 Tell the preprocessor not to discard comments.
1685 Used with the `-E' option.
1687 \labelwidthstring 00.00.0000
1698 Like `-M' but the output mentions only the user header files included with
1700 \begin_inset Quotes eld
1704 System header files included with `#include <file>' are omitted.
1706 \labelwidthstring 00.00.0000
1712 Assert the answer answer for question, in case it is tested with a preprocessor
1713 conditional such as `#if #question(answer)'.
1714 `-A-' disables the standard assertions that normally describe the target
1717 \labelwidthstring 00.00.0000
1723 (answer) Assert the answer answer for question, in case it is tested with
1724 a preprocessor conditional such as `#if #question(answer)'.
1725 `-A-' disables the standard assertions that normally describe the target
1728 \labelwidthstring 00.00.0000
1734 Undefine macro macro.
1735 `-U' options are evaluated after all `-D' options, but before any `-include'
1736 and `-imacros' options.
1738 \labelwidthstring 00.00.0000
1744 Tell the preprocessor to output only a list of the macro definitions that
1745 are in effect at the end of preprocessing.
1746 Used with the `-E' option.
1748 \labelwidthstring 00.00.0000
1754 Tell the preprocessor to pass all macro definitions into the output, in
1755 their proper sequence in the rest of the output.
1757 \labelwidthstring 00.00.0000
1768 Like `-dD' except that the macro arguments and contents are omitted.
1769 Only `#define name' is included in the output.
1770 \layout Subsubsection
1774 \labelwidthstring 00.00.0000
1781 the output path resp.
1782 file where everything will be placed
1784 \labelwidthstring 00.00.0000
1794 <absolute path to additional libraries> This option is passed to the linkage
1795 editor's additional libraries search path.
1796 The path name must be absolute.
1797 Additional library files may be specified in the command line.
1798 See section Compiling programs for more details.
1800 \labelwidthstring 00.00.0000
1806 <Value> The start location of the external ram, default value is 0.
1807 The value entered can be in Hexadecimal or Decimal format, e.g.: ---xram-loc
1808 0x8000 or ---xram-loc 32768.
1810 \labelwidthstring 00.00.0000
1816 <Value> The start location of the code segment, default value 0.
1817 Note when this option is used the interrupt vector table is also relocated
1818 to the given address.
1819 The value entered can be in Hexadecimal or Decimal format, e.g.: ---code-loc
1820 0x8000 or ---code-loc 32768.
1822 \labelwidthstring 00.00.0000
1828 <Value> By default the stack is placed after the data segment.
1829 Using this option the stack can be placed anywhere in the internal memory
1831 The value entered can be in Hexadecimal or Decimal format, e.g.
1832 ---stack-loc 0x20 or ---stack-loc 32.
1833 Since the sp register is incremented before a push or call, the initial
1834 sp will be set to one byte prior the provided value.
1835 The provided value should not overlap any other memory areas such as used
1836 register banks or the data segment and with enough space for the current
1839 \labelwidthstring 00.00.0000
1845 <Value> The start location of the internal ram data segment.
1846 The value entered can be in Hexadecimal or Decimal format, eg.
1847 ---data-loc 0x20 or ---data-loc 32.
1848 (By default, the start location of the internal ram data segment is set
1849 as low as possible in memory, taking into account the used register banks
1850 and the bit segment at address 0x20.
1851 For example if register banks 0 and 1 are used without bit variables, the
1852 data segment will be set, if ---data-loc is not used, to location 0x10.)
1854 \labelwidthstring 00.00.0000
1860 <Value> The start location of the indirectly addressable internal ram, default
1862 The value entered can be in Hexadecimal or Decimal format, eg.
1863 ---idata-loc 0x88 or ---idata-loc 136.
1865 \labelwidthstring 00.00.0000
1874 The linker output (final object code) is in Intel Hex format.
1875 (This is the default option).
1877 \labelwidthstring 00.00.0000
1886 The linker output (final object code) is in Motorola S19 format.
1887 \layout Subsubsection
1891 \labelwidthstring 00.00.0000
1897 Generate code for Large model programs see section Memory Models for more
1899 If this option is used all source files in the project should be compiled
1901 In addition the standard library routines are compiled with small model,
1902 they will need to be recompiled.
1904 \labelwidthstring 00.00.0000
1915 Generate code for Small Model programs see section Memory Models for more
1917 This is the default model.
1918 \layout Subsubsection
1922 \labelwidthstring 00.00.0000
1933 Generate 24-bit flat mode code.
1934 This is the one and only that the ds390 code generator supports right now
1935 and is default when using
1940 See section Memory Models for more details.
1942 \labelwidthstring 00.00.0000
1948 Generate code for the 10 bit stack mode of the Dallas DS80C390 part.
1949 This is the one and only that the ds390 code generator supports right now
1950 and is default when using
1955 In this mode, the stack is located in the lower 1K of the internal RAM,
1956 which is mapped to 0x400000.
1957 Note that the support is incomplete, since it still uses a single byte
1958 as the stack pointer.
1959 This means that only the lower 256 bytes of the potential 1K stack space
1960 will actually be used.
1961 However, this does allow you to reclaim the precious 256 bytes of low RAM
1962 for use for the DATA and IDATA segments.
1963 The compiler will not generate any code to put the processor into 10 bit
1965 It is important to ensure that the processor is in this mode before calling
1966 any re-entrant functions compiled with this option.
1967 In principle, this should work with the
1971 option, but that has not been tested.
1972 It is incompatible with the
1977 It also only makes sense if the processor is in 24 bit contiguous addressing
1980 ---model-flat24 option
1983 \layout Subsubsection
1985 Optimization Options
1987 \labelwidthstring 00.00.0000
1993 Will not do global subexpression elimination, this option may be used when
1994 the compiler creates undesirably large stack/data spaces to store compiler
1996 A warning message will be generated when this happens and the compiler
1997 will indicate the number of extra bytes it allocated.
1998 It recommended that this option NOT be used, #pragma\SpecialChar ~
2000 to turn off global subexpression elimination for a given function only.
2002 \labelwidthstring 00.00.0000
2008 Will not do loop invariant optimizations, this may be turned off for reasons
2009 explained for the previous option.
2010 For more details of loop optimizations performed see section Loop Invariants.It
2011 recommended that this option NOT be used, #pragma\SpecialChar ~
2012 NOINVARIANT can be used
2013 to turn off invariant optimizations for a given function only.
2015 \labelwidthstring 00.00.0000
2021 Will not do loop induction optimizations, see section strength reduction
2022 for more details.It is recommended that this option is NOT used, #pragma\SpecialChar ~
2024 ION can be used to turn off induction optimizations for a given function
2027 \labelwidthstring 00.00.0000
2038 Will not generate boundary condition check when switch statements are implement
2039 ed using jump-tables.
2040 See section Switch Statements for more details.
2041 It is recommended that this option is NOT used, #pragma\SpecialChar ~
2043 used to turn off boundary checking for jump tables for a given function
2046 \labelwidthstring 00.00.0000
2055 Will not do loop reversal optimization.
2057 \labelwidthstring 00.00.0000
2063 This will disable the memcpy of initialized data in far space from code
2065 \layout Subsubsection
2069 \labelwidthstring 00.00.0000
2076 will compile and assemble the source, but will not call the linkage editor.
2078 \labelwidthstring 00.00.0000
2084 Run only the C preprocessor.
2085 Preprocess all the C source files specified and output the results to standard
2088 \labelwidthstring 00.00.0000
2099 All functions in the source file will be compiled as
2104 the parameters and local variables will be allocated on the stack.
2105 see section Parameters and Local Variables for more details.
2106 If this option is used all source files in the project should be compiled
2110 \labelwidthstring 00.00.0000
2116 Uses a pseudo stack in the first 256 bytes in the external ram for allocating
2117 variables and passing parameters.
2118 See section on external stack for more details.
2120 \labelwidthstring 00.00.0000
2124 ---callee-saves function1[,function2][,function3]....
2127 The compiler by default uses a caller saves convention for register saving
2128 across function calls, however this can cause unneccessary register pushing
2129 & popping when calling small functions from larger functions.
2130 This option can be used to switch the register saving convention for the
2131 function names specified.
2132 The compiler will not save registers when calling these functions, no extra
2133 code will be generated at the entry & exit for these functions to save
2134 & restore the registers used by these functions, this can SUBSTANTIALLY
2135 reduce code & improve run time performance of the generated code.
2136 In the future the compiler (with interprocedural analysis) will be able
2137 to determine the appropriate scheme to use for each function call.
2138 DO NOT use this option for built-in functions such as _muluint..., if this
2139 option is used for a library function the appropriate library function
2140 needs to be recompiled with the same option.
2141 If the project consists of multiple source files then all the source file
2142 should be compiled with the same ---callee-saves option string.
2143 Also see #pragma\SpecialChar ~
2146 \labelwidthstring 00.00.0000
2155 When this option is used the compiler will generate debug information, that
2156 can be used with the SDCDB.
2157 The debug information is collected in a file with .cdb extension.
2158 For more information see documentation for SDCDB.
2160 \labelwidthstring 00.00.0000
2166 <filename> This option can be used to use additional rules to be used by
2167 the peep hole optimizer.
2168 See section Peep Hole optimizations for details on how to write these rules.
2170 \labelwidthstring 00.00.0000
2181 Stop after the stage of compilation proper; do not assemble.
2182 The output is an assembler code file for the input file specified.
2184 \labelwidthstring 00.00.0000
2188 -Wa_asmOption[,asmOption]
2191 Pass the asmOption to the assembler.
2193 \labelwidthstring 00.00.0000
2197 -Wl_linkOption[,linkOption]
2200 Pass the linkOption to the linker.
2202 \labelwidthstring 00.00.0000
2211 Integer (16 bit) and long (32 bit) libraries have been compiled as reentrant.
2212 Note by default these libraries are compiled as non-reentrant.
2213 See section Installation for more details.
2215 \labelwidthstring 00.00.0000
2224 This option will cause the compiler to generate an information message for
2225 each function in the source file.
2226 The message contains some
2230 information about the function.
2231 The number of edges and nodes the compiler detected in the control flow
2232 graph of the function, and most importantly the
2234 cyclomatic complexity
2236 see section on Cyclomatic Complexity for more details.
2238 \labelwidthstring 00.00.0000
2247 Floating point library is compiled as reentrant.See section Installation
2250 \labelwidthstring 00.00.0000
2256 The compiler will not overlay parameters and local variables of any function,
2257 see section Parameters and local variables for more details.
2259 \labelwidthstring 00.00.0000
2265 This option can be used when the code generated is called by a monitor
2267 The compiler will generate a 'ret' upon return from the 'main' function.
2268 The default option is to lock up i.e.
2271 \labelwidthstring 00.00.0000
2277 Disable peep-hole optimization.
2279 \labelwidthstring 00.00.0000
2285 Pass the inline assembler code through the peep hole optimizer.
2286 This can cause unexpected changes to inline assembler code, please go through
2287 the peephole optimizer rules defined in the source file tree '<target>/peeph.def
2288 ' before using this option.
2290 \labelwidthstring 00.00.0000
2296 <Value> Causes the linker to check if the internal ram usage is within limits
2299 \labelwidthstring 00.00.0000
2305 <Value> Causes the linker to check if the external ram usage is within limits
2308 \labelwidthstring 00.00.0000
2314 <Value> Causes the linker to check if the code usage is within limits of
2317 \labelwidthstring 00.00.0000
2323 This will prevent the compiler from passing on the default include path
2324 to the preprocessor.
2326 \labelwidthstring 00.00.0000
2332 This will prevent the compiler from passing on the default library path
2335 \labelwidthstring 00.00.0000
2341 Shows the various actions the compiler is performing.
2343 \labelwidthstring 00.00.0000
2349 Shows the actual commands the compiler is executing.
2350 \layout Subsubsection
2352 Intermediate Dump Options
2355 The following options are provided for the purpose of retargetting and debugging
2357 These provided a means to dump the intermediate code (iCode) generated
2358 by the compiler in human readable form at various stages of the compilation
2362 \labelwidthstring 00.00.0000
2368 This option will cause the compiler to dump the intermediate code into
2371 <source filename>.dumpraw
2373 just after the intermediate code has been generated for a function, i.e.
2374 before any optimizations are done.
2375 The basic blocks at this stage ordered in the depth first number, so they
2376 may not be in sequence of execution.
2378 \labelwidthstring 00.00.0000
2384 Will create a dump of iCode's, after global subexpression elimination,
2387 <source filename>.dumpgcse.
2389 \labelwidthstring 00.00.0000
2395 Will create a dump of iCode's, after deadcode elimination, into a file
2398 <source filename>.dumpdeadcode.
2400 \labelwidthstring 00.00.0000
2409 Will create a dump of iCode's, after loop optimizations, into a file named
2412 <source filename>.dumploop.
2414 \labelwidthstring 00.00.0000
2423 Will create a dump of iCode's, after live range analysis, into a file named
2426 <source filename>.dumprange.
2428 \labelwidthstring 00.00.0000
2434 Will dump the life ranges for all symbols.
2436 \labelwidthstring 00.00.0000
2445 Will create a dump of iCode's, after register assignment, into a file named
2448 <source filename>.dumprassgn.
2450 \labelwidthstring 00.00.0000
2456 Will create a dump of the live ranges of iTemp's
2458 \labelwidthstring 00.00.0000
2469 Will cause all the above mentioned dumps to be created.
2472 MCS51/DS390 Storage Class Language Extensions
2475 In addition to the ANSI storage classes SDCC allows the following MCS51
2476 specific storage classes.
2477 \layout Subsubsection
2482 Variables declared with this storage class will be placed in the extern
2488 storage class for Large Memory model, e.g.:
2494 xdata unsigned char xduc;
2495 \layout Subsubsection
2504 storage class for Small Memory model.
2505 Variables declared with this storage class will be allocated in the internal
2513 \layout Subsubsection
2518 Variables declared with this storage class will be allocated into the indirectly
2519 addressable portion of the internal ram of a 8051, e.g.:
2526 \layout Subsubsection
2531 This is a data-type and a storage class specifier.
2532 When a variable is declared as a bit, it is allocated into the bit addressable
2533 memory of 8051, e.g.:
2540 \layout Subsubsection
2545 Like the bit keyword,
2549 signifies both a data-type and storage class, they are used to describe
2550 the special function registers and special bit variables of a 8051, eg:
2556 sfr at 0x80 P0; /* special function register P0 at location 0x80 */
2558 sbit at 0xd7 CY; /* CY (Carry Flag) */
2564 SDCC allows (via language extensions) pointers to explicitly point to any
2565 of the memory spaces of the 8051.
2566 In addition to the explicit pointers, the compiler uses (by default) generic
2567 pointers which can be used to point to any of the memory spaces.
2571 Pointer declaration examples:
2580 /* pointer physically in xternal ram pointing to object in internal ram
2583 data unsigned char * xdata p;
2587 /* pointer physically in code rom pointing to data in xdata space */
2589 xdata unsigned char * code p;
2593 /* pointer physically in code space pointing to data in code space */
2595 code unsigned char * code p;
2599 /* the folowing is a generic pointer physically located in xdata space */
2610 Well you get the idea.
2615 All unqualified pointers are treated as 3-byte (4-byte for the ds390)
2628 The highest order byte of the
2632 pointers contains the data space information.
2633 Assembler support routines are called whenever data is stored or retrieved
2639 These are useful for developing reusable library routines.
2640 Explicitly specifying the pointer type will generate the most efficient
2644 Parameters & Local Variables
2647 Automatic (local) variables and parameters to functions can either be placed
2648 on the stack or in data-space.
2649 The default action of the compiler is to place these variables in the internal
2650 RAM (for small model) or external RAM (for large model).
2651 This in fact makes them
2655 so by default functions are non-reentrant.
2659 They can be placed on the stack either by using the
2663 option or by using the
2667 keyword in the function declaration, e.g.:
2676 unsigned char foo(char i) reentrant
2689 Since stack space on 8051 is limited, the
2697 option should be used sparingly.
2698 Note that the reentrant keyword just means that the parameters & local
2699 variables will be allocated to the stack, it
2703 mean that the function is register bank independent.
2707 Local variables can be assigned storage classes and absolute addresses,
2714 unsigned char foo() {
2720 xdata unsigned char i;
2732 data at 0x31 unsiged char j;
2747 In the above example the variable
2751 will be allocated in the external ram,
2755 in bit addressable space and
2764 or when a function is declared as
2768 this should only be done for static variables.
2771 Parameters however are not allowed any storage class, (storage classes for
2772 parameters will be ignored), their allocation is governed by the memory
2773 model in use, and the reentrancy options.
2779 For non-reentrant functions SDCC will try to reduce internal ram space usage
2780 by overlaying parameters and local variables of a function (if possible).
2781 Parameters and local variables of a function will be allocated to an overlayabl
2782 e segment if the function has
2784 no other function calls and the function is non-reentrant and the memory
2788 If an explicit storage class is specified for a local variable, it will
2792 Note that the compiler (not the linkage editor) makes the decision for overlayin
2794 Functions that are called from an interrupt service routine should be preceded
2795 by a #pragma\SpecialChar ~
2796 NOOVERLAY if they are not reentrant.
2799 Also note that the compiler does not do any processing of inline assembler
2800 code, so the compiler might incorrectly assign local variables and parameters
2801 of a function into the overlay segment if the inline assembler code calls
2802 other c-functions that might use the overlay.
2803 In that case the #pragma\SpecialChar ~
2804 NOOVERLAY should be used.
2807 Parameters and Local variables of functions that contain 16 or 32 bit multiplica
2808 tion or division will NOT be overlayed since these are implemented using
2809 external functions, e.g.:
2819 void set_error(unsigned char errcd)
2835 void some_isr () interrupt 2 using 1
2864 In the above example the parameter
2872 would be assigned to the overlayable segment if the #pragma\SpecialChar ~
2874 not present, this could cause unpredictable runtime behavior when called
2876 The #pragma\SpecialChar ~
2877 NOOVERLAY ensures that the parameters and local variables for
2878 the function are NOT overlayed.
2881 Interrupt Service Routines
2884 SDCC allows interrupt service routines to be coded in C, with some extended
2891 void timer_isr (void) interrupt 2 using 1
2904 The number following the
2908 keyword is the interrupt number this routine will service.
2909 The compiler will insert a call to this routine in the interrupt vector
2910 table for the interrupt number specified.
2915 keyword is used to tell the compiler to use the specified register bank
2916 (8051 specific) when generating code for this function.
2917 Note that when some function is called from an interrupt service routine
2918 it should be preceded by a #pragma\SpecialChar ~
2919 NOOVERLAY if it is not reentrant.
2920 A special note here, int (16 bit) and long (32 bit) integer division, multiplic
2921 ation & modulus operations are implemented using external support routines
2922 developed in ANSI-C, if an interrupt service routine needs to do any of
2923 these operations then the support routines (as mentioned in a following
2924 section) will have to be recompiled using the
2928 option and the source file will need to be compiled using the
2935 If you have multiple source files in your project, interrupt service routines
2936 can be present in any of them, but a prototype of the isr MUST be present
2937 or included in the file that contains the function
2944 Interrupt Numbers and the corresponding address & descriptions for the Standard
2945 8051 are listed below.
2946 SDCC will automatically adjust the interrupt vector table to the maximum
2947 interrupt number specified.
2953 \begin_inset Tabular
2954 <lyxtabular version="3" rows="6" columns="3">
2956 <column alignment="center" valignment="top" leftline="true" width="0(null)">
2957 <column alignment="center" valignment="top" leftline="true" width="0(null)">
2958 <column alignment="center" valignment="top" leftline="true" rightline="true" width="0(null)">
2959 <row topline="true" bottomline="true">
2960 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
2968 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
2976 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
2985 <row topline="true">
2986 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
2994 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3002 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
3011 <row topline="true">
3012 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3020 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3028 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
3037 <row topline="true">
3038 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3046 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3054 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
3063 <row topline="true">
3064 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3072 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3080 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
3089 <row topline="true" bottomline="true">
3090 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3098 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3106 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
3123 If the interrupt service routine is defined without
3127 a register bank or with register bank 0 (using 0), the compiler will save
3128 the registers used by itself on the stack upon entry and restore them at
3129 exit, however if such an interrupt service routine calls another function
3130 then the entire register bank will be saved on the stack.
3131 This scheme may be advantageous for small interrupt service routines which
3132 have low register usage.
3135 If the interrupt service routine is defined to be using a specific register
3140 are save and restored, if such an interrupt service routine calls another
3141 function (using another register bank) then the entire register bank of
3142 the called function will be saved on the stack.
3143 This scheme is recommended for larger interrupt service routines.
3146 Calling other functions from an interrupt service routine is not recommended,
3147 avoid it if possible.
3151 Also see the _naked modifier.
3159 <TODO: this isn't implemented at all!>
3165 A special keyword may be associated with a function declaring it as
3170 SDCC will generate code to disable all interrupts upon entry to a critical
3171 function and enable them back before returning.
3172 Note that nesting critical functions may cause unpredictable results.
3197 The critical attribute maybe used with other attributes like
3205 A special keyword may be associated with a function declaring it as
3214 function modifier attribute prevents the compiler from generating prologue
3215 and epilogue code for that function.
3216 This means that the user is entirely responsible for such things as saving
3217 any registers that may need to be preserved, selecting the proper register
3218 bank, generating the
3222 instruction at the end, etc.
3223 Practically, this means that the contents of the function must be written
3224 in inline assembler.
3225 This is particularly useful for interrupt functions, which can have a large
3226 (and often unnecessary) prologue/epilogue.
3227 For example, compare the code generated by these two functions:
3233 data unsigned char counter;
3235 void simpleInterrupt(void) interrupt 1
3249 void nakedInterrupt(void) interrupt 2 _naked
3282 ; MUST explicitly include ret in _naked function.
3296 For an 8051 target, the generated simpleInterrupt looks like:
3441 whereas nakedInterrupt looks like:
3466 ; MUST explicitly include ret(i) in _naked function.
3472 While there is nothing preventing you from writing C code inside a _naked
3473 function, there are many ways to shoot yourself in the foot doing this,
3474 and it is recommended that you stick to inline assembler.
3477 Functions using private banks
3484 attribute (which tells the compiler to use a register bank other than the
3485 default bank zero) should only be applied to
3489 functions (see note 1 below).
3490 This will in most circumstances make the generated ISR code more efficient
3491 since it will not have to save registers on the stack.
3498 attribute will have no effect on the generated code for a
3502 function (but may occasionally be useful anyway
3508 possible exception: if a function is called ONLY from 'interrupt' functions
3509 using a particular bank, it can be declared with the same 'using' attribute
3510 as the calling 'interrupt' functions.
3511 For instance, if you have several ISRs using bank one, and all of them
3512 call memcpy(), it might make sense to create a specialized version of memcpy()
3513 'using 1', since this would prevent the ISR from having to save bank zero
3514 to the stack on entry and switch to bank zero before calling the function
3521 (pending: I don't think this has been done yet)
3528 function using a non-zero bank will assume that it can trash that register
3529 bank, and will not save it.
3530 Since high-priority interrupts can interrupt low-priority ones on the 8051
3531 and friends, this means that if a high-priority ISR
3535 a particular bank occurs while processing a low-priority ISR
3539 the same bank, terrible and bad things can happen.
3540 To prevent this, no single register bank should be
3544 by both a high priority and a low priority ISR.
3545 This is probably most easily done by having all high priority ISRs use
3546 one bank and all low priority ISRs use another.
3547 If you have an ISR which can change priority at runtime, you're on your
3548 own: I suggest using the default bank zero and taking the small performance
3552 It is most efficient if your ISR calls no other functions.
3553 If your ISR must call other functions, it is most efficient if those functions
3554 use the same bank as the ISR (see note 1 below); the next best is if the
3555 called functions use bank zero.
3556 It is very inefficient to call a function using a different, non-zero bank
3564 Data items can be assigned an absolute address with the
3568 keyword, in addition to a storage class, e.g.:
3574 xdata at 0x8000 unsigned char PORTA_8255 ;
3580 In the above example the PORTA_8255 will be allocated to the location 0x8000
3581 of the external ram.
3582 Note that this feature is provided to give the programmer access to
3586 devices attached to the controller.
3587 The compiler does not actually reserve any space for variables declared
3588 in this way (they are implemented with an equate in the assembler).
3589 Thus it is left to the programmer to make sure there are no overlaps with
3590 other variables that are declared without the absolute address.
3591 The assembler listing file (.lst) and the linker output files (.rst) and
3592 (.map) are a good places to look for such overlaps.
3596 Absolute address can be specified for variables in all storage classes,
3609 The above example will allocate the variable at offset 0x02 in the bit-addressab
3611 There is no real advantage to assigning absolute addresses to variables
3612 in this manner, unless you want strict control over all the variables allocated.
3618 The compiler inserts a call to the C routine
3620 _sdcc__external__startup()
3625 at the start of the CODE area.
3626 This routine is in the runtime library.
3627 By default this routine returns 0, if this routine returns a non-zero value,
3628 the static & global variable initialization will be skipped and the function
3629 main will be invoked Other wise static & global variables will be initialized
3630 before the function main is invoked.
3633 _sdcc__external__startup()
3635 routine to your program to override the default if you need to setup hardware
3636 or perform some other critical operation prior to static & global variable
3640 Inline Assembler Code
3643 SDCC allows the use of in-line assembler with a few restriction as regards
3645 All labels defined within inline assembler code
3653 where nnnn is a number less than 100 (which implies a limit of utmost 100
3654 inline assembler labels
3662 It is strongly recommended that each assembly instruction (including labels)
3663 be placed in a separate line (as the example shows).
3668 command line option is used, the inline assembler code will be passed through
3669 the peephole optimizer.
3670 This might cause some unexpected changes in the inline assembler code.
3671 Please go throught the peephole optimizer rules defined in file
3675 carefully before using this option.
3715 The inline assembler code can contain any valid code understood by the assembler
3716 , this includes any assembler directives and comment lines.
3717 The compiler does not do any validation of the code within the
3727 Inline assembler code cannot reference any C-Labels, however it can reference
3728 labels defined by the inline assembler, e.g.:
3754 ; some assembler code
3774 /* some more c code */
3776 clabel:\SpecialChar ~
3778 /* inline assembler cannot reference this label */
3790 $0003: ;label (can be reference by inline assembler only)
3802 /* some more c code */
3810 In other words inline assembly code can access labels defined in inline
3811 assembly within the scope of the funtion.
3815 The same goes the other way, ie.
3816 labels defines in inline assembly CANNOT be accessed by C statements.
3819 int(16 bit) and long (32 bit) Support
3822 For signed & unsigned int (16 bit) and long (32 bit) variables, division,
3823 multiplication and modulus operations are implemented by support routines.
3824 These support routines are all developed in ANSI-C to facilitate porting
3825 to other MCUs, although some model specific assembler optimations are used.
3826 The following files contain the described routine, all of them can be found
3827 in <installdir>/share/sdcc/lib.
3833 <pending: tabularise this>
3839 _mulsint.c - signed 16 bit multiplication (calls _muluint)
3841 _muluint.c - unsigned 16 bit multiplication
3843 _divsint.c - signed 16 bit division (calls _divuint)
3845 _divuint.c - unsigned 16 bit division
3847 _modsint.c - signed 16 bit modulus (call _moduint)
3849 _moduint.c - unsigned 16 bit modulus
3851 _mulslong.c - signed 32 bit multiplication (calls _mululong)
3853 _mululong.c - unsigned32 bit multiplication
3855 _divslong.c - signed 32 division (calls _divulong)
3857 _divulong.c - unsigned 32 division
3859 _modslong.c - signed 32 bit modulus (calls _modulong)
3861 _modulong.c - unsigned 32 bit modulus
3869 Since they are compiled as
3873 , interrupt service routines should not do any of the above operations.
3874 If this is unavoidable then the above routines will need to be compiled
3879 option, after which the source program will have to be compiled with
3886 Floating Point Support
3889 SDCC supports IEEE (single precision 4bytes) floating point numbers.The floating
3890 point support routines are derived from gcc's floatlib.c and consists of
3891 the following routines:
3897 <pending: tabularise this>
3903 _fsadd.c - add floating point numbers
3905 _fssub.c - subtract floating point numbers
3907 _fsdiv.c - divide floating point numbers
3909 _fsmul.c - multiply floating point numbers
3911 _fs2uchar.c - convert floating point to unsigned char
3913 _fs2char.c - convert floating point to signed char
3915 _fs2uint.c - convert floating point to unsigned int
3917 _fs2int.c - convert floating point to signed int
3919 _fs2ulong.c - convert floating point to unsigned long
3921 _fs2long.c - convert floating point to signed long
3923 _uchar2fs.c - convert unsigned char to floating point
3925 _char2fs.c - convert char to floating point number
3927 _uint2fs.c - convert unsigned int to floating point
3929 _int2fs.c - convert int to floating point numbers
3931 _ulong2fs.c - convert unsigned long to floating point number
3933 _long2fs.c - convert long to floating point number
3941 Note if all these routines are used simultaneously the data space might
3943 For serious floating point usage it is strongly recommended that the large
3950 SDCC allows two memory models for MCS51 code, small and large.
3951 Modules compiled with different memory models should
3955 be combined together or the results would be unpredictable.
3956 The library routines supplied with the compiler are compiled as both small
3958 The compiled library modules are contained in seperate directories as small
3959 and large so that you can link to either set.
3963 When the large model is used all variables declared without a storage class
3964 will be allocated into the external ram, this includes all parameters and
3965 local variables (for non-reentrant functions).
3966 When the small model is used variables without storage class are allocated
3967 in the internal ram.
3970 Judicious usage of the processor specific storage classes and the 'reentrant'
3971 function type will yield much more efficient code, than using the large
3973 Several optimizations are disabled when the program is compiled using the
3974 large model, it is therefore strongly recommdended that the small model
3975 be used unless absolutely required.
3981 The only model supported is Flat 24.
3982 This generates code for the 24 bit contiguous addressing mode of the Dallas
3984 In this mode, up to four meg of external RAM or code space can be directly
3986 See the data sheets at www.dalsemi.com for further information on this part.
3990 In older versions of the compiler, this option was used with the MCS51 code
3996 Now, however, the '390 has it's own code generator, selected by the
4005 Note that the compiler does not generate any code to place the processor
4006 into 24 bitmode (although
4010 in the ds390 libraries will do that for you).
4015 , the boot loader or similar code must ensure that the processor is in 24
4016 bit contiguous addressing mode before calling the SDCC startup code.
4024 option, variables will by default be placed into the XDATA segment.
4029 Segments may be placed anywhere in the 4 meg address space using the usual
4031 Note that if any segments are located above 64K, the -r flag must be passed
4032 to the linker to generate the proper segment relocations, and the Intel
4033 HEX output format must be used.
4034 The -r flag can be passed to the linker by using the option
4038 on the sdcc command line.
4039 However, currently the linker can not handle code segments > 64k.
4042 Defines Created by the Compiler
4045 The compiler creates the following #defines.
4048 SDCC - this Symbol is always defined.
4051 SDCC_mcs51 or SDCC_ds390 or SDCC_z80, etc - depending on the model used
4055 __mcs51 or __ds390 or __z80, etc - depending on the model used (e.g.
4059 SDCC_STACK_AUTO - this symbol is defined when
4066 SDCC_MODEL_SMALL - when
4073 SDCC_MODEL_LARGE - when
4080 SDCC_USE_XSTACK - when
4087 SDCC_STACK_TENBIT - when
4094 SDCC_MODEL_FLAT24 - when
4107 SDCC performs a host of standard optimizations in addition to some MCU specific
4110 \layout Subsubsection
4112 Sub-expression Elimination
4115 The compiler does local and global common subexpression elimination, e.g.:
4130 will be translated to
4146 Some subexpressions are not as obvious as the above example, e.g.:
4160 In this case the address arithmetic a->b[i] will be computed only once;
4161 the equivalent code in C would be.
4177 The compiler will try to keep these temporary variables in registers.
4178 \layout Subsubsection
4180 Dead-Code Elimination
4195 i = 1; \SpecialChar ~
4200 global = 1;\SpecialChar ~
4213 global = 3;\SpecialChar ~
4228 int global; void f ()
4241 \layout Subsubsection
4302 Note: the dead stores created by this copy propagation will be eliminated
4303 by dead-code elimination.
4304 \layout Subsubsection
4309 Two types of loop optimizations are done by SDCC loop invariant lifting
4310 and strength reduction of loop induction variables.
4311 In addition to the strength reduction the optimizer marks the induction
4312 variables and the register allocator tries to keep the induction variables
4313 in registers for the duration of the loop.
4314 Because of this preference of the register allocator, loop induction optimizati
4315 on causes an increase in register pressure, which may cause unwanted spilling
4316 of other temporary variables into the stack / data space.
4317 The compiler will generate a warning message when it is forced to allocate
4318 extra space either on the stack or data space.
4319 If this extra space allocation is undesirable then induction optimization
4320 can be eliminated either for the entire source file (with ---noinduction
4321 option) or for a given function only using #pragma\SpecialChar ~
4332 for (i = 0 ; i < 100 ; i ++)
4350 for (i = 0; i < 100; i++)
4360 As mentioned previously some loop invariants are not as apparent, all static
4361 address computations are also moved out of the loop.
4365 Strength Reduction, this optimization substitutes an expression by a cheaper
4372 for (i=0;i < 100; i++)
4392 for (i=0;i< 100;i++) {
4396 ar[itemp1] = itemp2;
4412 The more expensive multiplication is changed to a less expensive addition.
4413 \layout Subsubsection
4418 This optimization is done to reduce the overhead of checking loop boundaries
4419 for every iteration.
4420 Some simple loops can be reversed and implemented using a
4421 \begin_inset Quotes eld
4424 decrement and jump if not zero
4425 \begin_inset Quotes erd
4429 SDCC checks for the following criterion to determine if a loop is reversible
4430 (note: more sophisticated compilers use data-dependency analysis to make
4431 this determination, SDCC uses a more simple minded analysis).
4434 The 'for' loop is of the form
4440 for (<symbol> = <expression> ; <sym> [< | <=] <expression> ; [<sym>++ |
4450 The <for body> does not contain
4451 \begin_inset Quotes eld
4455 \begin_inset Quotes erd
4459 \begin_inset Quotes erd
4465 All goto's are contained within the loop.
4468 No function calls within the loop.
4471 The loop control variable <sym> is not assigned any value within the loop
4474 The loop control variable does NOT participate in any arithmetic operation
4478 There are NO switch statements in the loop.
4479 \layout Subsubsection
4481 Algebraic Simplifications
4484 SDCC does numerous algebraic simplifications, the following is a small sub-set
4485 of these optimizations.
4491 i = j + 0 ; /* changed to */ i = j;
4493 i /= 2; /* changed to */ i >>= 1;
4495 i = j - j ; /* changed to */ i = 0;
4497 i = j / 1 ; /* changed to */ i = j;
4503 Note the subexpressions given above are generally introduced by macro expansions
4504 or as a result of copy/constant propagation.
4505 \layout Subsubsection
4510 SDCC changes switch statements to jump tables when the following conditions
4515 The case labels are in numerical sequence, the labels need not be in order,
4516 and the starting number need not be one or zero.
4522 switch(i) {\SpecialChar ~
4629 Both the above switch statements will be implemented using a jump-table.
4632 The number of case labels is at least three, since it takes two conditional
4633 statements to handle the boundary conditions.
4636 The number of case labels is less than 84, since each label takes 3 bytes
4637 and a jump-table can be utmost 256 bytes long.
4641 Switch statements which have gaps in the numeric sequence or those that
4642 have more that 84 case labels can be split into more than one switch statement
4643 for efficient code generation, e.g.:
4681 If the above switch statement is broken down into two switch statements
4715 case 9: \SpecialChar ~
4725 case 12:\SpecialChar ~
4735 then both the switch statements will be implemented using jump-tables whereas
4736 the unmodified switch statement will not be.
4737 \layout Subsubsection
4739 Bit-shifting Operations.
4742 Bit shifting is one of the most frequently used operation in embedded programmin
4744 SDCC tries to implement bit-shift operations in the most efficient way
4764 generates the following code:
4782 In general SDCC will never setup a loop if the shift count is known.
4822 Note that SDCC stores numbers in little-endian format (i.e.
4823 lowest order first).
4824 \layout Subsubsection
4829 A special case of the bit-shift operation is bit rotation, SDCC recognizes
4830 the following expression to be a left bit-rotation:
4841 i = ((i << 1) | (i >> 7));
4849 will generate the following code:
4865 SDCC uses pattern matching on the parse tree to determine this operation.Variatio
4866 ns of this case will also be recognized as bit-rotation, i.e.:
4872 i = ((i >> 7) | (i << 1)); /* left-bit rotation */
4873 \layout Subsubsection
4878 It is frequently required to obtain the highest order bit of an integral
4879 type (long, int, short or char types).
4880 SDCC recognizes the following expression to yield the highest order bit
4881 and generates optimized code for it, e.g.:
4902 hob = (gint >> 15) & 1;
4915 will generate the following code:
4954 000A E5*01\SpecialChar ~
4982 000C 33\SpecialChar ~
5013 000D E4\SpecialChar ~
5044 000E 13\SpecialChar ~
5075 000F F5*02\SpecialChar ~
5105 Variations of this case however will
5110 It is a standard C expression, so I heartily recommend this be the only
5111 way to get the highest order bit, (it is portable).
5112 Of course it will be recognized even if it is embedded in other expressions,
5119 xyz = gint + ((gint >> 15) & 1);
5125 will still be recognized.
5126 \layout Subsubsection
5131 The compiler uses a rule based, pattern matching and re-writing mechanism
5132 for peep-hole optimization.
5137 a peep-hole optimizer by Christopher W.
5138 Fraser (cwfraser@microsoft.com).
5139 A default set of rules are compiled into the compiler, additional rules
5140 may be added with the
5142 ---peep-file <filename>
5145 The rule language is best illustrated with examples.
5173 The above rule will change the following assembly sequence:
5203 Note: All occurrences of a
5207 (pattern variable) must denote the same string.
5208 With the above rule, the assembly sequence:
5226 will remain unmodified.
5230 Other special case optimizations may be added by the user (via
5236 some variants of the 8051 MCU allow only
5245 The following two rules will change all
5267 replace { lcall %1 } by { acall %1 }
5269 replace { ljmp %1 } by { ajmp %1 }
5277 inline-assembler code
5279 is also passed through the peep hole optimizer, thus the peephole optimizer
5280 can also be used as an assembly level macro expander.
5281 The rules themselves are MCU dependent whereas the rule language infra-structur
5282 e is MCU independent.
5283 Peephole optimization rules for other MCU can be easily programmed using
5288 The syntax for a rule is as follows:
5294 rule := replace [ restart ] '{' <assembly sequence> '
5332 <assembly sequence> '
5350 '}' [if <functionName> ] '
5358 <assembly sequence> := assembly instruction (each instruction including
5359 labels must be on a separate line).
5363 The optimizer will apply to the rules one by one from the top in the sequence
5364 of their appearance, it will terminate when all rules are exhausted.
5365 If the 'restart' option is specified, then the optimizer will start matching
5366 the rules again from the top, this option for a rule is expensive (performance)
5367 , it is intended to be used in situations where a transformation will trigger
5368 the same rule again.
5369 An example of this (not a good one, it has side effects) is the following
5396 Note that the replace pattern cannot be a blank, but can be a comment line.
5397 Without the 'restart' option only the inner most 'pop' 'push' pair would
5398 be eliminated, i.e.:
5450 the restart option the rule will be applied again to the resulting code
5451 and then all the pop-push pairs will be eliminated to yield:
5469 A conditional function can be attached to a rule.
5470 Attaching rules are somewhat more involved, let me illustrate this with
5501 The optimizer does a look-up of a function name table defined in function
5506 in the source file SDCCpeeph.c, with the name
5511 If it finds a corresponding entry the function is called.
5512 Note there can be no parameters specified for these functions, in this
5517 is crucial, since the function
5521 expects to find the label in that particular variable (the hash table containin
5522 g the variable bindings is passed as a parameter).
5523 If you want to code more such functions, take a close look at the function
5524 labelInRange and the calling mechanism in source file SDCCpeeph.c.
5525 I know this whole thing is a little kludgey, but maybe some day we will
5526 have some better means.
5527 If you are looking at this file, you will also see the default rules that
5528 are compiled into the compiler, you can add your own rules in the default
5529 set there if you get tired of specifying the ---peep-file option.
5535 SDCC supports the following #pragma directives.
5536 This directives are applicable only at a function level.
5539 SAVE - this will save all the current options.
5542 RESTORE - will restore the saved options from the last save.
5543 Note that SAVES & RESTOREs cannot be nested.
5544 SDCC uses the same buffer to save the options each time a SAVE is called.
5547 NOGCSE - will stop global subexpression elimination.
5550 NOINDUCTION - will stop loop induction optimizations.
5553 NOJTBOUND - will not generate code for boundary value checking, when switch
5554 statements are turned into jump-tables.
5557 NOOVERLAY - the compiler will not overlay the parameters and local variables
5561 NOLOOPREVERSE - Will not do loop reversal optimization
5564 EXCLUDE NONE | {acc[,b[,dpl[,dph]]] - The exclude pragma disables generation
5565 of pair of push/pop instruction in ISR function (using interrupt keyword).
5566 The directive should be placed immediately before the ISR function definition
5567 and it affects ALL ISR functions following it.
5568 To enable the normal register saving for ISR functions use #pragma\SpecialChar ~
5569 EXCLUDE\SpecialChar ~
5573 CALLEE-SAVES function1[,function2[,function3...]] - The compiler by default
5574 uses a caller saves convention for register saving across function calls,
5575 however this can cause unneccessary register pushing & popping when calling
5576 small functions from larger functions.
5577 This option can be used to switch the register saving convention for the
5578 function names specified.
5579 The compiler will not save registers when calling these functions, extra
5580 code will be generated at the entry & exit for these functions to save
5581 & restore the registers used by these functions, this can SUBSTANTIALLY
5582 reduce code & improve run time performance of the generated code.
5583 In future the compiler (with interprocedural analysis) will be able to
5584 determine the appropriate scheme to use for each function call.
5585 If ---callee-saves command line option is used, the function names specified
5586 in #pragma\SpecialChar ~
5587 CALLEE-SAVES is appended to the list of functions specified inthe
5591 The pragma's are intended to be used to turn-off certain optimizations which
5592 might cause the compiler to generate extra stack / data space to store
5593 compiler generated temporary variables.
5594 This usually happens in large functions.
5595 Pragma directives should be used as shown in the following example, they
5596 are used to control options & optimizations for a given function; pragmas
5597 should be placed before and/or after a function, placing pragma's inside
5598 a function body could have unpredictable results.
5604 #pragma SAVE /* save the current settings */
5606 #pragma NOGCSE /* turnoff global subexpression elimination */
5608 #pragma NOINDUCTION /* turn off induction optimizations */
5630 #pragma RESTORE /* turn the optimizations back on */
5636 The compiler will generate a warning message when extra space is allocated.
5637 It is strongly recommended that the SAVE and RESTORE pragma's be used when
5638 changing options for a function.
5643 <pending: this is messy and incomplete>
5648 Compiler support routines (_gptrget, _mulint etc)
5651 Stdclib functions (puts, printf, strcat etc)
5654 Math functions (sin, pow, sqrt etc)
5657 Interfacing with Assembly Routines
5658 \layout Subsubsection
5660 Global Registers used for Parameter Passing
5663 The compiler always uses the global registers
5671 to pass the first parameter to a routine.
5672 The second parameter onwards is either allocated on the stack (for reentrant
5673 routines or if ---stack-auto is used) or in the internal / external ram
5674 (depending on the memory model).
5676 \layout Subsubsection
5678 Assembler Routine(non-reentrant)
5681 In the following example the function cfunc calls an assembler routine asm_func,
5682 which takes two parameters.
5688 extern int asm_func(unsigned char, unsigned char);
5692 int c_func (unsigned char i, unsigned char j)
5700 return asm_func(i,j);
5714 return c_func(10,9);
5722 The corresponding assembler function is:
5728 .globl _asm_func_PARM_2
5792 add a,_asm_func_PARM_2
5828 Note here that the return values are placed in 'dpl' - One byte return value,
5829 'dpl' LSB & 'dph' MSB for two byte values.
5830 'dpl', 'dph' and 'b' for three byte values (generic pointers) and 'dpl','dph','
5831 b' & 'acc' for four byte values.
5834 The parameter naming convention is _<function_name>_PARM_<n>, where n is
5835 the parameter number starting from 1, and counting from the left.
5836 The first parameter is passed in
5837 \begin_inset Quotes eld
5841 \begin_inset Quotes erd
5844 for One bye parameter,
5845 \begin_inset Quotes eld
5849 \begin_inset Quotes erd
5853 \begin_inset Quotes eld
5857 \begin_inset Quotes erd
5861 \begin_inset Quotes eld
5865 \begin_inset Quotes erd
5868 for four bytes, the varible name for the second parameter will be _<function_na
5873 Assemble the assembler routine with the following command:
5880 asx8051 -losg asmfunc.asm
5887 Then compile and link the assembler routine to the C source file with the
5895 sdcc cfunc.c asmfunc.rel
5896 \layout Subsubsection
5898 Assembler Routine(reentrant)
5901 In this case the second parameter onwards will be passed on the stack, the
5902 parameters are pushed from right to left i.e.
5903 after the call the left most parameter will be on the top of the stack.
5910 extern int asm_func(unsigned char, unsigned char);
5914 int c_func (unsigned char i, unsigned char j) reentrant
5922 return asm_func(i,j);
5936 return c_func(10,9);
5944 The corresponding assembler routine is:
6054 The compiling and linking procedure remains the same, however note the extra
6055 entry & exit linkage required for the assembler code, _bp is the stack
6056 frame pointer and is used to compute the offset into the stack for parameters
6057 and local variables.
6063 The external stack is located at the start of the external ram segment,
6064 and is 256 bytes in size.
6065 When ---xstack option is used to compile the program, the parameters and
6066 local variables of all reentrant functions are allocated in this area.
6067 This option is provided for programs with large stack space requirements.
6068 When used with the ---stack-auto option, all parameters and local variables
6069 are allocated on the external stack (note support libraries will need to
6070 be recompiled with the same options).
6073 The compiler outputs the higher order address byte of the external ram segment
6074 into PORT P2, therefore when using the External Stack option, this port
6075 MAY NOT be used by the application program.
6081 Deviations from the compliancy.
6084 functions are not always reentrant.
6087 structures cannot be assigned values directly, cannot be passed as function
6088 parameters or assigned to each other and cannot be a return value from
6115 s1 = s2 ; /* is invalid in SDCC although allowed in ANSI */
6126 struct s foo1 (struct s parms) /* is invalid in SDCC although allowed in
6148 return rets;/* is invalid in SDCC although allowed in ANSI */
6153 'long long' (64 bit integers) not supported.
6156 'double' precision floating point not supported.
6159 No support for setjmp and longjmp (for now).
6162 Old K&R style function declarations are NOT allowed.
6168 foo(i,j) /* this old style of function declarations */
6170 int i,j; /* are valid in ANSI but not valid in SDCC */
6184 functions declared as pointers must be dereferenced during the call.
6195 /* has to be called like this */
6197 (*foo)(); /* ansi standard allows calls to be made like 'foo()' */
6200 Cyclomatic Complexity
6203 Cyclomatic complexity of a function is defined as the number of independent
6204 paths the program can take during execution of the function.
6205 This is an important number since it defines the number test cases you
6206 have to generate to validate the function.
6207 The accepted industry standard for complexity number is 10, if the cyclomatic
6208 complexity reported by SDCC exceeds 10 you should think about simplification
6209 of the function logic.
6210 Note that the complexity level is not related to the number of lines of
6212 Large functions can have low complexity, and small functions can have large
6218 SDCC uses the following formula to compute the complexity:
6223 complexity = (number of edges in control flow graph) - (number of nodes
6224 in control flow graph) + 2;
6228 Having said that the industry standard is 10, you should be aware that in
6229 some cases it be may unavoidable to have a complexity level of less than
6231 For example if you have switch statement with more than 10 case labels,
6232 each case label adds one to the complexity level.
6233 The complexity level is by no means an absolute measure of the algorithmic
6234 complexity of the function, it does however provide a good starting point
6235 for which functions you might look at for further optimization.
6241 Here are a few guidelines that will help the compiler generate more efficient
6242 code, some of the tips are specific to this compiler others are generally
6243 good programming practice.
6246 Use the smallest data type to represent your data-value.
6247 If it is known in advance that the value is going to be less than 256 then
6248 use a 'char' instead of a 'short' or 'int'.
6251 Use unsigned when it is known in advance that the value is not going to
6253 This helps especially if you are doing division or multiplication.
6256 NEVER jump into a LOOP.
6259 Declare the variables to be local whenever possible, especially loop control
6260 variables (induction).
6263 Since the compiler does not do implicit integral promotion, the programmer
6264 should do an explicit cast when integral promotion is required.
6267 Reducing the size of division, multiplication & modulus operations can reduce
6268 code size substantially.
6269 Take the following code for example.
6275 foobar(unsigned int p1, unsigned char ch)
6279 unsigned char ch1 = p1 % ch ;
6290 For the modulus operation the variable ch will be promoted to unsigned int
6291 first then the modulus operation will be performed (this will lead to a
6292 call to support routine _moduint()), and the result will be casted to a
6294 If the code is changed to
6300 foobar(unsigned int p1, unsigned char ch)
6304 unsigned char ch1 = (unsigned char)p1 % ch ;
6315 It would substantially reduce the code generated (future versions of the
6316 compiler will be smart enough to detect such optimization oppurtunities).
6319 Notes on MCS51 memory layout
6322 The 8051 family of micro controller have a minimum of 128 bytes of internal
6323 memory which is structured as follows
6327 - Bytes 00-1F - 32 bytes to hold up to 4 banks of the registers R7 to R7
6330 - Bytes 20-2F - 16 bytes to hold 128 bit variables and
6332 - Bytes 30-7F - 60 bytes for general purpose use.
6336 Normally the SDCC compiler will only utilise the first bank of registers,
6337 but it is possible to specify that other banks of registers should be used
6338 in interrupt routines.
6339 By default, the compiler will place the stack after the last bank of used
6341 if the first 2 banks of registers are used, it will position the base of
6342 the internal stack at address 16 (0X10).
6343 This implies that as the stack grows, it will use up the remaining register
6344 banks, and the 16 bytes used by the 128 bit variables, and 60 bytes for
6345 general purpose use.
6348 By default, the compiler uses the 60 general purpose bytes to hold "near
6350 The compiler/optimiser may also declare some Local Variables in this area
6355 If any of the 128 bit variables are used, or near data is being used then
6356 care needs to be taken to ensure that the stack does not grow so much that
6357 it starts to over write either your bit variables or "near data".
6358 There is no runtime checking to prevent this from happening.
6361 The amount of stack being used is affected by the use of the "internal stack"
6362 to save registers before a subroutine call is made (---stack-auto will
6363 declare parameters and local variables on the stack) and the number of
6367 If you detect that the stack is over writing you data, then the following
6369 ---xstack will cause an external stack to be used for saving registers
6370 and (if ---stack-auto is being used) storing parameters and local variables.
6371 However this will produce more code which will be slower to execute.
6375 ---stack-loc will allow you specify the start of the stack, i.e.
6376 you could start it after any data in the general purpose area.
6377 However this may waste the memory not used by the register banks and if
6378 the size of the "near data" increases, it may creep into the bottom of
6382 ---stack-after-data, similar to the ---stack-loc, but it automatically places
6383 the stack after the end of the "near data".
6384 Again this could waste any spare register space.
6387 ---data-loc allows you to specify the start address of the near data.
6388 This could be used to move the "near data" further away from the stack
6389 giving it more room to grow.
6390 This will only work if no bit variables are being used and the stack can
6391 grow to use the bit variable space.
6399 If you find that the stack is over writing your bit variables or "near data"
6400 then the approach which best utilised the internal memory is to position
6401 the "near data" after the last bank of used registers or, if you use bit
6402 variables, after the last bit variable by using the ---data-loc, e.g.
6403 if two register banks are being used and no bit variables, ---data-loc
6404 16, and use the ---stack-after-data option.
6407 If bit variables are being used, another method would be to try and squeeze
6408 the data area in the unused register banks if it will fit, and start the
6409 stack after the last bit variable.
6412 Retargetting for other MCUs.
6415 The issues for retargetting the compiler are far too numerous to be covered
6417 What follows is a brief description of each of the seven phases of the
6418 compiler and its MCU dependency.
6421 Parsing the source and building the annotated parse tree.
6422 This phase is largely MCU independent (except for the language extensions).
6423 Syntax & semantic checks are also done in this phase, along with some initial
6424 optimizations like back patching labels and the pattern matching optimizations
6425 like bit-rotation etc.
6428 The second phase involves generating an intermediate code which can be easy
6429 manipulated during the later phases.
6430 This phase is entirely MCU independent.
6431 The intermediate code generation assumes the target machine has unlimited
6432 number of registers, and designates them with the name iTemp.
6433 The compiler can be made to dump a human readable form of the code generated
6434 by using the ---dumpraw option.
6437 This phase does the bulk of the standard optimizations and is also MCU independe
6439 This phase can be broken down into several sub-phases:
6443 Break down intermediate code (iCode) into basic blocks.
6445 Do control flow & data flow analysis on the basic blocks.
6447 Do local common subexpression elimination, then global subexpression elimination
6449 Dead code elimination
6453 If loop optimizations caused any changes then do 'global subexpression eliminati
6454 on' and 'dead code elimination' again.
6457 This phase determines the live-ranges; by live range I mean those iTemp
6458 variables defined by the compiler that still survive after all the optimization
6460 Live range analysis is essential for register allocation, since these computati
6461 on determines which of these iTemps will be assigned to registers, and for
6465 Phase five is register allocation.
6466 There are two parts to this process.
6470 The first part I call 'register packing' (for lack of a better term).
6471 In this case several MCU specific expression folding is done to reduce
6476 The second part is more MCU independent and deals with allocating registers
6477 to the remaining live ranges.
6478 A lot of MCU specific code does creep into this phase because of the limited
6479 number of index registers available in the 8051.
6482 The Code generation phase is (unhappily), entirely MCU dependent and very
6483 little (if any at all) of this code can be reused for other MCU.
6484 However the scheme for allocating a homogenized assembler operand for each
6485 iCode operand may be reused.
6488 As mentioned in the optimization section the peep-hole optimizer is rule
6489 based system, which can reprogrammed for other MCUs.
6492 SDCDB - Source Level Debugger
6495 SDCC is distributed with a source level debugger.
6496 The debugger uses a command line interface, the command repertoire of the
6497 debugger has been kept as close to gdb (the GNU debugger) as possible.
6498 The configuration and build process is part of the standard compiler installati
6499 on, which also builds and installs the debugger in the target directory
6500 specified during configuration.
6501 The debugger allows you debug BOTH at the C source and at the ASM source
6505 Compiling for Debugging
6510 debug option must be specified for all files for which debug information
6512 The complier generates a .cdb file for each of these files.
6513 The linker updates the .cdb file with the address information.
6514 This .cdb is used by the debugger.
6517 How the Debugger Works
6520 When the ---debug option is specified the compiler generates extra symbol
6521 information some of which are put into the the assembler source and some
6522 are put into the .cdb file, the linker updates the .cdb file with the address
6523 information for the symbols.
6524 The debugger reads the symbolic information generated by the compiler &
6525 the address information generated by the linker.
6526 It uses the SIMULATOR (Daniel's S51) to execute the program, the program
6527 execution is controlled by the debugger.
6528 When a command is issued for the debugger, it translates it into appropriate
6529 commands for the simulator.
6532 Starting the Debugger
6535 The debugger can be started using the following command line.
6536 (Assume the file you are debugging has the file name foo).
6550 The debugger will look for the following files.
6553 foo.c - the source file.
6556 foo.cdb - the debugger symbol information file.
6559 foo.ihx - the intel hex format object file.
6562 Command Line Options.
6565 ---directory=<source file directory> this option can used to specify the
6566 directory search list.
6567 The debugger will look into the directory list specified for source, cdb
6569 The items in the directory list must be separated by ':', e.g.
6570 if the source files can be in the directories /home/src1 and /home/src2,
6571 the ---directory option should be ---directory=/home/src1:/home/src2.
6572 Note there can be no spaces in the option.
6576 -cd <directory> - change to the <directory>.
6579 -fullname - used by GUI front ends.
6582 -cpu <cpu-type> - this argument is passed to the simulator please see the
6583 simulator docs for details.
6586 -X <Clock frequency > this options is passed to the simulator please see
6587 the simulator docs for details.
6590 -s <serial port file> passed to simulator see the simulator docs for details.
6593 -S <serial in,out> passed to simulator see the simulator docs for details.
6599 As mention earlier the command interface for the debugger has been deliberately
6600 kept as close the GNU debugger gdb, as possible.
6601 This will help the integration with existing graphical user interfaces
6602 (like ddd, xxgdb or xemacs) existing for the GNU debugger.
6603 \layout Subsubsection
6605 break [line | file:line | function | file:function]
6608 Set breakpoint at specified line or function:
6617 sdcdb>break foo.c:100
6621 sdcdb>break foo.c:funcfoo
6622 \layout Subsubsection
6624 clear [line | file:line | function | file:function ]
6627 Clear breakpoint at specified line or function:
6636 sdcdb>clear foo.c:100
6640 sdcdb>clear foo.c:funcfoo
6641 \layout Subsubsection
6646 Continue program being debugged, after breakpoint.
6647 \layout Subsubsection
6652 Execute till the end of the current function.
6653 \layout Subsubsection
6658 Delete breakpoint number 'n'.
6659 If used without any option clear ALL user defined break points.
6660 \layout Subsubsection
6662 info [break | stack | frame | registers ]
6665 info break - list all breakpoints
6668 info stack - show the function call stack.
6671 info frame - show information about the current execution frame.
6674 info registers - show content of all registers.
6675 \layout Subsubsection
6680 Step program until it reaches a different source line.
6681 \layout Subsubsection
6686 Step program, proceeding through subroutine calls.
6687 \layout Subsubsection
6692 Start debugged program.
6693 \layout Subsubsection
6698 Print type information of the variable.
6699 \layout Subsubsection
6704 print value of variable.
6705 \layout Subsubsection
6710 load the given file name.
6711 Note this is an alternate method of loading file for debugging.
6712 \layout Subsubsection
6717 print information about current frame.
6718 \layout Subsubsection
6723 Toggle between C source & assembly source.
6724 \layout Subsubsection
6729 Send the string following '!' to the simulator, the simulator response is
6731 Note the debugger does not interpret the command being sent to the simulator,
6732 so if a command like 'go' is sent the debugger can loose its execution
6733 context and may display incorrect values.
6734 \layout Subsubsection
6741 My name is Bobby Brown"
6744 Interfacing with XEmacs.
6747 Two files (in emacs lisp) are provided for the interfacing with XEmacs,
6748 sdcdb.el and sdcdbsrc.el.
6749 These two files can be found in the $(prefix)/bin directory after the installat
6751 These files need to be loaded into XEmacs for the interface to work.
6752 This can be done at XEmacs startup time by inserting the following into
6753 your '.xemacs' file (which can be found in your HOME directory):
6759 (load-file sdcdbsrc.el)
6765 .xemacs is a lisp file so the () around the command is REQUIRED.
6766 The files can also be loaded dynamically while XEmacs is running, set the
6767 environment variable 'EMACSLOADPATH' to the installation bin directory
6768 (<installdir>/bin), then enter the following command ESC-x load-file sdcdbsrc.
6769 To start the interface enter the following command:
6783 You will prompted to enter the file name to be debugged.
6788 The command line options that are passed to the simulator directly are bound
6789 to default values in the file sdcdbsrc.el.
6790 The variables are listed below, these values maybe changed as required.
6793 sdcdbsrc-cpu-type '51
6796 sdcdbsrc-frequency '11059200
6802 The following is a list of key mapping for the debugger interface.
6810 ;; Current Listing ::
6827 binding\SpecialChar ~
6866 ------\SpecialChar ~
6906 sdcdb-next-from-src\SpecialChar ~
6932 sdcdb-back-from-src\SpecialChar ~
6958 sdcdb-cont-from-src\SpecialChar ~
6968 SDCDB continue command
6984 sdcdb-step-from-src\SpecialChar ~
7010 sdcdb-whatis-c-sexp\SpecialChar ~
7020 SDCDB ptypecommand for data at
7084 sdcdbsrc-delete\SpecialChar ~
7098 SDCDB Delete all breakpoints if no arg
7146 given or delete arg (C-u arg x)
7162 sdcdbsrc-frame\SpecialChar ~
7177 SDCDB Display current frame if no arg,
7226 given or display frame arg
7291 sdcdbsrc-goto-sdcdb\SpecialChar ~
7301 Goto the SDCDB output buffer
7317 sdcdb-print-c-sexp\SpecialChar ~
7328 SDCDB print command for data at
7392 sdcdbsrc-goto-sdcdb\SpecialChar ~
7402 Goto the SDCDB output buffer
7418 sdcdbsrc-mode\SpecialChar ~
7434 Toggles Sdcdbsrc mode (turns it off)
7438 ;; C-c C-f\SpecialChar ~
7446 sdcdb-finish-from-src\SpecialChar ~
7454 SDCDB finish command
7458 ;; C-x SPC\SpecialChar ~
7466 sdcdb-break\SpecialChar ~
7484 Set break for line with point
7486 ;; ESC t\SpecialChar ~
7496 sdcdbsrc-mode\SpecialChar ~
7512 Toggle Sdcdbsrc mode
7514 ;; ESC m\SpecialChar ~
7524 sdcdbsrc-srcmode\SpecialChar ~
7548 The Z80 and gbz80 port
7551 SDCC can target both the Zilog Z80 and the Nintendo Gameboy's Z80-like gbz80.
7552 The port is incomplete - long support is incomplete (mul, div and mod are
7553 unimplimented), and both float and bitfield support is missing.
7554 Apart from that the code generated is correct.
7557 As always, the code is the authoritave reference - see z80/ralloc.c and z80/gen.c.
7558 The stack frame is similar to that generated by the IAR Z80 compiler.
7559 IX is used as the base pointer, HL is used as a temporary register, and
7560 BC and DE are available for holding varibles.
7561 IY is currently unusued.
7562 Return values are stored in HL.
7563 One bad side effect of using IX as the base pointer is that a functions
7564 stack frame is limited to 127 bytes - this will be fixed in a later version.
7570 SDCC has grown to be a large project.
7571 The compiler alone (without the preprocessor, assembler and linker) is
7572 about 40,000 lines of code (blank stripped).
7573 The open source nature of this project is a key to its continued growth
7575 You gain the benefit and support of many active software developers and
7577 Is SDCC perfect? No, that's why we need your help.
7578 The developers take pride in fixing reported bugs.
7579 You can help by reporting the bugs and helping other SDCC users.
7580 There are lots of ways to contribute, and we encourage you to take part
7581 in making SDCC a great software package.
7587 Send an email to the mailing list at 'user-sdcc@sdcc.sourceforge.net' or 'devel-sd
7588 cc@sdcc.sourceforge.net'.
7589 Bugs will be fixed ASAP.
7590 When reporting a bug, it is very useful to include a small test program
7591 which reproduces the problem.
7592 If you can isolate the problem by looking at the generated assembly code,
7593 this can be very helpful.
7594 Compiling your program with the ---dumpall option can sometimes be useful
7595 in locating optimization problems.
7598 The anatomy of the compiler
7603 This is an excerpt from an atricle published in Circuit Cellar MagaZine
7605 It's a little outdated (the compiler is much more efficient now and user/devell
7606 oper friendly), but pretty well exposes the guts of it all.
7612 The current version of SDCC can generate code for Intel 8051 and Z80 MCU.
7613 It is fairly easy to retarget for other 8-bit MCU.
7614 Here we take a look at some of the internals of the compiler.
7621 Parsing the input source file and creating an AST (Annotated Syntax Tree).
7622 This phase also involves propagating types (annotating each node of the
7623 parse tree with type information) and semantic analysis.
7624 There are some MCU specific parsing rules.
7625 For example the storage classes, the extended storage classes are MCU specific
7626 while there may be a xdata storage class for 8051 there is no such storage
7627 class for z80 or Atmel AVR.
7628 SDCC allows MCU specific storage class extensions, i.e.
7629 xdata will be treated as a storage class specifier when parsing 8051 C
7630 code but will be treated as a C identifier when parsing z80 or ATMEL AVR
7637 Intermediate code generation.
7638 In this phase the AST is broken down into three-operand form (iCode).
7639 These three operand forms are represented as doubly linked lists.
7640 ICode is the term given to the intermediate form generated by the compiler.
7641 ICode example section shows some examples of iCode generated for some simple
7648 Bulk of the target independent optimizations is performed in this phase.
7649 The optimizations include constant propagation, common sub-expression eliminati
7650 on, loop invariant code movement, strength reduction of loop induction variables
7651 and dead-code elimination.
7657 During intermediate code generation phase, the compiler assumes the target
7658 machine has infinite number of registers and generates a lot of temporary
7660 The live range computation determines the lifetime of each of these compiler-ge
7661 nerated temporaries.
7662 A picture speaks a thousand words.
7663 ICode example sections show the live range annotations for each of the
7665 It is important to note here, each iCode is assigned a number in the order
7666 of its execution in the function.
7667 The live ranges are computed in terms of these numbers.
7668 The from number is the number of the iCode which first defines the operand
7669 and the to number signifies the iCode which uses this operand last.
7675 The register allocation determines the type and number of registers needed
7677 In most MCUs only a few registers can be used for indirect addressing.
7678 In case of 8051 for example the registers R0 & R1 can be used to indirectly
7679 address the internal ram and DPTR to indirectly address the external ram.
7680 The compiler will try to allocate the appropriate register to pointer variables
7682 ICode example section shows the operands annotated with the registers assigned
7684 The compiler will try to keep operands in registers as much as possible;
7685 there are several schemes the compiler uses to do achieve this.
7686 When the compiler runs out of registers the compiler will check to see
7687 if there are any live operands which is not used or defined in the current
7688 basic block being processed, if there are any found then it will push that
7689 operand and use the registers in this block, the operand will then be popped
7690 at the end of the basic block.
7694 There are other MCU specific considerations in this phase.
7695 Some MCUs have an accumulator; very short-lived operands could be assigned
7696 to the accumulator instead of general-purpose register.
7702 Figure II gives a table of iCode operations supported by the compiler.
7703 The code generation involves translating these operations into corresponding
7704 assembly code for the processor.
7705 This sounds overly simple but that is the essence of code generation.
7706 Some of the iCode operations are generated on a MCU specific manner for
7707 example, the z80 port does not use registers to pass parameters so the
7708 SEND and RECV iCode operations will not be generated, and it also does
7709 not support JUMPTABLES.
7716 <Where is Figure II ?>
7722 This section shows some details of iCode.
7723 The example C code does not do anything useful; it is used as an example
7724 to illustrate the intermediate code generated by the compiler.
7737 /* This function does nothing useful.
7744 for the purpose of explaining iCode */
7747 short function (data int *x)
7755 short i=10; /* dead initialization eliminated */
7760 short sum=10; /* dead initialization eliminated */
7773 while (*x) *x++ = *p++;
7787 /* compiler detects i,j to be induction variables */
7791 for (i = 0, j = 10 ; i < 10 ; i++, j---) {
7803 mul += i * 3; /* this multiplication remains */
7809 gint += j * 3;/* this multiplication changed to addition */
7826 In addition to the operands each iCode contains information about the filename
7827 and line it corresponds to in the source file.
7828 The first field in the listing should be interpreted as follows:
7833 Filename(linenumber: iCode Execution sequence number : ICode hash table
7834 key : loop depth of the iCode).
7839 Then follows the human readable form of the ICode operation.
7840 Each operand of this triplet form can be of three basic types a) compiler
7841 generated temporary b) user defined variable c) a constant value.
7842 Note that local variables and parameters are replaced by compiler generated
7844 Live ranges are computed only for temporaries (i.e.
7845 live ranges are not computed for global variables).
7846 Registers are allocated for temporaries only.
7847 Operands are formatted in the following manner:
7852 Operand Name [lr live-from : live-to ] { type information } [ registers
7858 As mentioned earlier the live ranges are computed in terms of the execution
7859 sequence number of the iCodes, for example
7861 the iTemp0 is live from (i.e.
7862 first defined in iCode with execution sequence number 3, and is last used
7863 in the iCode with sequence number 5).
7864 For induction variables such as iTemp21 the live range computation extends
7865 the lifetime from the start to the end of the loop.
7867 The register allocator used the live range information to allocate registers,
7868 the same registers may be used for different temporaries if their live
7869 ranges do not overlap, for example r0 is allocated to both iTemp6 and to
7870 iTemp17 since their live ranges do not overlap.
7871 In addition the allocator also takes into consideration the type and usage
7872 of a temporary, for example itemp6 is a pointer to near space and is used
7873 as to fetch data from (i.e.
7874 used in GET_VALUE_AT_ADDRESS) so it is allocated a pointer registers (r0).
7875 Some short lived temporaries are allocated to special registers which have
7876 meaning to the code generator e.g.
7877 iTemp13 is allocated to a pseudo register CC which tells the back end that
7878 the temporary is used only for a conditional jump the code generation makes
7879 use of this information to optimize a compare and jump ICode.
7881 There are several loop optimizations performed by the compiler.
7882 It can detect induction variables iTemp21(i) and iTemp23(j).
7883 Also note the compiler does selective strength reduction, i.e.
7884 the multiplication of an induction variable in line 18 (gint = j * 3) is
7885 changed to addition, a new temporary iTemp17 is allocated and assigned
7886 a initial value, a constant 3 is then added for each iteration of the loop.
7887 The compiler does not change the multiplication in line 17 however since
7888 the processor does support an 8 * 8 bit multiplication.
7890 Note the dead code elimination optimization eliminated the dead assignments
7891 in line 7 & 8 to I and sum respectively.
7898 Sample.c (5:1:0:0) _entry($9) :
7903 Sample.c(5:2:1:0) proc _function [lr0:0]{function short}
7908 Sample.c(11:3:2:0) iTemp0 [lr3:5]{_near * int}[r2] = recv
7913 Sample.c(11:4:53:0) preHeaderLbl0($11) :
7918 Sample.c(11:5:55:0) iTemp6 [lr5:16]{_near * int}[r0] := iTemp0 [lr3:5]{_near
7924 Sample.c(11:6:5:1) _whilecontinue_0($1) :
7929 Sample.c(11:7:7:1) iTemp4 [lr7:8]{int}[r2 r3] = @[iTemp6 [lr5:16]{_near *
7935 Sample.c(11:8:8:1) if iTemp4 [lr7:8]{int}[r2 r3] == 0 goto _whilebreak_0($3)
7940 Sample.c(11:9:14:1) iTemp7 [lr9:13]{_far * int}[DPTR] := _p [lr0:0]{_far
7946 Sample.c(11:10:15:1) _p [lr0:0]{_far * int} = _p [lr0:0]{_far * int} + 0x2
7952 Sample.c(11:13:18:1) iTemp10 [lr13:14]{int}[r2 r3] = @[iTemp7 [lr9:13]{_far
7958 Sample.c(11:14:19:1) *(iTemp6 [lr5:16]{_near * int}[r0]) := iTemp10 [lr13:14]{int
7964 Sample.c(11:15:12:1) iTemp6 [lr5:16]{_near * int}[r0] = iTemp6 [lr5:16]{_near
7975 Sample.c(11:16:20:1) goto _whilecontinue_0($1)
7980 Sample.c(11:17:21:0)_whilebreak_0($3) :
7985 Sample.c(12:18:22:0) iTemp2 [lr18:40]{short}[r2] := 0x0 {short}
7990 Sample.c(13:19:23:0) iTemp11 [lr19:40]{short}[r3] := 0x0 {short}
7995 Sample.c(15:20:54:0)preHeaderLbl1($13) :
8000 Sample.c(15:21:56:0) iTemp21 [lr21:38]{short}[r4] := 0x0 {short}
8005 Sample.c(15:22:57:0) iTemp23 [lr22:38]{int}[r5 r6] := 0xa {int}
8010 Sample.c(15:23:58:0) iTemp17 [lr23:38]{int}[r7 r0] := 0x1e {int}
8015 Sample.c(15:24:26:1)_forcond_0($4) :
8020 Sample.c(15:25:27:1) iTemp13 [lr25:26]{char}[CC] = iTemp21 [lr21:38]{short}[r4]
8026 Sample.c(15:26:28:1) if iTemp13 [lr25:26]{char}[CC] == 0 goto _forbreak_0($7)
8031 Sample.c(16:27:31:1) iTemp2 [lr18:40]{short}[r2] = iTemp2 [lr18:40]{short}[r2]
8037 ITemp21 [lr21:38]{short}[r4]
8042 Sample.c(17:29:33:1) iTemp15 [lr29:30]{short}[r1] = iTemp21 [lr21:38]{short}[r4]
8048 Sample.c(17:30:34:1) iTemp11 [lr19:40]{short}[r3] = iTemp11 [lr19:40]{short}[r3]
8054 iTemp15 [lr29:30]{short}[r1]
8059 Sample.c(18:32:36:1:1) iTemp17 [lr23:38]{int}[r7 r0]= iTemp17 [lr23:38]{int}[r7
8065 Sample.c(18:33:37:1) _gint [lr0:0]{int} = _gint [lr0:0]{int} + iTemp17 [lr23:38]{
8071 Sample.c(15:36:42:1) iTemp21 [lr21:38]{short}[r4] = iTemp21 [lr21:38]{short}[r4]
8077 Sample.c(15:37:45:1) iTemp23 [lr22:38]{int}[r5 r6]= iTemp23 [lr22:38]{int}[r5
8083 Sample.c(19:38:47:1) goto _forcond_0($4)
8088 Sample.c(19:39:48:0)_forbreak_0($7) :
8093 Sample.c(20:40:49:0) iTemp24 [lr40:41]{short}[DPTR] = iTemp2 [lr18:40]{short}[r2]
8099 ITemp11 [lr19:40]{short}[r3]
8104 sample.c(20:41:50:0) ret iTemp24 [lr40:41]{short}
8109 sample.c(20:42:51:0)_return($8) :
8114 sample.c(20:43:52:0) eproc _function [lr0:0]{ ia0 re0 rm0}{function short}
8120 Finally the code generated for this function:
8161 ; ----------------------------------------------
8171 ; ----------------------------------------------
8181 ; iTemp0 [lr3:5]{_near * int}[r2] = recv
8193 ; iTemp6 [lr5:16]{_near * int}[r0] := iTemp0 [lr3:5]{_near * int}[r2]
8205 ;_whilecontinue_0($1) :
8215 ; iTemp4 [lr7:8]{int}[r2 r3] = @[iTemp6 [lr5:16]{_near * int}[r0]]
8220 ; if iTemp4 [lr7:8]{int}[r2 r3] == 0 goto _whilebreak_0($3)
8279 ; iTemp7 [lr9:13]{_far * int}[DPTR] := _p [lr0:0]{_far * int}
8298 ; _p [lr0:0]{_far * int} = _p [lr0:0]{_far * int} + 0x2 {short}
8345 ; iTemp10 [lr13:14]{int}[r2 r3] = @[iTemp7 [lr9:13]{_far * int}[DPTR]]
8385 ; *(iTemp6 [lr5:16]{_near * int}[r0]) := iTemp10 [lr13:14]{int}[r2 r3]
8411 ; iTemp6 [lr5:16]{_near * int}[r0] =
8416 ; iTemp6 [lr5:16]{_near * int}[r0] +
8433 ; goto _whilecontinue_0($1)
8445 ; _whilebreak_0($3) :
8455 ; iTemp2 [lr18:40]{short}[r2] := 0x0 {short}
8467 ; iTemp11 [lr19:40]{short}[r3] := 0x0 {short}
8479 ; iTemp21 [lr21:38]{short}[r4] := 0x0 {short}
8491 ; iTemp23 [lr22:38]{int}[r5 r6] := 0xa {int}
8510 ; iTemp17 [lr23:38]{int}[r7 r0] := 0x1e {int}
8539 ; iTemp13 [lr25:26]{char}[CC] = iTemp21 [lr21:38]{short}[r4] < 0xa {short}
8544 ; if iTemp13 [lr25:26]{char}[CC] == 0 goto _forbreak_0($7)
8589 ; iTemp2 [lr18:40]{short}[r2] = iTemp2 [lr18:40]{short}[r2] +
8594 ; iTemp21 [lr21:38]{short}[r4]
8620 ; iTemp15 [lr29:30]{short}[r1] = iTemp21 [lr21:38]{short}[r4] * 0x3 {short}
8653 ; iTemp11 [lr19:40]{short}[r3] = iTemp11 [lr19:40]{short}[r3] +
8658 ; iTemp15 [lr29:30]{short}[r1]
8677 ; iTemp17 [lr23:38]{int}[r7 r0]= iTemp17 [lr23:38]{int}[r7 r0]- 0x3 {short}
8724 ; _gint [lr0:0]{int} = _gint [lr0:0]{int} + iTemp17 [lr23:38]{int}[r7 r0]
8771 ; iTemp21 [lr21:38]{short}[r4] = iTemp21 [lr21:38]{short}[r4] + 0x1 {short}
8783 ; iTemp23 [lr22:38]{int}[r5 r6]= iTemp23 [lr22:38]{int}[r5 r6]- 0x1 {short}
8797 cjne r5,#0xff,00104$
8809 ; goto _forcond_0($4)
8831 ; ret iTemp24 [lr40:41]{short}
8880 \begin_inset LatexCommand \url{http://sdcc.sourceforge.net#Who}
8890 Thanks to all the other volunteer developers who have helped with coding,
8891 testing, web-page creation, distribution sets, etc.
8892 You know who you are :-)
8899 This document was initially written by Sandeep Dutta
8902 All product names mentioned herein may be trademarks of their respective
8908 \begin_inset LatexCommand \printindex{}
projects / fw / sdcc / blob