1 #LyX 1.2 created this file. For more info see http://www.lyx.org/
15 \use_numerical_citations 0
16 \paperorientation portrait
19 \paragraph_separation indent
21 \quotes_language swedish
29 Please note: double dashed longoptions (e.g.
30 --version) need three dashes in this document to be visable in html and
34 SDCC Compiler User Guide
38 \begin_inset LatexCommand \tableofcontents{}
55 is a Freeware, retargettable, optimizing ANSI-C compiler by
59 designed for 8 bit Microprocessors.
60 The current version targets Intel MCS51 based Microprocessors(8051,8052,
61 etc), Zilog Z80 based MCUs, and the Dallas DS80C390 variant.
62 It can be retargetted for other microprocessors, support for PIC, AVR and
63 186 is under development.
64 The entire source code for the compiler is distributed under GPL.
65 SDCC uses ASXXXX & ASLINK, a Freeware, retargettable assembler & linker.
66 SDCC has extensive language extensions suitable for utilizing various microcont
67 rollers and underlying hardware effectively.
72 In addition to the MCU specific optimizations SDCC also does a host of standard
76 global sub expression elimination,
79 loop optimizations (loop invariant, strength reduction of induction variables
83 constant folding & propagation,
99 For the back-end SDCC uses a global register allocation scheme which should
100 be well suited for other 8 bit MCUs.
105 The peep hole optimizer uses a rule based substitution mechanism which is
111 Supported data-types are:
114 char (8 bits, 1 byte),
117 short and int (16 bits, 2 bytes),
120 long (32 bit, 4 bytes)
127 The compiler also allows
129 inline assembler code
131 to be embedded anywhere in a function.
132 In addition, routines developed in assembly can also be called.
136 SDCC also provides an option (--cyclomatic) to report the relative complexity
138 These functions can then be further optimized, or hand coded in assembly
144 SDCC also comes with a companion source level debugger SDCDB, the debugger
145 currently uses ucSim a freeware simulator for 8051 and other micro-controllers.
150 The latest version can be downloaded from
151 \begin_inset LatexCommand \url{http://sdcc.sourceforge.net/}
163 All packages used in this compiler system are
171 ; source code for all the sub-packages (pre-processor, assemblers, linkers
172 etc) is distributed with the package.
173 This documentation is maintained using a freeware word processor (LyX).
175 This program is free software; you can redistribute it and/or modify it
176 under the terms of the GNU General Public License as published by the Free
177 Software Foundation; either version 2, or (at your option) any later version.
178 This program is distributed in the hope that it will be useful, but WITHOUT
179 ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
180 FOR A PARTICULAR PURPOSE.
181 See the GNU General Public License for more details.
182 You should have received a copy of the GNU General Public License along
183 with this program; if not, write to the Free Software Foundation, 59 Temple
184 Place - Suite 330, Boston, MA 02111-1307, USA.
185 In other words, you are welcome to use, share and improve this program.
186 You are forbidden to forbid anyone else to use, share and improve what
188 Help stamp out software-hoarding!
191 Typographic conventions
194 Throughout this manual, we will use the following convention.
195 Commands you have to type in are printed in
203 Code samples are printed in
208 Interesting items and new terms are printed in
213 Compatibility with previous versions
216 This version has numerous bug fixes compared with the previous version.
217 But we also introduced some incompatibilities with older versions.
218 Not just for the fun of it, but to make the compiler more stable, efficient
225 short is now equivalent to int (16 bits), it used to be equivalent to char
226 (8 bits) which is not ANSI compliant
229 the default directory for gcc-builds where include, library and documention
230 files are stored is now in /usr/local/share
233 char type parameters to vararg functions are casted to int unless explicitly
250 will push a as an int and as a char resp.
253 option ---regextend has been removed
256 option ---noregparms has been removed
259 option ---stack-after-data has been removed
264 <pending: more incompatibilities?>
270 What do you need before you start installation of SDCC? A computer, and
272 The preferred method of installation is to compile SDCC from source using
274 For Windows some pre-compiled binary distributions are available for your
276 You should have some experience with command line tools and compiler use.
282 The SDCC home page at
283 \begin_inset LatexCommand \url{http://sdcc.sourceforge.net/}
287 is a great place to find distribution sets.
288 You can also find links to the user mailing lists that offer help or discuss
289 SDCC with other SDCC users.
290 Web links to other SDCC related sites can also be found here.
291 This document can be found in the DOC directory of the source package as
293 Some of the other tools (simulator and assembler) included with SDCC contain
294 their own documentation and can be found in the source distribution.
295 If you want the latest unreleased software, the complete source package
296 is available directly by anonymous CVS on cvs.sdcc.sourceforge.net.
299 Wishes for the future
302 There are (and always will be) some things that could be done.
303 Here are some I can think of:
310 char KernelFunction3(char p) at 0x340;
316 If you can think of some more, please send them to the list.
322 <pending: And then of course a proper index-table
323 \begin_inset LatexCommand \index{index}
333 Install and search paths
336 Linux (and other gcc-builds like Solaris, Cygwin, Mingw32 and OSX) by default
337 install in /usr/local.
338 You can override this when configuring with ---prefix-path.
339 Subdirs used will be bin, share/sdcc/include, share/sdcc/lib and share/sdcc/doc.
341 Windows MSVC and Borland builds will install in one single tree (e.g.
342 /sdcc) with subdirs bin, lib, include and doc.
346 The paths searched when running the compiler are as follows (the first catch
350 Binary files (preprocessor, assembler and linker):
352 - the path of argv[0] (if available)
355 \begin_inset Quotes sld
359 \begin_inset Quotes srd
365 \begin_inset Quotes sld
369 \begin_inset Quotes srd
382 \begin_inset Quotes sld
386 \begin_inset Quotes srd
392 \begin_inset Quotes sld
396 \begin_inset Quotes srd
401 - /usr/local/share/sdcc/include (gcc builds)
403 - path(arv[0])/../include and then /sdcc/include (as a last resort for windoze
404 msvc and borland builds)
411 is auto-appended by the compiler, e.g.
412 small, large, z80, ds390 etc.):
417 \begin_inset Quotes sld
421 \begin_inset Quotes srd
431 \begin_inset Quotes sld
435 \begin_inset Quotes srd
444 - /usr/local/share/sdcc/lib/
450 - path(argv[0])/../lib/
458 (as a last resort for windoze msvc and borland builds)
461 Documentation (although never really searched for, you have to do that yourself
465 \begin_inset Quotes sld
469 \begin_inset Quotes srd
474 - /usr/local/share/sdcc/doc (gcc builds)
476 - /sdcc/doc (windoze msvc and borland builds)
479 So, for windoze it is highly recommended to set the environment variable
480 SDCCHOME to prevent needless usage of -I and -L options.
481 For gcc-builds SDCCHOME should only be set when sdcc is installed in non-standa
485 Linux and other gcc-based systems (cygwin, mingw32, osx)
490 Download the source package
492 either from the SDCC CVS repository or from the
493 \begin_inset LatexCommand \url[nightly snapshots]{http://sdcc.sourceforge.net/snap.php}
499 , it will be named something like sdcc
508 Bring up a command line terminal, such as xterm.
513 Unpack the file using a command like:
516 "tar -xzf sdcc.src.tgz
521 , this will create a sub-directory called sdcc with all of the sources.
524 Change directory into the main SDCC directory, for example type:
541 This configures the package for compilation on your system.
557 All of the source packages will compile, this can take a while.
573 This copies the binary executables, the include files, the libraries and
574 the documentation to the install directories.
578 \layout Subsubsection
580 Windows Install Using a Binary Package
583 Download the binary package and unpack it using your favorite unpacking
584 tool (gunzip, WinZip, etc).
585 This should unpack to a group of sub-directories.
586 An example directory structure after unpacking the mingw32 package is:
593 bin for the executables, c:
613 lib for the include and libraries.
616 Adjust your environment variable PATH to include the location of the bin
617 directory or start sdcc using the full path.
618 \layout Subsubsection
620 Windows Install Using Cygwin and Mingw32
623 Follow the instruction in
625 Linux and other gcc-based systems
628 \layout Subsubsection
630 Windows Install Using Microsoft Visual C++ 6.0/NET
635 Download the source package
637 either from the SDCC CVS repository or from the
638 \begin_inset LatexCommand \url[nightly snapshots]{http://sdcc.sourceforge.net/snap.php}
644 , it will be named something like sdcc
651 SDCC is distributed with all the projects, workspaces, and files you need
652 to build it using Visual C++ 6.0/NET.
653 The workspace name is 'sdcc.dsw'.
654 Please note that as it is now, all the executables are created in a folder
658 Once built you need to copy the executables from sdcc
662 bin before runnng SDCC.
667 In order to build SDCC with Visual C++ 6.0/NET you need win32 executables
668 of bison.exe, flex.exe, and gawk.exe.
669 One good place to get them is
670 \begin_inset LatexCommand \url[here]{http://unxutils.sourceforge.net}
678 Download the file UnxUtils.zip.
679 Now you have to install the utilities and setup Visual C++ so it can locate
680 the required programs.
681 Here there are two alternatives (choose one!):
688 a) Extract UnxUtils.zip to your C:
690 hard disk PRESERVING the original paths, otherwise bison won't work.
691 (If you are using WinZip make certain that 'Use folder names' is selected)
695 b) In the Visual C++ IDE click Tools, Options, select the Directory tab,
696 in 'Show directories for:' select 'Executable files', and in the directories
697 window add a new path: 'C:
707 (As a side effect, you get a bunch of Unix utilities that could be useful,
708 such as diff and patch.)
715 This one avoids extracting a bunch of files you may not use, but requires
720 a) Create a directory were to put the tools needed, or use a directory already
728 b) Extract 'bison.exe', 'bison.hairy', 'bison.simple', 'flex.exe', and gawk.exe
729 to such directory WITHOUT preserving the original paths.
730 (If you are using WinZip make certain that 'Use folder names' is not selected)
734 c) Rename bison.exe to '_bison.exe'.
738 d) Create a batch file 'bison.bat' in 'C:
742 ' and add these lines:
762 _bison %1 %2 %3 %4 %5 %6 %7 %8 %9
766 Steps 'c' and 'd' are needed because bison requires by default that the
767 files 'bison.simple' and 'bison.hairy' reside in some weird Unix directory,
768 '/usr/local/share/' I think.
769 So it is necessary to tell bison where those files are located if they
770 are not in such directory.
771 That is the function of the environment variables BISON_SIMPLE and BISON_HAIRY.
775 e) In the Visual C++ IDE click Tools, Options, select the Directory tab,
776 in 'Show directories for:' select 'Executable files', and in the directories
777 window add a new path: 'c:
780 Note that you can use any other path instead of 'c:
782 util', even the path where the Visual C++ tools are, probably: 'C:
786 Microsoft Visual Studio
791 So you don't have to execute step 'e' :)
795 Open 'sdcc.dsw' in Visual Studio, click 'build all', when it finishes copy
796 the executables from sdcc
800 bin, and you can compile using sdcc.
801 \layout Subsubsection
803 Windows Install Using Borland
806 From the sdcc directory, run the command "make -f Makefile.bcc".
807 This should regenerate all the .exe files in the bin directory except for
808 sdcdb.exe (which currently doesn't build under Borland C++).
811 If you modify any source files and need to rebuild, be aware that the dependanci
812 es may not be correctly calculated.
813 The safest option is to delete all .obj files and run the build again.
814 From a Cygwin BASH prompt, this can easily be done with the commmand:
824 ( -name '*.obj' -o -name '*.lib' -o -name '*.rul'
835 or on Windows NT/2000/XP from the command prompt with the commmand:
842 del /s *.obj *.lib *.rul
845 from the sdcc directory.
848 Testing out the SDCC Compiler
851 The first thing you should do after installing your SDCC compiler is to
859 at the prompt, and the program should run and tell you the version.
860 If it doesn't run, or gives a message about not finding sdcc program, then
861 you need to check over your installation.
862 Make sure that the sdcc bin directory is in your executable search path
863 defined by the PATH environment setting (see the Trouble-shooting section
865 Make sure that the sdcc program is in the bin folder, if not perhaps something
866 did not install correctly.
874 is commonly installed as described in section
875 \begin_inset Quotes sld
878 Install and search paths
879 \begin_inset Quotes srd
888 Make sure the compiler works on a very simple example.
889 Type in the following test.c program using your favorite
924 Compile this using the following command:
933 If all goes well, the compiler will generate a test.asm and test.rel file.
934 Congratulations, you've just compiled your first program with SDCC.
935 We used the -c option to tell SDCC not to link the generated code, just
936 to keep things simple for this step.
944 The next step is to try it with the linker.
954 If all goes well the compiler will link with the libraries and produce
955 a test.ihx output file.
960 (no test.ihx, and the linker generates warnings), then the problem is most
961 likely that sdcc cannot find the
965 usr/local/share/sdcc/lib directory
969 (see the Install trouble-shooting section for suggestions).
977 The final test is to ensure sdcc can use the
981 header files and libraries.
982 Edit test.c and change it to the following:
1002 strcpy(str1, "testing");
1011 Compile this by typing
1018 This should generate a test.ihx output file, and it should give no warnings
1019 such as not finding the string.h file.
1020 If it cannot find the string.h file, then the problem is that sdcc cannot
1021 find the /usr/local/share/sdcc/include directory
1025 (see the Install trouble-shooting section for suggestions).
1028 Install Trouble-shooting
1029 \layout Subsubsection
1031 SDCC does not build correctly.
1034 A thing to try is starting from scratch by unpacking the .tgz source package
1035 again in an empty directory.
1043 ./configure 2>&1 | tee configure.log
1057 make 2>&1 | tee make.log
1064 If anything goes wrong, you can review the log files to locate the problem.
1065 Or a relevant part of this can be attached to an email that could be helpful
1066 when requesting help from the mailing list.
1067 \layout Subsubsection
1070 \begin_inset Quotes sld
1074 \begin_inset Quotes srd
1081 \begin_inset Quotes sld
1085 \begin_inset Quotes srd
1088 command is a script that analyzes your system and performs some configuration
1089 to ensure the source package compiles on your system.
1090 It will take a few minutes to run, and will compile a few tests to determine
1091 what compiler features are installed.
1092 \layout Subsubsection
1095 \begin_inset Quotes sld
1099 \begin_inset Quotes srd
1105 This runs the GNU make tool, which automatically compiles all the source
1106 packages into the final installed binary executables.
1107 \layout Subsubsection
1110 \begin_inset Quotes sld
1114 \begin_inset Quotes erd
1120 This will install the compiler, other executables libraries and include
1121 files in to the appropriate directories.
1123 \begin_inset Quotes sld
1126 Install and Search PATHS
1127 \begin_inset Quotes srd
1132 On most systems you will need super-user privilages to do this.
1138 SDCC is not just a compiler, but a collection of tools by various developers.
1139 These include linkers, assemblers, simulators and other components.
1140 Here is a summary of some of the components.
1141 Note that the included simulator and assembler have separate documentation
1142 which you can find in the source package in their respective directories.
1143 As SDCC grows to include support for other processors, other packages from
1144 various developers are included and may have their own sets of documentation.
1148 You might want to look at the files which are installed in <installdir>.
1149 At the time of this writing, we find the following programs for gcc-builds:
1153 In <installdir>/bin:
1156 sdcc - The compiler.
1159 sdcpp - The C preprocessor.
1162 asx8051 - The assembler for 8051 type processors.
1169 as-gbz80 - The Z80 and GameBoy Z80 assemblers.
1172 aslink -The linker for 8051 type processors.
1179 link-gbz80 - The Z80 and GameBoy Z80 linkers.
1182 s51 - The ucSim 8051 simulator.
1185 sdcdb - The source debugger.
1188 packihx - A tool to pack (compress) Intel hex files.
1191 In <installdir>/share/sdcc/include
1197 In <installdir>/share/sdcc/lib
1200 the subdirs src and small, large, z80, gbz80 and ds390 with the precompiled
1204 In <installdir>/share/sdcc/doc
1210 As development for other processors proceeds, this list will expand to include
1211 executables to support processors like AVR, PIC, etc.
1212 \layout Subsubsection
1217 This is the actual compiler, it in turn uses the c-preprocessor and invokes
1218 the assembler and linkage editor.
1219 \layout Subsubsection
1221 sdcpp - The C-Preprocessor
1224 The preprocessor is a modified version of the GNU preprocessor.
1225 The C preprocessor is used to pull in #include sources, process #ifdef
1226 statements, #defines and so on.
1227 \layout Subsubsection
1229 asx8051, as-z80, as-gbz80, aslink, link-z80, link-gbz80 - The Assemblers
1233 This is retargettable assembler & linkage editor, it was developed by Alan
1235 John Hartman created the version for 8051, and I (Sandeep) have made some
1236 enhancements and bug fixes for it to work properly with the SDCC.
1237 \layout Subsubsection
1242 S51 is a freeware, opensource simulator developed by Daniel Drotos (
1243 \begin_inset LatexCommand \url{mailto:drdani@mazsola.iit.uni-miskolc.hu}
1248 The simulator is built as part of the build process.
1249 For more information visit Daniel's website at:
1250 \begin_inset LatexCommand \url{http://mazsola.iit.uni-miskolc.hu/~drdani/embedded/s51}
1255 It currently support the core mcs51, the Dallas DS80C390 and the Philips
1257 \layout Subsubsection
1259 sdcdb - Source Level Debugger
1265 <todo: is this thing still alive?>
1272 Sdcdb is the companion source level debugger.
1273 The current version of the debugger uses Daniel's Simulator S51, but can
1274 be easily changed to use other simulators.
1281 \layout Subsubsection
1283 Single Source File Projects
1286 For single source file 8051 projects the process is very simple.
1287 Compile your programs with the following command
1290 "sdcc sourcefile.c".
1294 This will compile, assemble and link your source file.
1295 Output files are as follows
1299 sourcefile.asm - Assembler source file created by the compiler
1301 sourcefile.lst - Assembler listing file created by the Assembler
1303 sourcefile.rst - Assembler listing file updated with linkedit information,
1304 created by linkage editor
1306 sourcefile.sym - symbol listing for the sourcefile, created by the assembler
1308 sourcefile.rel - Object file created by the assembler, input to Linkage editor
1310 sourcefile.map - The memory map for the load module, created by the Linker
1312 sourcefile.ihx - The load module in Intel hex format (you can select the
1313 Motorola S19 format with ---out-fmt-s19)
1315 sourcefile.cdb - An optional file (with ---debug) containing debug information
1317 sourcefile.dump* - Dump file to debug the compiler it self (with ---dumpall)
1319 \begin_inset Quotes sld
1322 Anatomy of the compiler
1323 \begin_inset Quotes srd
1327 \layout Subsubsection
1329 Projects with Multiple Source Files
1332 SDCC can compile only ONE file at a time.
1333 Let us for example assume that you have a project containing the following
1338 foo1.c (contains some functions)
1340 foo2.c (contains some more functions)
1342 foomain.c (contains more functions and the function main)
1350 The first two files will need to be compiled separately with the commands:
1382 Then compile the source file containing the
1386 function and link the files together with the following command:
1394 foomain.c\SpecialChar ~
1395 foo1.rel\SpecialChar ~
1407 can be separately compiled as well:
1418 sdcc foomain.rel foo1.rel foo2.rel
1425 The file containing the
1440 file specified in the command line, since the linkage editor processes
1441 file in the order they are presented to it.
1442 \layout Subsubsection
1444 Projects with Additional Libraries
1447 Some reusable routines may be compiled into a library, see the documentation
1448 for the assembler and linkage editor (which are in <installdir>/share/sdcc/doc)
1454 Libraries created in this manner can be included in the command line.
1455 Make sure you include the -L <library-path> option to tell the linker where
1456 to look for these files if they are not in the current directory.
1457 Here is an example, assuming you have the source file
1469 (if that is not the same as your current project):
1476 sdcc foomain.c foolib.lib -L mylib
1487 must be an absolute path name.
1491 The most efficient way to use libraries is to keep seperate modules in seperate
1493 The lib file now should name all the modules.rel files.
1494 For an example see the standard library file
1498 in the directory <installdir>/share/lib/small.
1501 Command Line Options
1502 \layout Subsubsection
1504 Processor Selection Options
1506 \labelwidthstring 00.00.0000
1512 Generate code for the MCS51 (8051) family of processors.
1513 This is the default processor target.
1515 \labelwidthstring 00.00.0000
1521 Generate code for the DS80C390 processor.
1523 \labelwidthstring 00.00.0000
1529 Generate code for the Z80 family of processors.
1531 \labelwidthstring 00.00.0000
1537 Generate code for the GameBoy Z80 processor.
1539 \labelwidthstring 00.00.0000
1545 Generate code for the Atmel AVR processor (In development, not complete).
1547 \labelwidthstring 00.00.0000
1553 Generate code for the PIC 14-bit processors (In development, not complete).
1555 \labelwidthstring 00.00.0000
1561 Generate code for the Toshiba TLCS-900H processor (In development, not
1564 \labelwidthstring 00.00.0000
1570 Generate code for the Philips XA51 processor (In development, not complete).
1571 \layout Subsubsection
1573 Preprocessor Options
1575 \labelwidthstring 00.00.0000
1581 The additional location where the pre processor will look for <..h> or
1582 \begin_inset Quotes eld
1586 \begin_inset Quotes erd
1591 \labelwidthstring 00.00.0000
1597 Command line definition of macros.
1598 Passed to the pre processor.
1600 \labelwidthstring 00.00.0000
1606 Tell the preprocessor to output a rule suitable for make describing the
1607 dependencies of each object file.
1608 For each source file, the preprocessor outputs one make-rule whose target
1609 is the object file name for that source file and whose dependencies are
1610 all the files `#include'd in it.
1611 This rule may be a single line or may be continued with `
1613 '-newline if it is long.
1614 The list of rules is printed on standard output instead of the preprocessed
1618 \labelwidthstring 00.00.0000
1624 Tell the preprocessor not to discard comments.
1625 Used with the `-E' option.
1627 \labelwidthstring 00.00.0000
1638 Like `-M' but the output mentions only the user header files included with
1640 \begin_inset Quotes eld
1644 System header files included with `#include <file>' are omitted.
1646 \labelwidthstring 00.00.0000
1652 Assert the answer answer for question, in case it is tested with a preprocessor
1653 conditional such as `#if #question(answer)'.
1654 `-A-' disables the standard assertions that normally describe the target
1657 \labelwidthstring 00.00.0000
1663 (answer) Assert the answer answer for question, in case it is tested with
1664 a preprocessor conditional such as `#if #question(answer)'.
1665 `-A-' disables the standard assertions that normally describe the target
1668 \labelwidthstring 00.00.0000
1674 Undefine macro macro.
1675 `-U' options are evaluated after all `-D' options, but before any `-include'
1676 and `-imacros' options.
1678 \labelwidthstring 00.00.0000
1684 Tell the preprocessor to output only a list of the macro definitions that
1685 are in effect at the end of preprocessing.
1686 Used with the `-E' option.
1688 \labelwidthstring 00.00.0000
1694 Tell the preprocessor to pass all macro definitions into the output, in
1695 their proper sequence in the rest of the output.
1697 \labelwidthstring 00.00.0000
1708 Like `-dD' except that the macro arguments and contents are omitted.
1709 Only `#define name' is included in the output.
1710 \layout Subsubsection
1714 \labelwidthstring 00.00.0000
1724 <absolute path to additional libraries> This option is passed to the linkage
1725 editor's additional libraries search path.
1726 The path name must be absolute.
1727 Additional library files may be specified in the command line.
1728 See section Compiling programs for more details.
1730 \labelwidthstring 00.00.0000
1736 <Value> The start location of the external ram, default value is 0.
1737 The value entered can be in Hexadecimal or Decimal format, e.g.: ---xram-loc
1738 0x8000 or ---xram-loc 32768.
1740 \labelwidthstring 00.00.0000
1746 <Value> The start location of the code segment, default value 0.
1747 Note when this option is used the interrupt vector table is also relocated
1748 to the given address.
1749 The value entered can be in Hexadecimal or Decimal format, e.g.: ---code-loc
1750 0x8000 or ---code-loc 32768.
1752 \labelwidthstring 00.00.0000
1758 <Value> By default the stack is placed after the data segment.
1759 Using this option the stack can be placed anywhere in the internal memory
1761 The value entered can be in Hexadecimal or Decimal format, e.g.
1762 ---stack-loc 0x20 or ---stack-loc 32.
1763 Since the sp register is incremented before a push or call, the initial
1764 sp will be set to one byte prior the provided value.
1765 The provided value should not overlap any other memory areas such as used
1766 register banks or the data segment and with enough space for the current
1769 \labelwidthstring 00.00.0000
1775 <Value> The start location of the internal ram data segment.
1776 The value entered can be in Hexadecimal or Decimal format, eg.
1777 ---data-loc 0x20 or ---data-loc 32.
1778 (By default, the start location of the internal ram data segment is set
1779 as low as possible in memory, taking into account the used register banks
1780 and the bit segment at address 0x20.
1781 For example if register banks 0 and 1 are used without bit variables, the
1782 data segment will be set, if ---data-loc is not used, to location 0x10.)
1784 \labelwidthstring 00.00.0000
1790 <Value> The start location of the indirectly addressable internal ram, default
1792 The value entered can be in Hexadecimal or Decimal format, eg.
1793 ---idata-loc 0x88 or ---idata-loc 136.
1795 \labelwidthstring 00.00.0000
1804 The linker output (final object code) is in Intel Hex format.
1805 (This is the default option).
1807 \labelwidthstring 00.00.0000
1816 The linker output (final object code) is in Motorola S19 format.
1817 \layout Subsubsection
1821 \labelwidthstring 00.00.0000
1827 Generate code for Large model programs see section Memory Models for more
1829 If this option is used all source files in the project should be compiled
1831 In addition the standard library routines are compiled with small model,
1832 they will need to be recompiled.
1834 \labelwidthstring 00.00.0000
1845 Generate code for Small Model programs see section Memory Models for more
1847 This is the default model.
1848 \layout Subsubsection
1852 \labelwidthstring 00.00.0000
1863 Generate 24-bit flat mode code.
1864 This is the one and only that the ds390 code generator supports right now
1865 and is default when using
1870 See section Memory Models for more details.
1872 \labelwidthstring 00.00.0000
1878 Generate code for the 10 bit stack mode of the Dallas DS80C390 part.
1879 This is the one and only that the ds390 code generator supports right now
1880 and is default when using
1885 In this mode, the stack is located in the lower 1K of the internal RAM,
1886 which is mapped to 0x400000.
1887 Note that the support is incomplete, since it still uses a single byte
1888 as the stack pointer.
1889 This means that only the lower 256 bytes of the potential 1K stack space
1890 will actually be used.
1891 However, this does allow you to reclaim the precious 256 bytes of low RAM
1892 for use for the DATA and IDATA segments.
1893 The compiler will not generate any code to put the processor into 10 bit
1895 It is important to ensure that the processor is in this mode before calling
1896 any re-entrant functions compiled with this option.
1897 In principle, this should work with the
1901 option, but that has not been tested.
1902 It is incompatible with the
1907 It also only makes sense if the processor is in 24 bit contiguous addressing
1910 ---model-flat24 option
1913 \layout Subsubsection
1915 Optimization Options
1917 \labelwidthstring 00.00.0000
1923 Will not do global subexpression elimination, this option may be used when
1924 the compiler creates undesirably large stack/data spaces to store compiler
1926 A warning message will be generated when this happens and the compiler
1927 will indicate the number of extra bytes it allocated.
1928 It recommended that this option NOT be used, #pragma\SpecialChar ~
1930 to turn off global subexpression elimination for a given function only.
1932 \labelwidthstring 00.00.0000
1938 Will not do loop invariant optimizations, this may be turned off for reasons
1939 explained for the previous option.
1940 For more details of loop optimizations performed see section Loop Invariants.It
1941 recommended that this option NOT be used, #pragma\SpecialChar ~
1942 NOINVARIANT can be used
1943 to turn off invariant optimizations for a given function only.
1945 \labelwidthstring 00.00.0000
1951 Will not do loop induction optimizations, see section strength reduction
1952 for more details.It is recommended that this option is NOT used, #pragma\SpecialChar ~
1954 ION can be used to turn off induction optimizations for a given function
1957 \labelwidthstring 00.00.0000
1968 Will not generate boundary condition check when switch statements are implement
1969 ed using jump-tables.
1970 See section Switch Statements for more details.
1971 It is recommended that this option is NOT used, #pragma\SpecialChar ~
1973 used to turn off boundary checking for jump tables for a given function
1976 \labelwidthstring 00.00.0000
1985 Will not do loop reversal optimization.
1987 \labelwidthstring 00.00.0000
1993 Will not optimize labels (makes the dumpfiles more readable).
1995 \labelwidthstring 00.00.0000
2001 Will not memcpy initialized data in far space from code space.
2002 This saves a few bytes in code space if you don't have initialized data.
2003 \layout Subsubsection
2007 \labelwidthstring 00.00.0000
2014 will compile and assemble the source, but will not call the linkage editor.
2016 \labelwidthstring 00.00.0000
2022 reads the preprocessed source from standard input and compiles it.
2023 The file name for the assembler output must be specified using the -o option.
2025 \labelwidthstring 00.00.0000
2031 Run only the C preprocessor.
2032 Preprocess all the C source files specified and output the results to standard
2035 \labelwidthstring 00.00.0000
2042 The output path resp.
2043 file where everything will be placed.
2044 If the parameter is a path, it must have a trailing slash (or backslash
2045 for the Windows binaries) to be recognized as a path.
2048 \labelwidthstring 00.00.0000
2059 All functions in the source file will be compiled as
2064 the parameters and local variables will be allocated on the stack.
2065 see section Parameters and Local Variables for more details.
2066 If this option is used all source files in the project should be compiled
2070 \labelwidthstring 00.00.0000
2076 Uses a pseudo stack in the first 256 bytes in the external ram for allocating
2077 variables and passing parameters.
2078 See section on external stack for more details.
2080 \labelwidthstring 00.00.0000
2084 ---callee-saves function1[,function2][,function3]....
2087 The compiler by default uses a caller saves convention for register saving
2088 across function calls, however this can cause unneccessary register pushing
2089 & popping when calling small functions from larger functions.
2090 This option can be used to switch the register saving convention for the
2091 function names specified.
2092 The compiler will not save registers when calling these functions, no extra
2093 code will be generated at the entry & exit for these functions to save
2094 & restore the registers used by these functions, this can SUBSTANTIALLY
2095 reduce code & improve run time performance of the generated code.
2096 In the future the compiler (with interprocedural analysis) will be able
2097 to determine the appropriate scheme to use for each function call.
2098 DO NOT use this option for built-in functions such as _muluint..., if this
2099 option is used for a library function the appropriate library function
2100 needs to be recompiled with the same option.
2101 If the project consists of multiple source files then all the source file
2102 should be compiled with the same ---callee-saves option string.
2103 Also see #pragma\SpecialChar ~
2106 \labelwidthstring 00.00.0000
2115 When this option is used the compiler will generate debug information, that
2116 can be used with the SDCDB.
2117 The debug information is collected in a file with .cdb extension.
2118 For more information see documentation for SDCDB.
2120 \labelwidthstring 00.00.0000
2126 <filename> This option can be used to use additional rules to be used by
2127 the peep hole optimizer.
2128 See section Peep Hole optimizations for details on how to write these rules.
2130 \labelwidthstring 00.00.0000
2141 Stop after the stage of compilation proper; do not assemble.
2142 The output is an assembler code file for the input file specified.
2144 \labelwidthstring 00.00.0000
2148 -Wa_asmOption[,asmOption]
2151 Pass the asmOption to the assembler.
2153 \labelwidthstring 00.00.0000
2157 -Wl_linkOption[,linkOption]
2160 Pass the linkOption to the linker.
2162 \labelwidthstring 00.00.0000
2171 Integer (16 bit) and long (32 bit) libraries have been compiled as reentrant.
2172 Note by default these libraries are compiled as non-reentrant.
2173 See section Installation for more details.
2175 \labelwidthstring 00.00.0000
2184 This option will cause the compiler to generate an information message for
2185 each function in the source file.
2186 The message contains some
2190 information about the function.
2191 The number of edges and nodes the compiler detected in the control flow
2192 graph of the function, and most importantly the
2194 cyclomatic complexity
2196 see section on Cyclomatic Complexity for more details.
2198 \labelwidthstring 00.00.0000
2207 Floating point library is compiled as reentrant.See section Installation
2210 \labelwidthstring 00.00.0000
2216 The compiler will not overlay parameters and local variables of any function,
2217 see section Parameters and local variables for more details.
2219 \labelwidthstring 00.00.0000
2225 This option can be used when the code generated is called by a monitor
2227 The compiler will generate a 'ret' upon return from the 'main' function.
2228 The default option is to lock up i.e.
2231 \labelwidthstring 00.00.0000
2237 Disable peep-hole optimization.
2239 \labelwidthstring 00.00.0000
2245 Pass the inline assembler code through the peep hole optimizer.
2246 This can cause unexpected changes to inline assembler code, please go through
2247 the peephole optimizer rules defined in the source file tree '<target>/peeph.def
2248 ' before using this option.
2250 \labelwidthstring 00.00.0000
2256 <Value> Causes the linker to check if the internal ram usage is within limits
2259 \labelwidthstring 00.00.0000
2265 <Value> Causes the linker to check if the external ram usage is within limits
2268 \labelwidthstring 00.00.0000
2274 <Value> Causes the linker to check if the code usage is within limits of
2277 \labelwidthstring 00.00.0000
2283 This will prevent the compiler from passing on the default include path
2284 to the preprocessor.
2286 \labelwidthstring 00.00.0000
2292 This will prevent the compiler from passing on the default library path
2295 \labelwidthstring 00.00.0000
2301 Shows the various actions the compiler is performing.
2303 \labelwidthstring 00.00.0000
2309 Shows the actual commands the compiler is executing.
2311 \labelwidthstring 00.00.0000
2317 Hides your ugly and inefficient c-code from the asm file, so you can always
2318 blame the compiler :).
2320 \labelwidthstring 00.00.0000
2326 Include i-codes in the asm file.
2327 Looks like noise but is most helpfull for debugging the compiler itself.
2328 \layout Subsubsection
2330 Intermediate Dump Options
2333 The following options are provided for the purpose of retargetting and debugging
2335 These provided a means to dump the intermediate code (iCode) generated
2336 by the compiler in human readable form at various stages of the compilation
2340 \labelwidthstring 00.00.0000
2346 This option will cause the compiler to dump the intermediate code into
2349 <source filename>.dumpraw
2351 just after the intermediate code has been generated for a function, i.e.
2352 before any optimizations are done.
2353 The basic blocks at this stage ordered in the depth first number, so they
2354 may not be in sequence of execution.
2356 \labelwidthstring 00.00.0000
2362 Will create a dump of iCode's, after global subexpression elimination,
2365 <source filename>.dumpgcse.
2367 \labelwidthstring 00.00.0000
2373 Will create a dump of iCode's, after deadcode elimination, into a file
2376 <source filename>.dumpdeadcode.
2378 \labelwidthstring 00.00.0000
2387 Will create a dump of iCode's, after loop optimizations, into a file named
2390 <source filename>.dumploop.
2392 \labelwidthstring 00.00.0000
2401 Will create a dump of iCode's, after live range analysis, into a file named
2404 <source filename>.dumprange.
2406 \labelwidthstring 00.00.0000
2412 Will dump the life ranges for all symbols.
2414 \labelwidthstring 00.00.0000
2423 Will create a dump of iCode's, after register assignment, into a file named
2426 <source filename>.dumprassgn.
2428 \labelwidthstring 00.00.0000
2434 Will create a dump of the live ranges of iTemp's
2436 \labelwidthstring 00.00.0000
2447 Will cause all the above mentioned dumps to be created.
2450 Environment variables
2453 SDCC recognizes the following environment variables:
2455 \labelwidthstring 00.00.0000
2461 SDCC installs a signal handler to be able to delete temporary files after
2462 an user break (^C) or an exception.
2463 If this environment variable is set, SDCC won't install the signal handler
2464 in order to be able to debug SDCC.
2466 \labelwidthstring 00.00.0000
2474 Path, where temporary files will be created.
2475 The order of the variables is the search order.
2476 In a standard *nix environment these variables are not set, and there's
2477 no need to set them.
2478 On Windows it's recommended to set one of them.
2480 \labelwidthstring 00.00.0000
2484 (coming\SpecialChar ~
2489 \begin_inset Quotes sld
2492 2.1 Install and search paths
2493 \begin_inset Quotes srd
2498 \labelwidthstring 00.00.0000
2502 (coming\SpecialChar ~
2507 \begin_inset Quotes sld
2510 2.1 Install and search paths
2511 \begin_inset Quotes srd
2516 \labelwidthstring 00.00.0000
2520 (coming\SpecialChar ~
2525 \begin_inset Quotes sld
2528 2.1 Install and search paths
2529 \begin_inset Quotes srd
2534 \labelwidthstring 00.00.0000
2538 SDCCDIR\SpecialChar ~
2540 replaced\SpecialChar ~
2545 \begin_inset Quotes sld
2548 2.1 Install and search paths
2549 \begin_inset Quotes srd
2555 There are some more environment variables recognized by SDCC, but these
2556 are solely used for debugging purposes.
2557 They can change or disappear very quickly, and will never be documentated.
2560 MCS51/DS390 Storage Class Language Extensions
2563 In addition to the ANSI storage classes SDCC allows the following MCS51
2564 specific storage classes.
2565 \layout Subsubsection
2570 Variables declared with this storage class will be placed in the extern
2576 storage class for Large Memory model, e.g.:
2582 xdata unsigned char xduc;
2583 \layout Subsubsection
2592 storage class for Small Memory model.
2593 Variables declared with this storage class will be allocated in the internal
2601 \layout Subsubsection
2606 Variables declared with this storage class will be allocated into the indirectly
2607 addressable portion of the internal ram of a 8051, e.g.:
2614 \layout Subsubsection
2619 This is a data-type and a storage class specifier.
2620 When a variable is declared as a bit, it is allocated into the bit addressable
2621 memory of 8051, e.g.:
2628 \layout Subsubsection
2633 Like the bit keyword,
2637 signifies both a data-type and storage class, they are used to describe
2638 the special function registers and special bit variables of a 8051, eg:
2644 sfr at 0x80 P0; /* special function register P0 at location 0x80 */
2646 sbit at 0xd7 CY; /* CY (Carry Flag) */
2652 SDCC allows (via language extensions) pointers to explicitly point to any
2653 of the memory spaces of the 8051.
2654 In addition to the explicit pointers, the compiler uses (by default) generic
2655 pointers which can be used to point to any of the memory spaces.
2659 Pointer declaration examples:
2668 /* pointer physically in xternal ram pointing to object in internal ram
2671 data unsigned char * xdata p;
2675 /* pointer physically in code rom pointing to data in xdata space */
2677 xdata unsigned char * code p;
2681 /* pointer physically in code space pointing to data in code space */
2683 code unsigned char * code p;
2687 /* the folowing is a generic pointer physically located in xdata space */
2698 Well you get the idea.
2703 All unqualified pointers are treated as 3-byte (4-byte for the ds390)
2716 The highest order byte of the
2720 pointers contains the data space information.
2721 Assembler support routines are called whenever data is stored or retrieved
2727 These are useful for developing reusable library routines.
2728 Explicitly specifying the pointer type will generate the most efficient
2732 Parameters & Local Variables
2735 Automatic (local) variables and parameters to functions can either be placed
2736 on the stack or in data-space.
2737 The default action of the compiler is to place these variables in the internal
2738 RAM (for small model) or external RAM (for large model).
2739 This in fact makes them
2743 so by default functions are non-reentrant.
2747 They can be placed on the stack either by using the
2751 option or by using the
2755 keyword in the function declaration, e.g.:
2764 unsigned char foo(char i) reentrant
2777 Since stack space on 8051 is limited, the
2785 option should be used sparingly.
2786 Note that the reentrant keyword just means that the parameters & local
2787 variables will be allocated to the stack, it
2791 mean that the function is register bank independent.
2795 Local variables can be assigned storage classes and absolute addresses,
2802 unsigned char foo() {
2808 xdata unsigned char i;
2820 data at 0x31 unsiged char j;
2835 In the above example the variable
2839 will be allocated in the external ram,
2843 in bit addressable space and
2852 or when a function is declared as
2856 this should only be done for static variables.
2859 Parameters however are not allowed any storage class, (storage classes for
2860 parameters will be ignored), their allocation is governed by the memory
2861 model in use, and the reentrancy options.
2867 For non-reentrant functions SDCC will try to reduce internal ram space usage
2868 by overlaying parameters and local variables of a function (if possible).
2869 Parameters and local variables of a function will be allocated to an overlayabl
2870 e segment if the function has
2872 no other function calls and the function is non-reentrant and the memory
2876 If an explicit storage class is specified for a local variable, it will
2880 Note that the compiler (not the linkage editor) makes the decision for overlayin
2882 Functions that are called from an interrupt service routine should be preceded
2883 by a #pragma\SpecialChar ~
2884 NOOVERLAY if they are not reentrant.
2887 Also note that the compiler does not do any processing of inline assembler
2888 code, so the compiler might incorrectly assign local variables and parameters
2889 of a function into the overlay segment if the inline assembler code calls
2890 other c-functions that might use the overlay.
2891 In that case the #pragma\SpecialChar ~
2892 NOOVERLAY should be used.
2895 Parameters and Local variables of functions that contain 16 or 32 bit multiplica
2896 tion or division will NOT be overlayed since these are implemented using
2897 external functions, e.g.:
2907 void set_error(unsigned char errcd)
2923 void some_isr () interrupt 2 using 1
2952 In the above example the parameter
2960 would be assigned to the overlayable segment if the #pragma\SpecialChar ~
2962 not present, this could cause unpredictable runtime behavior when called
2964 The #pragma\SpecialChar ~
2965 NOOVERLAY ensures that the parameters and local variables for
2966 the function are NOT overlayed.
2969 Interrupt Service Routines
2972 SDCC allows interrupt service routines to be coded in C, with some extended
2979 void timer_isr (void) interrupt 2 using 1
2992 The number following the
2996 keyword is the interrupt number this routine will service.
2997 The compiler will insert a call to this routine in the interrupt vector
2998 table for the interrupt number specified.
3003 keyword is used to tell the compiler to use the specified register bank
3004 (8051 specific) when generating code for this function.
3005 Note that when some function is called from an interrupt service routine
3006 it should be preceded by a #pragma\SpecialChar ~
3007 NOOVERLAY if it is not reentrant.
3008 A special note here, int (16 bit) and long (32 bit) integer division, multiplic
3009 ation & modulus operations are implemented using external support routines
3010 developed in ANSI-C, if an interrupt service routine needs to do any of
3011 these operations then the support routines (as mentioned in a following
3012 section) will have to be recompiled using the
3016 option and the source file will need to be compiled using the
3023 If you have multiple source files in your project, interrupt service routines
3024 can be present in any of them, but a prototype of the isr MUST be present
3025 or included in the file that contains the function
3032 Interrupt Numbers and the corresponding address & descriptions for the Standard
3033 8051 are listed below.
3034 SDCC will automatically adjust the interrupt vector table to the maximum
3035 interrupt number specified.
3041 \begin_inset Tabular
3042 <lyxtabular version="3" rows="6" columns="3">
3044 <column alignment="center" valignment="top" leftline="true" width="0pt">
3045 <column alignment="center" valignment="top" leftline="true" width="0pt">
3046 <column alignment="center" valignment="top" leftline="true" rightline="true" width="0pt">
3047 <row topline="true" bottomline="true">
3048 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3056 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3064 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
3073 <row topline="true">
3074 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3082 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3090 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
3099 <row topline="true">
3100 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3108 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3116 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
3125 <row topline="true">
3126 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3134 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3142 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
3151 <row topline="true">
3152 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3160 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3168 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
3177 <row topline="true" bottomline="true">
3178 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3186 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3194 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
3211 If the interrupt service routine is defined without
3215 a register bank or with register bank 0 (using 0), the compiler will save
3216 the registers used by itself on the stack upon entry and restore them at
3217 exit, however if such an interrupt service routine calls another function
3218 then the entire register bank will be saved on the stack.
3219 This scheme may be advantageous for small interrupt service routines which
3220 have low register usage.
3223 If the interrupt service routine is defined to be using a specific register
3228 are save and restored, if such an interrupt service routine calls another
3229 function (using another register bank) then the entire register bank of
3230 the called function will be saved on the stack.
3231 This scheme is recommended for larger interrupt service routines.
3234 Calling other functions from an interrupt service routine is not recommended,
3235 avoid it if possible.
3239 Also see the _naked modifier.
3247 <TODO: this isn't implemented at all!>
3253 A special keyword may be associated with a function declaring it as
3258 SDCC will generate code to disable all interrupts upon entry to a critical
3259 function and enable them back before returning.
3260 Note that nesting critical functions may cause unpredictable results.
3285 The critical attribute maybe used with other attributes like
3293 A special keyword may be associated with a function declaring it as
3302 function modifier attribute prevents the compiler from generating prologue
3303 and epilogue code for that function.
3304 This means that the user is entirely responsible for such things as saving
3305 any registers that may need to be preserved, selecting the proper register
3306 bank, generating the
3310 instruction at the end, etc.
3311 Practically, this means that the contents of the function must be written
3312 in inline assembler.
3313 This is particularly useful for interrupt functions, which can have a large
3314 (and often unnecessary) prologue/epilogue.
3315 For example, compare the code generated by these two functions:
3321 data unsigned char counter;
3323 void simpleInterrupt(void) interrupt 1
3337 void nakedInterrupt(void) interrupt 2 _naked
3370 ; MUST explicitly include ret in _naked function.
3384 For an 8051 target, the generated simpleInterrupt looks like:
3529 whereas nakedInterrupt looks like:
3554 ; MUST explicitly include ret(i) in _naked function.
3560 While there is nothing preventing you from writing C code inside a _naked
3561 function, there are many ways to shoot yourself in the foot doing this,
3562 and it is recommended that you stick to inline assembler.
3565 Functions using private banks
3572 attribute (which tells the compiler to use a register bank other than the
3573 default bank zero) should only be applied to
3577 functions (see note 1 below).
3578 This will in most circumstances make the generated ISR code more efficient
3579 since it will not have to save registers on the stack.
3586 attribute will have no effect on the generated code for a
3590 function (but may occasionally be useful anyway
3596 possible exception: if a function is called ONLY from 'interrupt' functions
3597 using a particular bank, it can be declared with the same 'using' attribute
3598 as the calling 'interrupt' functions.
3599 For instance, if you have several ISRs using bank one, and all of them
3600 call memcpy(), it might make sense to create a specialized version of memcpy()
3601 'using 1', since this would prevent the ISR from having to save bank zero
3602 to the stack on entry and switch to bank zero before calling the function
3609 (pending: I don't think this has been done yet)
3616 function using a non-zero bank will assume that it can trash that register
3617 bank, and will not save it.
3618 Since high-priority interrupts can interrupt low-priority ones on the 8051
3619 and friends, this means that if a high-priority ISR
3623 a particular bank occurs while processing a low-priority ISR
3627 the same bank, terrible and bad things can happen.
3628 To prevent this, no single register bank should be
3632 by both a high priority and a low priority ISR.
3633 This is probably most easily done by having all high priority ISRs use
3634 one bank and all low priority ISRs use another.
3635 If you have an ISR which can change priority at runtime, you're on your
3636 own: I suggest using the default bank zero and taking the small performance
3640 It is most efficient if your ISR calls no other functions.
3641 If your ISR must call other functions, it is most efficient if those functions
3642 use the same bank as the ISR (see note 1 below); the next best is if the
3643 called functions use bank zero.
3644 It is very inefficient to call a function using a different, non-zero bank
3652 Data items can be assigned an absolute address with the
3656 keyword, in addition to a storage class, e.g.:
3662 xdata at 0x8000 unsigned char PORTA_8255 ;
3668 In the above example the PORTA_8255 will be allocated to the location 0x8000
3669 of the external ram.
3670 Note that this feature is provided to give the programmer access to
3674 devices attached to the controller.
3675 The compiler does not actually reserve any space for variables declared
3676 in this way (they are implemented with an equate in the assembler).
3677 Thus it is left to the programmer to make sure there are no overlaps with
3678 other variables that are declared without the absolute address.
3679 The assembler listing file (.lst) and the linker output files (.rst) and
3680 (.map) are a good places to look for such overlaps.
3684 Absolute address can be specified for variables in all storage classes,
3697 The above example will allocate the variable at offset 0x02 in the bit-addressab
3699 There is no real advantage to assigning absolute addresses to variables
3700 in this manner, unless you want strict control over all the variables allocated.
3706 The compiler inserts a call to the C routine
3708 _sdcc__external__startup()
3713 at the start of the CODE area.
3714 This routine is in the runtime library.
3715 By default this routine returns 0, if this routine returns a non-zero value,
3716 the static & global variable initialization will be skipped and the function
3717 main will be invoked Other wise static & global variables will be initialized
3718 before the function main is invoked.
3721 _sdcc__external__startup()
3723 routine to your program to override the default if you need to setup hardware
3724 or perform some other critical operation prior to static & global variable
3728 Inline Assembler Code
3731 SDCC allows the use of in-line assembler with a few restriction as regards
3733 All labels defined within inline assembler code
3741 where nnnn is a number less than 100 (which implies a limit of utmost 100
3742 inline assembler labels
3750 It is strongly recommended that each assembly instruction (including labels)
3751 be placed in a separate line (as the example shows).
3756 command line option is used, the inline assembler code will be passed through
3757 the peephole optimizer.
3758 This might cause some unexpected changes in the inline assembler code.
3759 Please go throught the peephole optimizer rules defined in file
3763 carefully before using this option.
3803 The inline assembler code can contain any valid code understood by the assembler
3804 , this includes any assembler directives and comment lines.
3805 The compiler does not do any validation of the code within the
3815 Inline assembler code cannot reference any C-Labels, however it can reference
3816 labels defined by the inline assembler, e.g.:
3842 ; some assembler code
3862 /* some more c code */
3864 clabel:\SpecialChar ~
3866 /* inline assembler cannot reference this label */
3878 $0003: ;label (can be reference by inline assembler only)
3890 /* some more c code */
3898 In other words inline assembly code can access labels defined in inline
3899 assembly within the scope of the funtion.
3903 The same goes the other way, ie.
3904 labels defines in inline assembly CANNOT be accessed by C statements.
3907 int (16 bit) and long (32 bit) Support
3910 For signed & unsigned int (16 bit) and long (32 bit) variables, division,
3911 multiplication and modulus operations are implemented by support routines.
3912 These support routines are all developed in ANSI-C to facilitate porting
3913 to other MCUs, although some model specific assembler optimations are used.
3914 The following files contain the described routine, all of them can be found
3915 in <installdir>/share/sdcc/lib.
3921 <pending: tabularise this>
3927 _mulsint.c - signed 16 bit multiplication (calls _muluint)
3929 _muluint.c - unsigned 16 bit multiplication
3931 _divsint.c - signed 16 bit division (calls _divuint)
3933 _divuint.c - unsigned 16 bit division
3935 _modsint.c - signed 16 bit modulus (call _moduint)
3937 _moduint.c - unsigned 16 bit modulus
3939 _mulslong.c - signed 32 bit multiplication (calls _mululong)
3941 _mululong.c - unsigned32 bit multiplication
3943 _divslong.c - signed 32 division (calls _divulong)
3945 _divulong.c - unsigned 32 division
3947 _modslong.c - signed 32 bit modulus (calls _modulong)
3949 _modulong.c - unsigned 32 bit modulus
3957 Since they are compiled as
3961 , interrupt service routines should not do any of the above operations.
3962 If this is unavoidable then the above routines will need to be compiled
3967 option, after which the source program will have to be compiled with
3974 Floating Point Support
3977 SDCC supports IEEE (single precision 4bytes) floating point numbers.The floating
3978 point support routines are derived from gcc's floatlib.c and consists of
3979 the following routines:
3985 <pending: tabularise this>
3991 _fsadd.c - add floating point numbers
3993 _fssub.c - subtract floating point numbers
3995 _fsdiv.c - divide floating point numbers
3997 _fsmul.c - multiply floating point numbers
3999 _fs2uchar.c - convert floating point to unsigned char
4001 _fs2char.c - convert floating point to signed char
4003 _fs2uint.c - convert floating point to unsigned int
4005 _fs2int.c - convert floating point to signed int
4007 _fs2ulong.c - convert floating point to unsigned long
4009 _fs2long.c - convert floating point to signed long
4011 _uchar2fs.c - convert unsigned char to floating point
4013 _char2fs.c - convert char to floating point number
4015 _uint2fs.c - convert unsigned int to floating point
4017 _int2fs.c - convert int to floating point numbers
4019 _ulong2fs.c - convert unsigned long to floating point number
4021 _long2fs.c - convert long to floating point number
4029 Note if all these routines are used simultaneously the data space might
4031 For serious floating point usage it is strongly recommended that the large
4038 SDCC allows two memory models for MCS51 code, small and large.
4039 Modules compiled with different memory models should
4043 be combined together or the results would be unpredictable.
4044 The library routines supplied with the compiler are compiled as both small
4046 The compiled library modules are contained in seperate directories as small
4047 and large so that you can link to either set.
4051 When the large model is used all variables declared without a storage class
4052 will be allocated into the external ram, this includes all parameters and
4053 local variables (for non-reentrant functions).
4054 When the small model is used variables without storage class are allocated
4055 in the internal ram.
4058 Judicious usage of the processor specific storage classes and the 'reentrant'
4059 function type will yield much more efficient code, than using the large
4061 Several optimizations are disabled when the program is compiled using the
4062 large model, it is therefore strongly recommdended that the small model
4063 be used unless absolutely required.
4069 The only model supported is Flat 24.
4070 This generates code for the 24 bit contiguous addressing mode of the Dallas
4072 In this mode, up to four meg of external RAM or code space can be directly
4074 See the data sheets at www.dalsemi.com for further information on this part.
4078 In older versions of the compiler, this option was used with the MCS51 code
4084 Now, however, the '390 has it's own code generator, selected by the
4093 Note that the compiler does not generate any code to place the processor
4094 into 24 bitmode (although
4098 in the ds390 libraries will do that for you).
4103 , the boot loader or similar code must ensure that the processor is in 24
4104 bit contiguous addressing mode before calling the SDCC startup code.
4112 option, variables will by default be placed into the XDATA segment.
4117 Segments may be placed anywhere in the 4 meg address space using the usual
4119 Note that if any segments are located above 64K, the -r flag must be passed
4120 to the linker to generate the proper segment relocations, and the Intel
4121 HEX output format must be used.
4122 The -r flag can be passed to the linker by using the option
4126 on the sdcc command line.
4127 However, currently the linker can not handle code segments > 64k.
4130 Defines Created by the Compiler
4133 The compiler creates the following #defines.
4136 SDCC - this Symbol is always defined.
4139 SDCC_mcs51 or SDCC_ds390 or SDCC_z80, etc - depending on the model used
4143 __mcs51 or __ds390 or __z80, etc - depending on the model used (e.g.
4147 SDCC_STACK_AUTO - this symbol is defined when
4154 SDCC_MODEL_SMALL - when
4161 SDCC_MODEL_LARGE - when
4168 SDCC_USE_XSTACK - when
4175 SDCC_STACK_TENBIT - when
4182 SDCC_MODEL_FLAT24 - when
4195 SDCC performs a host of standard optimizations in addition to some MCU specific
4198 \layout Subsubsection
4200 Sub-expression Elimination
4203 The compiler does local and global common subexpression elimination, e.g.:
4218 will be translated to
4234 Some subexpressions are not as obvious as the above example, e.g.:
4248 In this case the address arithmetic a->b[i] will be computed only once;
4249 the equivalent code in C would be.
4265 The compiler will try to keep these temporary variables in registers.
4266 \layout Subsubsection
4268 Dead-Code Elimination
4283 i = 1; \SpecialChar ~
4288 global = 1;\SpecialChar ~
4301 global = 3;\SpecialChar ~
4316 int global; void f ()
4329 \layout Subsubsection
4390 Note: the dead stores created by this copy propagation will be eliminated
4391 by dead-code elimination.
4392 \layout Subsubsection
4397 Two types of loop optimizations are done by SDCC loop invariant lifting
4398 and strength reduction of loop induction variables.
4399 In addition to the strength reduction the optimizer marks the induction
4400 variables and the register allocator tries to keep the induction variables
4401 in registers for the duration of the loop.
4402 Because of this preference of the register allocator, loop induction optimizati
4403 on causes an increase in register pressure, which may cause unwanted spilling
4404 of other temporary variables into the stack / data space.
4405 The compiler will generate a warning message when it is forced to allocate
4406 extra space either on the stack or data space.
4407 If this extra space allocation is undesirable then induction optimization
4408 can be eliminated either for the entire source file (with ---noinduction
4409 option) or for a given function only using #pragma\SpecialChar ~
4420 for (i = 0 ; i < 100 ; i ++)
4438 for (i = 0; i < 100; i++)
4448 As mentioned previously some loop invariants are not as apparent, all static
4449 address computations are also moved out of the loop.
4453 Strength Reduction, this optimization substitutes an expression by a cheaper
4460 for (i=0;i < 100; i++)
4480 for (i=0;i< 100;i++) {
4484 ar[itemp1] = itemp2;
4500 The more expensive multiplication is changed to a less expensive addition.
4501 \layout Subsubsection
4506 This optimization is done to reduce the overhead of checking loop boundaries
4507 for every iteration.
4508 Some simple loops can be reversed and implemented using a
4509 \begin_inset Quotes eld
4512 decrement and jump if not zero
4513 \begin_inset Quotes erd
4517 SDCC checks for the following criterion to determine if a loop is reversible
4518 (note: more sophisticated compilers use data-dependency analysis to make
4519 this determination, SDCC uses a more simple minded analysis).
4522 The 'for' loop is of the form
4528 for (<symbol> = <expression> ; <sym> [< | <=] <expression> ; [<sym>++ |
4538 The <for body> does not contain
4539 \begin_inset Quotes eld
4543 \begin_inset Quotes erd
4547 \begin_inset Quotes erd
4553 All goto's are contained within the loop.
4556 No function calls within the loop.
4559 The loop control variable <sym> is not assigned any value within the loop
4562 The loop control variable does NOT participate in any arithmetic operation
4566 There are NO switch statements in the loop.
4567 \layout Subsubsection
4569 Algebraic Simplifications
4572 SDCC does numerous algebraic simplifications, the following is a small sub-set
4573 of these optimizations.
4579 i = j + 0 ; /* changed to */ i = j;
4581 i /= 2; /* changed to */ i >>= 1;
4583 i = j - j ; /* changed to */ i = 0;
4585 i = j / 1 ; /* changed to */ i = j;
4591 Note the subexpressions given above are generally introduced by macro expansions
4592 or as a result of copy/constant propagation.
4593 \layout Subsubsection
4598 SDCC changes switch statements to jump tables when the following conditions
4603 The case labels are in numerical sequence, the labels need not be in order,
4604 and the starting number need not be one or zero.
4610 switch(i) {\SpecialChar ~
4717 Both the above switch statements will be implemented using a jump-table.
4720 The number of case labels is at least three, since it takes two conditional
4721 statements to handle the boundary conditions.
4724 The number of case labels is less than 84, since each label takes 3 bytes
4725 and a jump-table can be utmost 256 bytes long.
4729 Switch statements which have gaps in the numeric sequence or those that
4730 have more that 84 case labels can be split into more than one switch statement
4731 for efficient code generation, e.g.:
4769 If the above switch statement is broken down into two switch statements
4803 case 9: \SpecialChar ~
4813 case 12:\SpecialChar ~
4823 then both the switch statements will be implemented using jump-tables whereas
4824 the unmodified switch statement will not be.
4825 \layout Subsubsection
4827 Bit-shifting Operations.
4830 Bit shifting is one of the most frequently used operation in embedded programmin
4832 SDCC tries to implement bit-shift operations in the most efficient way
4852 generates the following code:
4870 In general SDCC will never setup a loop if the shift count is known.
4910 Note that SDCC stores numbers in little-endian format (i.e.
4911 lowest order first).
4912 \layout Subsubsection
4917 A special case of the bit-shift operation is bit rotation, SDCC recognizes
4918 the following expression to be a left bit-rotation:
4929 i = ((i << 1) | (i >> 7));
4937 will generate the following code:
4953 SDCC uses pattern matching on the parse tree to determine this operation.Variatio
4954 ns of this case will also be recognized as bit-rotation, i.e.:
4960 i = ((i >> 7) | (i << 1)); /* left-bit rotation */
4961 \layout Subsubsection
4966 It is frequently required to obtain the highest order bit of an integral
4967 type (long, int, short or char types).
4968 SDCC recognizes the following expression to yield the highest order bit
4969 and generates optimized code for it, e.g.:
4990 hob = (gint >> 15) & 1;
5003 will generate the following code:
5042 000A E5*01\SpecialChar ~
5070 000C 33\SpecialChar ~
5101 000D E4\SpecialChar ~
5132 000E 13\SpecialChar ~
5163 000F F5*02\SpecialChar ~
5193 Variations of this case however will
5198 It is a standard C expression, so I heartily recommend this be the only
5199 way to get the highest order bit, (it is portable).
5200 Of course it will be recognized even if it is embedded in other expressions,
5207 xyz = gint + ((gint >> 15) & 1);
5213 will still be recognized.
5214 \layout Subsubsection
5219 The compiler uses a rule based, pattern matching and re-writing mechanism
5220 for peep-hole optimization.
5225 a peep-hole optimizer by Christopher W.
5226 Fraser (cwfraser@microsoft.com).
5227 A default set of rules are compiled into the compiler, additional rules
5228 may be added with the
5230 ---peep-file <filename>
5233 The rule language is best illustrated with examples.
5261 The above rule will change the following assembly sequence:
5291 Note: All occurrences of a
5295 (pattern variable) must denote the same string.
5296 With the above rule, the assembly sequence:
5314 will remain unmodified.
5318 Other special case optimizations may be added by the user (via
5324 some variants of the 8051 MCU allow only
5333 The following two rules will change all
5355 replace { lcall %1 } by { acall %1 }
5357 replace { ljmp %1 } by { ajmp %1 }
5365 inline-assembler code
5367 is also passed through the peep hole optimizer, thus the peephole optimizer
5368 can also be used as an assembly level macro expander.
5369 The rules themselves are MCU dependent whereas the rule language infra-structur
5370 e is MCU independent.
5371 Peephole optimization rules for other MCU can be easily programmed using
5376 The syntax for a rule is as follows:
5382 rule := replace [ restart ] '{' <assembly sequence> '
5420 <assembly sequence> '
5438 '}' [if <functionName> ] '
5446 <assembly sequence> := assembly instruction (each instruction including
5447 labels must be on a separate line).
5451 The optimizer will apply to the rules one by one from the top in the sequence
5452 of their appearance, it will terminate when all rules are exhausted.
5453 If the 'restart' option is specified, then the optimizer will start matching
5454 the rules again from the top, this option for a rule is expensive (performance)
5455 , it is intended to be used in situations where a transformation will trigger
5456 the same rule again.
5457 An example of this (not a good one, it has side effects) is the following
5484 Note that the replace pattern cannot be a blank, but can be a comment line.
5485 Without the 'restart' option only the inner most 'pop' 'push' pair would
5486 be eliminated, i.e.:
5538 the restart option the rule will be applied again to the resulting code
5539 and then all the pop-push pairs will be eliminated to yield:
5557 A conditional function can be attached to a rule.
5558 Attaching rules are somewhat more involved, let me illustrate this with
5589 The optimizer does a look-up of a function name table defined in function
5594 in the source file SDCCpeeph.c, with the name
5599 If it finds a corresponding entry the function is called.
5600 Note there can be no parameters specified for these functions, in this
5605 is crucial, since the function
5609 expects to find the label in that particular variable (the hash table containin
5610 g the variable bindings is passed as a parameter).
5611 If you want to code more such functions, take a close look at the function
5612 labelInRange and the calling mechanism in source file SDCCpeeph.c.
5613 I know this whole thing is a little kludgey, but maybe some day we will
5614 have some better means.
5615 If you are looking at this file, you will also see the default rules that
5616 are compiled into the compiler, you can add your own rules in the default
5617 set there if you get tired of specifying the ---peep-file option.
5623 SDCC supports the following #pragma directives.
5624 This directives are applicable only at a function level.
5627 SAVE - this will save all the current options.
5630 RESTORE - will restore the saved options from the last save.
5631 Note that SAVES & RESTOREs cannot be nested.
5632 SDCC uses the same buffer to save the options each time a SAVE is called.
5635 NOGCSE - will stop global subexpression elimination.
5638 NOINDUCTION - will stop loop induction optimizations.
5641 NOJTBOUND - will not generate code for boundary value checking, when switch
5642 statements are turned into jump-tables.
5645 NOOVERLAY - the compiler will not overlay the parameters and local variables
5649 NOLOOPREVERSE - Will not do loop reversal optimization
5652 EXCLUDE NONE | {acc[,b[,dpl[,dph]]] - The exclude pragma disables generation
5653 of pair of push/pop instruction in ISR function (using interrupt keyword).
5654 The directive should be placed immediately before the ISR function definition
5655 and it affects ALL ISR functions following it.
5656 To enable the normal register saving for ISR functions use #pragma\SpecialChar ~
5657 EXCLUDE\SpecialChar ~
5661 NOIV - Do not generate interrupt vector table entries for all ISR functions
5662 defined after the pragma.
5663 This is useful in cases where the interrupt vector table must be defined
5664 manually, or when there is a secondary, manually defined interrupt vector
5666 for the autovector feature of the Cypress EZ-USB FX2).
5669 CALLEE-SAVES function1[,function2[,function3...]] - The compiler by default
5670 uses a caller saves convention for register saving across function calls,
5671 however this can cause unneccessary register pushing & popping when calling
5672 small functions from larger functions.
5673 This option can be used to switch the register saving convention for the
5674 function names specified.
5675 The compiler will not save registers when calling these functions, extra
5676 code will be generated at the entry & exit for these functions to save
5677 & restore the registers used by these functions, this can SUBSTANTIALLY
5678 reduce code & improve run time performance of the generated code.
5679 In future the compiler (with interprocedural analysis) will be able to
5680 determine the appropriate scheme to use for each function call.
5681 If ---callee-saves command line option is used, the function names specified
5682 in #pragma\SpecialChar ~
5683 CALLEE-SAVES is appended to the list of functions specified inthe
5687 The pragma's are intended to be used to turn-off certain optimizations which
5688 might cause the compiler to generate extra stack / data space to store
5689 compiler generated temporary variables.
5690 This usually happens in large functions.
5691 Pragma directives should be used as shown in the following example, they
5692 are used to control options & optimizations for a given function; pragmas
5693 should be placed before and/or after a function, placing pragma's inside
5694 a function body could have unpredictable results.
5700 #pragma SAVE /* save the current settings */
5702 #pragma NOGCSE /* turnoff global subexpression elimination */
5704 #pragma NOINDUCTION /* turn off induction optimizations */
5726 #pragma RESTORE /* turn the optimizations back on */
5732 The compiler will generate a warning message when extra space is allocated.
5733 It is strongly recommended that the SAVE and RESTORE pragma's be used when
5734 changing options for a function.
5739 <pending: this is messy and incomplete>
5744 Compiler support routines (_gptrget, _mulint etc)
5747 Stdclib functions (puts, printf, strcat etc)
5750 Math functions (sin, pow, sqrt etc)
5753 Interfacing with Assembly Routines
5754 \layout Subsubsection
5756 Global Registers used for Parameter Passing
5759 The compiler always uses the global registers
5767 to pass the first parameter to a routine.
5768 The second parameter onwards is either allocated on the stack (for reentrant
5769 routines or if ---stack-auto is used) or in the internal / external ram
5770 (depending on the memory model).
5772 \layout Subsubsection
5774 Assembler Routine(non-reentrant)
5777 In the following example the function cfunc calls an assembler routine asm_func,
5778 which takes two parameters.
5784 extern int asm_func(unsigned char, unsigned char);
5788 int c_func (unsigned char i, unsigned char j)
5796 return asm_func(i,j);
5810 return c_func(10,9);
5818 The corresponding assembler function is:
5824 .globl _asm_func_PARM_2
5888 add a,_asm_func_PARM_2
5924 Note here that the return values are placed in 'dpl' - One byte return value,
5925 'dpl' LSB & 'dph' MSB for two byte values.
5926 'dpl', 'dph' and 'b' for three byte values (generic pointers) and 'dpl','dph','
5927 b' & 'acc' for four byte values.
5930 The parameter naming convention is _<function_name>_PARM_<n>, where n is
5931 the parameter number starting from 1, and counting from the left.
5932 The first parameter is passed in
5933 \begin_inset Quotes eld
5937 \begin_inset Quotes erd
5940 for One bye parameter,
5941 \begin_inset Quotes eld
5945 \begin_inset Quotes erd
5949 \begin_inset Quotes eld
5953 \begin_inset Quotes erd
5957 \begin_inset Quotes eld
5961 \begin_inset Quotes erd
5964 for four bytes, the varible name for the second parameter will be _<function_na
5969 Assemble the assembler routine with the following command:
5976 asx8051 -losg asmfunc.asm
5983 Then compile and link the assembler routine to the C source file with the
5991 sdcc cfunc.c asmfunc.rel
5992 \layout Subsubsection
5994 Assembler Routine(reentrant)
5997 In this case the second parameter onwards will be passed on the stack, the
5998 parameters are pushed from right to left i.e.
5999 after the call the left most parameter will be on the top of the stack.
6006 extern int asm_func(unsigned char, unsigned char);
6010 int c_func (unsigned char i, unsigned char j) reentrant
6018 return asm_func(i,j);
6032 return c_func(10,9);
6040 The corresponding assembler routine is:
6150 The compiling and linking procedure remains the same, however note the extra
6151 entry & exit linkage required for the assembler code, _bp is the stack
6152 frame pointer and is used to compute the offset into the stack for parameters
6153 and local variables.
6159 The external stack is located at the start of the external ram segment,
6160 and is 256 bytes in size.
6161 When ---xstack option is used to compile the program, the parameters and
6162 local variables of all reentrant functions are allocated in this area.
6163 This option is provided for programs with large stack space requirements.
6164 When used with the ---stack-auto option, all parameters and local variables
6165 are allocated on the external stack (note support libraries will need to
6166 be recompiled with the same options).
6169 The compiler outputs the higher order address byte of the external ram segment
6170 into PORT P2, therefore when using the External Stack option, this port
6171 MAY NOT be used by the application program.
6177 Deviations from the compliancy.
6180 functions are not always reentrant.
6183 structures cannot be assigned values directly, cannot be passed as function
6184 parameters or assigned to each other and cannot be a return value from
6211 s1 = s2 ; /* is invalid in SDCC although allowed in ANSI */
6222 struct s foo1 (struct s parms) /* is invalid in SDCC although allowed in
6244 return rets;/* is invalid in SDCC although allowed in ANSI */
6249 'long long' (64 bit integers) not supported.
6252 'double' precision floating point not supported.
6255 No support for setjmp and longjmp (for now).
6258 Old K&R style function declarations are NOT allowed.
6264 foo(i,j) /* this old style of function declarations */
6266 int i,j; /* are valid in ANSI but not valid in SDCC */
6280 functions declared as pointers must be dereferenced during the call.
6291 /* has to be called like this */
6293 (*foo)(); /* ansi standard allows calls to be made like 'foo()' */
6296 Cyclomatic Complexity
6299 Cyclomatic complexity of a function is defined as the number of independent
6300 paths the program can take during execution of the function.
6301 This is an important number since it defines the number test cases you
6302 have to generate to validate the function.
6303 The accepted industry standard for complexity number is 10, if the cyclomatic
6304 complexity reported by SDCC exceeds 10 you should think about simplification
6305 of the function logic.
6306 Note that the complexity level is not related to the number of lines of
6308 Large functions can have low complexity, and small functions can have large
6314 SDCC uses the following formula to compute the complexity:
6319 complexity = (number of edges in control flow graph) - (number of nodes
6320 in control flow graph) + 2;
6324 Having said that the industry standard is 10, you should be aware that in
6325 some cases it be may unavoidable to have a complexity level of less than
6327 For example if you have switch statement with more than 10 case labels,
6328 each case label adds one to the complexity level.
6329 The complexity level is by no means an absolute measure of the algorithmic
6330 complexity of the function, it does however provide a good starting point
6331 for which functions you might look at for further optimization.
6337 Here are a few guidelines that will help the compiler generate more efficient
6338 code, some of the tips are specific to this compiler others are generally
6339 good programming practice.
6342 Use the smallest data type to represent your data-value.
6343 If it is known in advance that the value is going to be less than 256 then
6344 use an 'unsigned char' instead of a 'short' or 'int'.
6347 Use unsigned when it is known in advance that the value is not going to
6349 This helps especially if you are doing division or multiplication.
6352 NEVER jump into a LOOP.
6355 Declare the variables to be local whenever possible, especially loop control
6356 variables (induction).
6359 Since the compiler does not always do implicit integral promotion, the programme
6360 r should do an explicit cast when integral promotion is required.
6363 Reducing the size of division, multiplication & modulus operations can reduce
6364 code size substantially.
6365 Take the following code for example.
6371 foobar(unsigned int p1, unsigned char ch)
6375 unsigned char ch1 = p1 % ch ;
6386 For the modulus operation the variable ch will be promoted to unsigned int
6387 first then the modulus operation will be performed (this will lead to a
6388 call to support routine _moduint()), and the result will be casted to a
6390 If the code is changed to
6396 foobar(unsigned int p1, unsigned char ch)
6400 unsigned char ch1 = (unsigned char)p1 % ch ;
6411 It would substantially reduce the code generated (future versions of the
6412 compiler will be smart enough to detect such optimization oppurtunities).
6415 Notes on MCS51 memory layout
6418 The 8051 family of micro controller have a minimum of 128 bytes of internal
6419 memory which is structured as follows
6423 - Bytes 00-1F - 32 bytes to hold up to 4 banks of the registers R7 to R7
6426 - Bytes 20-2F - 16 bytes to hold 128 bit variables and
6428 - Bytes 30-7F - 60 bytes for general purpose use.
6432 Normally the SDCC compiler will only utilise the first bank of registers,
6433 but it is possible to specify that other banks of registers should be used
6434 in interrupt routines.
6435 By default, the compiler will place the stack after the last bank of used
6437 if the first 2 banks of registers are used, it will position the base of
6438 the internal stack at address 16 (0X10).
6439 This implies that as the stack grows, it will use up the remaining register
6440 banks, and the 16 bytes used by the 128 bit variables, and 60 bytes for
6441 general purpose use.
6444 By default, the compiler uses the 60 general purpose bytes to hold "near
6446 The compiler/optimiser may also declare some Local Variables in this area
6451 If any of the 128 bit variables are used, or near data is being used then
6452 care needs to be taken to ensure that the stack does not grow so much that
6453 it starts to over write either your bit variables or "near data".
6454 There is no runtime checking to prevent this from happening.
6457 The amount of stack being used is affected by the use of the "internal stack"
6458 to save registers before a subroutine call is made (---stack-auto will
6459 declare parameters and local variables on the stack) and the number of
6463 If you detect that the stack is over writing you data, then the following
6465 ---xstack will cause an external stack to be used for saving registers
6466 and (if ---stack-auto is being used) storing parameters and local variables.
6467 However this will produce more code which will be slower to execute.
6471 ---stack-loc will allow you specify the start of the stack, i.e.
6472 you could start it after any data in the general purpose area.
6473 However this may waste the memory not used by the register banks and if
6474 the size of the "near data" increases, it may creep into the bottom of
6478 ---stack-after-data, similar to the ---stack-loc, but it automatically places
6479 the stack after the end of the "near data".
6480 Again this could waste any spare register space.
6483 ---data-loc allows you to specify the start address of the near data.
6484 This could be used to move the "near data" further away from the stack
6485 giving it more room to grow.
6486 This will only work if no bit variables are being used and the stack can
6487 grow to use the bit variable space.
6495 If you find that the stack is over writing your bit variables or "near data"
6496 then the approach which best utilised the internal memory is to position
6497 the "near data" after the last bank of used registers or, if you use bit
6498 variables, after the last bit variable by using the ---data-loc, e.g.
6499 if two register banks are being used and no bit variables, ---data-loc
6500 16, and use the ---stack-after-data option.
6503 If bit variables are being used, another method would be to try and squeeze
6504 the data area in the unused register banks if it will fit, and start the
6505 stack after the last bit variable.
6508 Retargetting for other MCUs.
6511 The issues for retargetting the compiler are far too numerous to be covered
6513 What follows is a brief description of each of the seven phases of the
6514 compiler and its MCU dependency.
6517 Parsing the source and building the annotated parse tree.
6518 This phase is largely MCU independent (except for the language extensions).
6519 Syntax & semantic checks are also done in this phase, along with some initial
6520 optimizations like back patching labels and the pattern matching optimizations
6521 like bit-rotation etc.
6524 The second phase involves generating an intermediate code which can be easy
6525 manipulated during the later phases.
6526 This phase is entirely MCU independent.
6527 The intermediate code generation assumes the target machine has unlimited
6528 number of registers, and designates them with the name iTemp.
6529 The compiler can be made to dump a human readable form of the code generated
6530 by using the ---dumpraw option.
6533 This phase does the bulk of the standard optimizations and is also MCU independe
6535 This phase can be broken down into several sub-phases:
6539 Break down intermediate code (iCode) into basic blocks.
6541 Do control flow & data flow analysis on the basic blocks.
6543 Do local common subexpression elimination, then global subexpression elimination
6545 Dead code elimination
6549 If loop optimizations caused any changes then do 'global subexpression eliminati
6550 on' and 'dead code elimination' again.
6553 This phase determines the live-ranges; by live range I mean those iTemp
6554 variables defined by the compiler that still survive after all the optimization
6556 Live range analysis is essential for register allocation, since these computati
6557 on determines which of these iTemps will be assigned to registers, and for
6561 Phase five is register allocation.
6562 There are two parts to this process.
6566 The first part I call 'register packing' (for lack of a better term).
6567 In this case several MCU specific expression folding is done to reduce
6572 The second part is more MCU independent and deals with allocating registers
6573 to the remaining live ranges.
6574 A lot of MCU specific code does creep into this phase because of the limited
6575 number of index registers available in the 8051.
6578 The Code generation phase is (unhappily), entirely MCU dependent and very
6579 little (if any at all) of this code can be reused for other MCU.
6580 However the scheme for allocating a homogenized assembler operand for each
6581 iCode operand may be reused.
6584 As mentioned in the optimization section the peep-hole optimizer is rule
6585 based system, which can reprogrammed for other MCUs.
6588 SDCDB - Source Level Debugger
6591 SDCC is distributed with a source level debugger.
6592 The debugger uses a command line interface, the command repertoire of the
6593 debugger has been kept as close to gdb (the GNU debugger) as possible.
6594 The configuration and build process is part of the standard compiler installati
6595 on, which also builds and installs the debugger in the target directory
6596 specified during configuration.
6597 The debugger allows you debug BOTH at the C source and at the ASM source
6601 Compiling for Debugging
6606 debug option must be specified for all files for which debug information
6608 The complier generates a .cdb file for each of these files.
6609 The linker updates the .cdb file with the address information.
6610 This .cdb is used by the debugger.
6613 How the Debugger Works
6616 When the ---debug option is specified the compiler generates extra symbol
6617 information some of which are put into the the assembler source and some
6618 are put into the .cdb file, the linker updates the .cdb file with the address
6619 information for the symbols.
6620 The debugger reads the symbolic information generated by the compiler &
6621 the address information generated by the linker.
6622 It uses the SIMULATOR (Daniel's S51) to execute the program, the program
6623 execution is controlled by the debugger.
6624 When a command is issued for the debugger, it translates it into appropriate
6625 commands for the simulator.
6628 Starting the Debugger
6631 The debugger can be started using the following command line.
6632 (Assume the file you are debugging has the file name foo).
6646 The debugger will look for the following files.
6649 foo.c - the source file.
6652 foo.cdb - the debugger symbol information file.
6655 foo.ihx - the intel hex format object file.
6658 Command Line Options.
6661 ---directory=<source file directory> this option can used to specify the
6662 directory search list.
6663 The debugger will look into the directory list specified for source, cdb
6665 The items in the directory list must be separated by ':', e.g.
6666 if the source files can be in the directories /home/src1 and /home/src2,
6667 the ---directory option should be ---directory=/home/src1:/home/src2.
6668 Note there can be no spaces in the option.
6672 -cd <directory> - change to the <directory>.
6675 -fullname - used by GUI front ends.
6678 -cpu <cpu-type> - this argument is passed to the simulator please see the
6679 simulator docs for details.
6682 -X <Clock frequency > this options is passed to the simulator please see
6683 the simulator docs for details.
6686 -s <serial port file> passed to simulator see the simulator docs for details.
6689 -S <serial in,out> passed to simulator see the simulator docs for details.
6695 As mention earlier the command interface for the debugger has been deliberately
6696 kept as close the GNU debugger gdb, as possible.
6697 This will help the integration with existing graphical user interfaces
6698 (like ddd, xxgdb or xemacs) existing for the GNU debugger.
6699 \layout Subsubsection
6701 break [line | file:line | function | file:function]
6704 Set breakpoint at specified line or function:
6713 sdcdb>break foo.c:100
6717 sdcdb>break foo.c:funcfoo
6718 \layout Subsubsection
6720 clear [line | file:line | function | file:function ]
6723 Clear breakpoint at specified line or function:
6732 sdcdb>clear foo.c:100
6736 sdcdb>clear foo.c:funcfoo
6737 \layout Subsubsection
6742 Continue program being debugged, after breakpoint.
6743 \layout Subsubsection
6748 Execute till the end of the current function.
6749 \layout Subsubsection
6754 Delete breakpoint number 'n'.
6755 If used without any option clear ALL user defined break points.
6756 \layout Subsubsection
6758 info [break | stack | frame | registers ]
6761 info break - list all breakpoints
6764 info stack - show the function call stack.
6767 info frame - show information about the current execution frame.
6770 info registers - show content of all registers.
6771 \layout Subsubsection
6776 Step program until it reaches a different source line.
6777 \layout Subsubsection
6782 Step program, proceeding through subroutine calls.
6783 \layout Subsubsection
6788 Start debugged program.
6789 \layout Subsubsection
6794 Print type information of the variable.
6795 \layout Subsubsection
6800 print value of variable.
6801 \layout Subsubsection
6806 load the given file name.
6807 Note this is an alternate method of loading file for debugging.
6808 \layout Subsubsection
6813 print information about current frame.
6814 \layout Subsubsection
6819 Toggle between C source & assembly source.
6820 \layout Subsubsection
6825 Send the string following '!' to the simulator, the simulator response is
6827 Note the debugger does not interpret the command being sent to the simulator,
6828 so if a command like 'go' is sent the debugger can loose its execution
6829 context and may display incorrect values.
6830 \layout Subsubsection
6837 My name is Bobby Brown"
6840 Interfacing with XEmacs.
6843 Two files (in emacs lisp) are provided for the interfacing with XEmacs,
6844 sdcdb.el and sdcdbsrc.el.
6845 These two files can be found in the $(prefix)/bin directory after the installat
6847 These files need to be loaded into XEmacs for the interface to work.
6848 This can be done at XEmacs startup time by inserting the following into
6849 your '.xemacs' file (which can be found in your HOME directory):
6855 (load-file sdcdbsrc.el)
6861 .xemacs is a lisp file so the () around the command is REQUIRED.
6862 The files can also be loaded dynamically while XEmacs is running, set the
6863 environment variable 'EMACSLOADPATH' to the installation bin directory
6864 (<installdir>/bin), then enter the following command ESC-x load-file sdcdbsrc.
6865 To start the interface enter the following command:
6879 You will prompted to enter the file name to be debugged.
6884 The command line options that are passed to the simulator directly are bound
6885 to default values in the file sdcdbsrc.el.
6886 The variables are listed below, these values maybe changed as required.
6889 sdcdbsrc-cpu-type '51
6892 sdcdbsrc-frequency '11059200
6898 The following is a list of key mapping for the debugger interface.
6906 ;; Current Listing ::
6923 binding\SpecialChar ~
6962 ------\SpecialChar ~
7002 sdcdb-next-from-src\SpecialChar ~
7028 sdcdb-back-from-src\SpecialChar ~
7054 sdcdb-cont-from-src\SpecialChar ~
7064 SDCDB continue command
7080 sdcdb-step-from-src\SpecialChar ~
7106 sdcdb-whatis-c-sexp\SpecialChar ~
7116 SDCDB ptypecommand for data at
7180 sdcdbsrc-delete\SpecialChar ~
7194 SDCDB Delete all breakpoints if no arg
7242 given or delete arg (C-u arg x)
7258 sdcdbsrc-frame\SpecialChar ~
7273 SDCDB Display current frame if no arg,
7322 given or display frame arg
7387 sdcdbsrc-goto-sdcdb\SpecialChar ~
7397 Goto the SDCDB output buffer
7413 sdcdb-print-c-sexp\SpecialChar ~
7424 SDCDB print command for data at
7488 sdcdbsrc-goto-sdcdb\SpecialChar ~
7498 Goto the SDCDB output buffer
7514 sdcdbsrc-mode\SpecialChar ~
7530 Toggles Sdcdbsrc mode (turns it off)
7534 ;; C-c C-f\SpecialChar ~
7542 sdcdb-finish-from-src\SpecialChar ~
7550 SDCDB finish command
7554 ;; C-x SPC\SpecialChar ~
7562 sdcdb-break\SpecialChar ~
7580 Set break for line with point
7582 ;; ESC t\SpecialChar ~
7592 sdcdbsrc-mode\SpecialChar ~
7608 Toggle Sdcdbsrc mode
7610 ;; ESC m\SpecialChar ~
7620 sdcdbsrc-srcmode\SpecialChar ~
7644 The Z80 and gbz80 port
7647 SDCC can target both the Zilog Z80 and the Nintendo Gameboy's Z80-like gbz80.
7648 The port is incomplete - long support is incomplete (mul, div and mod are
7649 unimplimented), and both float and bitfield support is missing.
7650 Apart from that the code generated is correct.
7653 As always, the code is the authoritave reference - see z80/ralloc.c and z80/gen.c.
7654 The stack frame is similar to that generated by the IAR Z80 compiler.
7655 IX is used as the base pointer, HL is used as a temporary register, and
7656 BC and DE are available for holding varibles.
7657 IY is currently unusued.
7658 Return values are stored in HL.
7659 One bad side effect of using IX as the base pointer is that a functions
7660 stack frame is limited to 127 bytes - this will be fixed in a later version.
7666 SDCC has grown to be a large project.
7667 The compiler alone (without the preprocessor, assembler and linker) is
7668 about 40,000 lines of code (blank stripped).
7669 The open source nature of this project is a key to its continued growth
7671 You gain the benefit and support of many active software developers and
7673 Is SDCC perfect? No, that's why we need your help.
7674 The developers take pride in fixing reported bugs.
7675 You can help by reporting the bugs and helping other SDCC users.
7676 There are lots of ways to contribute, and we encourage you to take part
7677 in making SDCC a great software package.
7683 Send an email to the mailing list at 'user-sdcc@sdcc.sourceforge.net' or 'devel-sd
7684 cc@sdcc.sourceforge.net'.
7685 Bugs will be fixed ASAP.
7686 When reporting a bug, it is very useful to include a small test program
7687 which reproduces the problem.
7688 If you can isolate the problem by looking at the generated assembly code,
7689 this can be very helpful.
7690 Compiling your program with the ---dumpall option can sometimes be useful
7691 in locating optimization problems.
7694 The anatomy of the compiler
7699 This is an excerpt from an atricle published in Circuit Cellar MagaZine
7701 It's a little outdated (the compiler is much more efficient now and user/devell
7702 oper friendly), but pretty well exposes the guts of it all.
7708 The current version of SDCC can generate code for Intel 8051 and Z80 MCU.
7709 It is fairly easy to retarget for other 8-bit MCU.
7710 Here we take a look at some of the internals of the compiler.
7717 Parsing the input source file and creating an AST (Annotated Syntax Tree).
7718 This phase also involves propagating types (annotating each node of the
7719 parse tree with type information) and semantic analysis.
7720 There are some MCU specific parsing rules.
7721 For example the storage classes, the extended storage classes are MCU specific
7722 while there may be a xdata storage class for 8051 there is no such storage
7723 class for z80 or Atmel AVR.
7724 SDCC allows MCU specific storage class extensions, i.e.
7725 xdata will be treated as a storage class specifier when parsing 8051 C
7726 code but will be treated as a C identifier when parsing z80 or ATMEL AVR
7733 Intermediate code generation.
7734 In this phase the AST is broken down into three-operand form (iCode).
7735 These three operand forms are represented as doubly linked lists.
7736 ICode is the term given to the intermediate form generated by the compiler.
7737 ICode example section shows some examples of iCode generated for some simple
7744 Bulk of the target independent optimizations is performed in this phase.
7745 The optimizations include constant propagation, common sub-expression eliminati
7746 on, loop invariant code movement, strength reduction of loop induction variables
7747 and dead-code elimination.
7753 During intermediate code generation phase, the compiler assumes the target
7754 machine has infinite number of registers and generates a lot of temporary
7756 The live range computation determines the lifetime of each of these compiler-ge
7757 nerated temporaries.
7758 A picture speaks a thousand words.
7759 ICode example sections show the live range annotations for each of the
7761 It is important to note here, each iCode is assigned a number in the order
7762 of its execution in the function.
7763 The live ranges are computed in terms of these numbers.
7764 The from number is the number of the iCode which first defines the operand
7765 and the to number signifies the iCode which uses this operand last.
7771 The register allocation determines the type and number of registers needed
7773 In most MCUs only a few registers can be used for indirect addressing.
7774 In case of 8051 for example the registers R0 & R1 can be used to indirectly
7775 address the internal ram and DPTR to indirectly address the external ram.
7776 The compiler will try to allocate the appropriate register to pointer variables
7778 ICode example section shows the operands annotated with the registers assigned
7780 The compiler will try to keep operands in registers as much as possible;
7781 there are several schemes the compiler uses to do achieve this.
7782 When the compiler runs out of registers the compiler will check to see
7783 if there are any live operands which is not used or defined in the current
7784 basic block being processed, if there are any found then it will push that
7785 operand and use the registers in this block, the operand will then be popped
7786 at the end of the basic block.
7790 There are other MCU specific considerations in this phase.
7791 Some MCUs have an accumulator; very short-lived operands could be assigned
7792 to the accumulator instead of general-purpose register.
7798 Figure II gives a table of iCode operations supported by the compiler.
7799 The code generation involves translating these operations into corresponding
7800 assembly code for the processor.
7801 This sounds overly simple but that is the essence of code generation.
7802 Some of the iCode operations are generated on a MCU specific manner for
7803 example, the z80 port does not use registers to pass parameters so the
7804 SEND and RECV iCode operations will not be generated, and it also does
7805 not support JUMPTABLES.
7812 <Where is Figure II ?>
7818 This section shows some details of iCode.
7819 The example C code does not do anything useful; it is used as an example
7820 to illustrate the intermediate code generated by the compiler.
7833 /* This function does nothing useful.
7840 for the purpose of explaining iCode */
7843 short function (data int *x)
7851 short i=10; /* dead initialization eliminated */
7856 short sum=10; /* dead initialization eliminated */
7869 while (*x) *x++ = *p++;
7883 /* compiler detects i,j to be induction variables */
7887 for (i = 0, j = 10 ; i < 10 ; i++, j---) {
7899 mul += i * 3; /* this multiplication remains */
7905 gint += j * 3;/* this multiplication changed to addition */
7922 In addition to the operands each iCode contains information about the filename
7923 and line it corresponds to in the source file.
7924 The first field in the listing should be interpreted as follows:
7929 Filename(linenumber: iCode Execution sequence number : ICode hash table
7930 key : loop depth of the iCode).
7935 Then follows the human readable form of the ICode operation.
7936 Each operand of this triplet form can be of three basic types a) compiler
7937 generated temporary b) user defined variable c) a constant value.
7938 Note that local variables and parameters are replaced by compiler generated
7940 Live ranges are computed only for temporaries (i.e.
7941 live ranges are not computed for global variables).
7942 Registers are allocated for temporaries only.
7943 Operands are formatted in the following manner:
7948 Operand Name [lr live-from : live-to ] { type information } [ registers
7954 As mentioned earlier the live ranges are computed in terms of the execution
7955 sequence number of the iCodes, for example
7957 the iTemp0 is live from (i.e.
7958 first defined in iCode with execution sequence number 3, and is last used
7959 in the iCode with sequence number 5).
7960 For induction variables such as iTemp21 the live range computation extends
7961 the lifetime from the start to the end of the loop.
7963 The register allocator used the live range information to allocate registers,
7964 the same registers may be used for different temporaries if their live
7965 ranges do not overlap, for example r0 is allocated to both iTemp6 and to
7966 iTemp17 since their live ranges do not overlap.
7967 In addition the allocator also takes into consideration the type and usage
7968 of a temporary, for example itemp6 is a pointer to near space and is used
7969 as to fetch data from (i.e.
7970 used in GET_VALUE_AT_ADDRESS) so it is allocated a pointer registers (r0).
7971 Some short lived temporaries are allocated to special registers which have
7972 meaning to the code generator e.g.
7973 iTemp13 is allocated to a pseudo register CC which tells the back end that
7974 the temporary is used only for a conditional jump the code generation makes
7975 use of this information to optimize a compare and jump ICode.
7977 There are several loop optimizations performed by the compiler.
7978 It can detect induction variables iTemp21(i) and iTemp23(j).
7979 Also note the compiler does selective strength reduction, i.e.
7980 the multiplication of an induction variable in line 18 (gint = j * 3) is
7981 changed to addition, a new temporary iTemp17 is allocated and assigned
7982 a initial value, a constant 3 is then added for each iteration of the loop.
7983 The compiler does not change the multiplication in line 17 however since
7984 the processor does support an 8 * 8 bit multiplication.
7986 Note the dead code elimination optimization eliminated the dead assignments
7987 in line 7 & 8 to I and sum respectively.
7994 Sample.c (5:1:0:0) _entry($9) :
7999 Sample.c(5:2:1:0) proc _function [lr0:0]{function short}
8004 Sample.c(11:3:2:0) iTemp0 [lr3:5]{_near * int}[r2] = recv
8009 Sample.c(11:4:53:0) preHeaderLbl0($11) :
8014 Sample.c(11:5:55:0) iTemp6 [lr5:16]{_near * int}[r0] := iTemp0 [lr3:5]{_near
8020 Sample.c(11:6:5:1) _whilecontinue_0($1) :
8025 Sample.c(11:7:7:1) iTemp4 [lr7:8]{int}[r2 r3] = @[iTemp6 [lr5:16]{_near *
8031 Sample.c(11:8:8:1) if iTemp4 [lr7:8]{int}[r2 r3] == 0 goto _whilebreak_0($3)
8036 Sample.c(11:9:14:1) iTemp7 [lr9:13]{_far * int}[DPTR] := _p [lr0:0]{_far
8042 Sample.c(11:10:15:1) _p [lr0:0]{_far * int} = _p [lr0:0]{_far * int} + 0x2
8048 Sample.c(11:13:18:1) iTemp10 [lr13:14]{int}[r2 r3] = @[iTemp7 [lr9:13]{_far
8054 Sample.c(11:14:19:1) *(iTemp6 [lr5:16]{_near * int}[r0]) := iTemp10 [lr13:14]{int
8060 Sample.c(11:15:12:1) iTemp6 [lr5:16]{_near * int}[r0] = iTemp6 [lr5:16]{_near
8061 * int}[r0] + 0x2 {short}
8066 Sample.c(11:16:20:1) goto _whilecontinue_0($1)
8071 Sample.c(11:17:21:0)_whilebreak_0($3) :
8076 Sample.c(12:18:22:0) iTemp2 [lr18:40]{short}[r2] := 0x0 {short}
8081 Sample.c(13:19:23:0) iTemp11 [lr19:40]{short}[r3] := 0x0 {short}
8086 Sample.c(15:20:54:0)preHeaderLbl1($13) :
8091 Sample.c(15:21:56:0) iTemp21 [lr21:38]{short}[r4] := 0x0 {short}
8096 Sample.c(15:22:57:0) iTemp23 [lr22:38]{int}[r5 r6] := 0xa {int}
8101 Sample.c(15:23:58:0) iTemp17 [lr23:38]{int}[r7 r0] := 0x1e {int}
8106 Sample.c(15:24:26:1)_forcond_0($4) :
8111 Sample.c(15:25:27:1) iTemp13 [lr25:26]{char}[CC] = iTemp21 [lr21:38]{short}[r4]
8117 Sample.c(15:26:28:1) if iTemp13 [lr25:26]{char}[CC] == 0 goto _forbreak_0($7)
8122 Sample.c(16:27:31:1) iTemp2 [lr18:40]{short}[r2] = iTemp2 [lr18:40]{short}[r2]
8123 + ITemp21 [lr21:38]{short}[r4]
8128 Sample.c(17:29:33:1) iTemp15 [lr29:30]{short}[r1] = iTemp21 [lr21:38]{short}[r4]
8134 Sample.c(17:30:34:1) iTemp11 [lr19:40]{short}[r3] = iTemp11 [lr19:40]{short}[r3]
8135 + iTemp15 [lr29:30]{short}[r1]
8140 Sample.c(18:32:36:1:1) iTemp17 [lr23:38]{int}[r7 r0]= iTemp17 [lr23:38]{int}[r7
8146 Sample.c(18:33:37:1) _gint [lr0:0]{int} = _gint [lr0:0]{int} + iTemp17 [lr23:38]{
8152 Sample.c(15:36:42:1) iTemp21 [lr21:38]{short}[r4] = iTemp21 [lr21:38]{short}[r4]
8158 Sample.c(15:37:45:1) iTemp23 [lr22:38]{int}[r5 r6]= iTemp23 [lr22:38]{int}[r5
8164 Sample.c(19:38:47:1) goto _forcond_0($4)
8169 Sample.c(19:39:48:0)_forbreak_0($7) :
8174 Sample.c(20:40:49:0) iTemp24 [lr40:41]{short}[DPTR] = iTemp2 [lr18:40]{short}[r2]
8175 + ITemp11 [lr19:40]{short}[r3]
8180 Sample.c(20:41:50:0) ret iTemp24 [lr40:41]{short}
8185 Sample.c(20:42:51:0)_return($8) :
8190 Sample.c(20:43:52:0) eproc _function [lr0:0]{ ia0 re0 rm0}{function short}
8196 Finally the code generated for this function:
8237 ; ----------------------------------------------
8247 ; ----------------------------------------------
8257 ; iTemp0 [lr3:5]{_near * int}[r2] = recv
8269 ; iTemp6 [lr5:16]{_near * int}[r0] := iTemp0 [lr3:5]{_near * int}[r2]
8281 ;_whilecontinue_0($1) :
8291 ; iTemp4 [lr7:8]{int}[r2 r3] = @[iTemp6 [lr5:16]{_near * int}[r0]]
8296 ; if iTemp4 [lr7:8]{int}[r2 r3] == 0 goto _whilebreak_0($3)
8355 ; iTemp7 [lr9:13]{_far * int}[DPTR] := _p [lr0:0]{_far * int}
8374 ; _p [lr0:0]{_far * int} = _p [lr0:0]{_far * int} + 0x2 {short}
8421 ; iTemp10 [lr13:14]{int}[r2 r3] = @[iTemp7 [lr9:13]{_far * int}[DPTR]]
8461 ; *(iTemp6 [lr5:16]{_near * int}[r0]) := iTemp10 [lr13:14]{int}[r2 r3]
8487 ; iTemp6 [lr5:16]{_near * int}[r0] =
8492 ; iTemp6 [lr5:16]{_near * int}[r0] +
8509 ; goto _whilecontinue_0($1)
8521 ; _whilebreak_0($3) :
8531 ; iTemp2 [lr18:40]{short}[r2] := 0x0 {short}
8543 ; iTemp11 [lr19:40]{short}[r3] := 0x0 {short}
8555 ; iTemp21 [lr21:38]{short}[r4] := 0x0 {short}
8567 ; iTemp23 [lr22:38]{int}[r5 r6] := 0xa {int}
8586 ; iTemp17 [lr23:38]{int}[r7 r0] := 0x1e {int}
8615 ; iTemp13 [lr25:26]{char}[CC] = iTemp21 [lr21:38]{short}[r4] < 0xa {short}
8620 ; if iTemp13 [lr25:26]{char}[CC] == 0 goto _forbreak_0($7)
8665 ; iTemp2 [lr18:40]{short}[r2] = iTemp2 [lr18:40]{short}[r2] +
8670 ; iTemp21 [lr21:38]{short}[r4]
8696 ; iTemp15 [lr29:30]{short}[r1] = iTemp21 [lr21:38]{short}[r4] * 0x3 {short}
8729 ; iTemp11 [lr19:40]{short}[r3] = iTemp11 [lr19:40]{short}[r3] +
8734 ; iTemp15 [lr29:30]{short}[r1]
8753 ; iTemp17 [lr23:38]{int}[r7 r0]= iTemp17 [lr23:38]{int}[r7 r0]- 0x3 {short}
8800 ; _gint [lr0:0]{int} = _gint [lr0:0]{int} + iTemp17 [lr23:38]{int}[r7 r0]
8847 ; iTemp21 [lr21:38]{short}[r4] = iTemp21 [lr21:38]{short}[r4] + 0x1 {short}
8859 ; iTemp23 [lr22:38]{int}[r5 r6]= iTemp23 [lr22:38]{int}[r5 r6]- 0x1 {short}
8873 cjne r5,#0xff,00104$
8885 ; goto _forcond_0($4)
8907 ; ret iTemp24 [lr40:41]{short}
8956 \begin_inset LatexCommand \url{http://sdcc.sourceforge.net#Who}
8966 Thanks to all the other volunteer developers who have helped with coding,
8967 testing, web-page creation, distribution sets, etc.
8968 You know who you are :-)
8975 This document was initially written by Sandeep Dutta
8978 All product names mentioned herein may be trademarks of their respective
8984 \begin_inset LatexCommand \printindex{}
projects / fw / sdcc / blob