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
43 SDCC Compiler User Guide
47 \begin_inset LatexCommand \tableofcontents{}
64 is a Freeware, retargettable, optimizing ANSI-C compiler by
68 designed for 8 bit Microprocessors.
69 The current version targets Intel MCS51 based Microprocessors(8051,8052,
70 etc), Zilog Z80 based MCUs, and the Dallas DS80C390 variant.
71 It can be retargetted for other microprocessors, support for PIC, AVR and
72 186 is under development.
73 The entire source code for the compiler is distributed under GPL.
74 SDCC uses ASXXXX & ASLINK, a Freeware, retargettable assembler & linker.
75 SDCC has extensive language extensions suitable for utilizing various microcont
76 rollers and underlying hardware effectively.
81 In addition to the MCU specific optimizations SDCC also does a host of standard
85 global sub expression elimination,
88 loop optimizations (loop invariant, strength reduction of induction variables
92 constant folding & propagation,
108 For the back-end SDCC uses a global register allocation scheme which should
109 be well suited for other 8 bit MCUs.
114 The peep hole optimizer uses a rule based substitution mechanism which is
120 Supported data-types are:
123 char (8 bits, 1 byte),
126 short and int (16 bits, 2 bytes),
129 long (32 bit, 4 bytes)
136 The compiler also allows
138 inline assembler code
140 to be embedded anywhere in a function.
141 In addition, routines developed in assembly can also be called.
145 SDCC also provides an option (---cyclomatic) to report the relative complexity
147 These functions can then be further optimized, or hand coded in assembly
153 SDCC also comes with a companion source level debugger SDCDB, the debugger
154 currently uses ucSim a freeware simulator for 8051 and other micro-controllers.
159 The latest version can be downloaded from
160 \begin_inset LatexCommand \htmlurl{http://sdcc.sourceforge.net/}
172 All packages used in this compiler system are
180 ; source code for all the sub-packages (pre-processor, assemblers, linkers
181 etc) is distributed with the package.
182 This documentation is maintained using a freeware word processor (LyX).
184 This program is free software; you can redistribute it and/or modify it
185 under the terms of the GNU General Public License as published by the Free
186 Software Foundation; either version 2, or (at your option) any later version.
187 This program is distributed in the hope that it will be useful, but WITHOUT
188 ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
189 FOR A PARTICULAR PURPOSE.
190 See the GNU General Public License for more details.
191 You should have received a copy of the GNU General Public License along
192 with this program; if not, write to the Free Software Foundation, 59 Temple
193 Place - Suite 330, Boston, MA 02111-1307, USA.
194 In other words, you are welcome to use, share and improve this program.
195 You are forbidden to forbid anyone else to use, share and improve what
197 Help stamp out software-hoarding!
200 Typographic conventions
203 Throughout this manual, we will use the following convention.
204 Commands you have to type in are printed in
212 Code samples are printed in
217 Interesting items and new terms are printed in
222 Compatibility with previous versions
225 This version has numerous bug fixes compared with the previous version.
226 But we also introduced some incompatibilities with older versions.
227 Not just for the fun of it, but to make the compiler more stable, efficient
234 short is now equivalent to int (16 bits), it used to be equivalent to char
235 (8 bits) which is not ANSI compliant
238 the default directory where include, library and documention files are stored
239 is now in /usr/local/share
242 char type parameters to vararg functions are casted to int unless explicitly
259 will push a as an int and as a char resp.
262 option --regextend has been removed
265 option --noregparms has been removed
268 option --stack-after-data has been removed
273 <pending: more incompatibilities?>
279 What do you need before you start installation of SDCC? A computer, and
281 The preferred method of installation is to compile SDCC from source using
283 For Windows some pre-compiled binary distributions are available for your
285 You should have some experience with command line tools and compiler use.
291 The SDCC home page at
292 \begin_inset LatexCommand \htmlurl{http://sdcc.sourceforge.net/}
296 is a great place to find distribution sets.
297 You can also find links to the user mailing lists that offer help or discuss
298 SDCC with other SDCC users.
299 Web links to other SDCC related sites can also be found here.
300 This document can be found in the DOC directory of the source package as
302 Some of the other tools (simulator and assembler) included with SDCC contain
303 their own documentation and can be found in the source distribution.
304 If you want the latest unreleased software, the complete source package
305 is available directly by anonymous CVS on cvs.sdcc.sourceforge.net.
308 Wishes for the future
311 There are (and always will be) some things that could be done.
312 Here are some I can think of:
319 char KernelFunction3(char p) at 0x340;
325 If you can think of some more, please send them to the list.
331 <pending: And then of course a proper index-table
332 \begin_inset LatexCommand \index{index}
342 Install and search paths
345 Linux (and other gcc-builds like Solaris, Cygwin, Mingw and OSX) by default
346 install in /usr/local.
347 You can override this when configuring with --prefix-path.
348 Subdirs used will be bin, share/sdcc/include, share/sdcc/lib and share/sdcc/doc.
350 Windows MSVC and Borland builds will install in one single tree (e.g.
351 /sdcc) with subdirs bin, lib, include and doc.
355 The paths searched when running the compiler are as follows (the first catch
359 Binary files (preprocessor, assembler and linker):
361 - the path of argv[0] (if available)
364 \begin_inset Quotes sld
368 \begin_inset Quotes srd
374 \begin_inset Quotes sld
378 \begin_inset Quotes srd
391 \begin_inset Quotes sld
395 \begin_inset Quotes srd
401 \begin_inset Quotes sld
406 - /usr/local/share/sdcc/include (gcc builds)
408 - path(arv[0])/../include and then /sdcc/include (windoze msvc and borland
416 is auto-appended by the compiler, e.g.
417 small, large, z80, ds390 etc.):
422 \begin_inset Quotes sld
426 \begin_inset Quotes srd
436 \begin_inset Quotes sld
440 \begin_inset Quotes srd
449 - /usr/local/share/sdcc/lib/
455 - path(argv[0])/../lib/
463 (windoze msvc and borland builds)
466 Documentation (although never really searched for, you have to do that yourself
470 \begin_inset Quotes sld
474 \begin_inset Quotes srd
479 - /usr/local/share/sdcc/doc (gcc builds)
481 - /sdcc/doc (windoze msvc and borland builds)
484 So, for windoze it is highly recommended to set the environment variable
485 SDCCHOME to prevent needless usage of -I and -L.
488 Linux and other gcc-based systems (cygwin, mingw, osx)
493 Download the source package
495 either from the SDCC CVS repository or from the
496 \begin_inset LatexCommand \url[nightly snapshots]{http://sdcc.sourceforge.net/snap.php}
502 , it will be named something like sdcc
511 Bring up a command line terminal, such as xterm.
516 Unpack the file using a command like:
519 "tar -xzf sdcc.src.tgz
524 , this will create a sub-directory called sdcc with all of the sources.
527 Change directory into the main SDCC directory, for example type:
544 This configures the package for compilation on your system.
560 All of the source packages will compile, this can take a while.
576 This copies the binary executables, the include files, the libraries and
577 the documentation to the install directories.
581 \layout Subsubsection
583 Windows Install Using a Binary Package
586 Download the binary package and unpack it using your favorite unpacking
587 tool (gunzip, WinZip, etc).
588 This should unpack to a group of sub-directories.
589 An example directory structure after unpacking the mingw package is: c:
595 bin for the executables, c:
615 lib for the include and libraries.
618 Adjust your environment variable PATH to include the location of the bin
619 directory or start sdcc using the full path.
620 \layout Subsubsection
622 Windows Install Using Cygwin and Mingw
625 Follow the instruction in
627 Linux and other gcc-based systems
630 \layout Subsubsection
632 Windows Install Using Microsoft Visual C++ 6.0/NET
637 Download the source package
639 either from the SDCC CVS repository or from the
640 \begin_inset LatexCommand \url[nightly snapshots]{http://sdcc.sourceforge.net/snap.php}
646 , it will be named something like sdcc
653 SDCC is distributed with all the projects, workspaces, and files you need
654 to build it using Visual C++ 6.0/NET.
655 The workspace name is 'sdcc.dsw'.
656 Please note that as it is now, all the executables are created in a folder
660 Once built you need to copy the executables from sdcc
664 bin before runnng SDCC.
669 In order to build SDCC with Visual C++ 6.0/NET you need win32 executables
670 of bison.exe, flex.exe, and gawk.exe.
671 One good place to get them is
672 \begin_inset LatexCommand \url[here]{http://unxutils.sourceforge.net}
680 Download the file UnxUtils.zip.
681 Now you have to install the utilities and setup Visual C++ so it can locate
682 the required programs.
683 Here there are two alternatives (choose one!):
690 a) Extract UnxUtils.zip to your C:
692 hard disk PRESERVING the original paths, otherwise bison won't work.
693 (If you are using WinZip make certain that 'Use folder names' is selected)
697 b) In the Visual C++ IDE click Tools, Options, select the Directory tab,
698 in 'Show directories for:' select 'Executable files', and in the directories
699 window add a new path: 'C:
709 (As a side effect, you get a bunch of Unix utilities that could be useful,
710 such as diff and patch.)
717 This one avoids extracting a bunch of files you may not use, but requires
722 a) Create a directory were to put the tools needed, or use a directory already
730 b) Extract 'bison.exe', 'bison.hairy', 'bison.simple', 'flex.exe', and gawk.exe
731 to such directory WITHOUT preserving the original paths.
732 (If you are using WinZip make certain that 'Use folder names' is not selected)
736 c) Rename bison.exe to '_bison.exe'.
740 d) Create a batch file 'bison.bat' in 'C:
744 ' and add these lines:
764 _bison %1 %2 %3 %4 %5 %6 %7 %8 %9
768 Steps 'c' and 'd' are needed because bison requires by default that the
769 files 'bison.simple' and 'bison.hairy' reside in some weird Unix directory,
770 '/usr/local/share/' I think.
771 So it is necessary to tell bison where those files are located if they
772 are not in such directory.
773 That is the function of the environment variables BISON_SIMPLE and BISON_HAIRY.
777 e) In the Visual C++ IDE click Tools, Options, select the Directory tab,
778 in 'Show directories for:' select 'Executable files', and in the directories
779 window add a new path: 'c:
782 Note that you can use any other path instead of 'c:
784 util', even the path where the Visual C++ tools are, probably: 'C:
788 Microsoft Visual Studio
793 So you don't have to execute step 'e' :)
797 Open 'sdcc.dsw' in Visual Studio, click 'build all', when it finishes copy
798 the executables from sdcc
802 bin, and you can compile using sdcc.
803 \layout Subsubsection
805 Windows Install Using Borland ......
813 Testing out the SDCC Compiler
816 The first thing you should do after installing your SDCC compiler is to
824 at the prompt, and the program should run and tell you the version.
825 If it doesn't run, or gives a message about not finding sdcc program, then
826 you need to check over your installation.
827 Make sure that the sdcc bin directory is in your executable search path
828 defined by the PATH environment setting (see the Trouble-shooting section
830 Make sure that the sdcc program is in the bin folder, if not perhaps something
831 did not install correctly.
837 SDCC binaries are commonly installed in a directory arrangement like this:
845 <lyxtabular version="3" rows="3" columns="2">
847 <column alignment="left" valignment="top" leftline="true" width="0(null)">
848 <column alignment="left" valignment="top" leftline="true" rightline="true" width="0(null)">
849 <row topline="true" bottomline="true">
850 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
860 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
867 Holds executables(sdcc, s51, aslink,
876 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
883 usr/local/share/sdcc/lib
886 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
899 <row topline="true" bottomline="true">
900 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
907 usr/local/share/sdcc/include
910 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
917 Holds common C header files
931 Make sure the compiler works on a very simple example.
932 Type in the following test.c program using your favorite editor:
963 Compile this using the following command:
972 If all goes well, the compiler will generate a test.asm and test.rel file.
973 Congratulations, you've just compiled your first program with SDCC.
974 We used the -c option to tell SDCC not to link the generated code, just
975 to keep things simple for this step.
983 The next step is to try it with the linker.
993 If all goes well the compiler will link with the libraries and produce
994 a test.ihx output file.
999 (no test.ihx, and the linker generates warnings), then the problem is most
1000 likely that sdcc cannot find the
1004 usr/local/share/sdcc/lib directory
1008 (see the Install trouble-shooting section for suggestions).
1016 The final test is to ensure sdcc can use the
1020 header files and libraries.
1021 Edit test.c and change it to the following:
1041 strcpy(str1, "testing");
1050 Compile this by typing
1057 This should generate a test.ihx output file, and it should give no warnings
1058 such as not finding the string.h file.
1059 If it cannot find the string.h file, then the problem is that sdcc cannot
1060 find the /usr/local/share/sdcc/include directory
1064 (see the Install trouble-shooting section for suggestions).
1067 Install Trouble-shooting
1068 \layout Subsubsection
1070 SDCC does not build correctly.
1073 A thing to try is starting from scratch by unpacking the .tgz source package
1074 again in an empty directory.
1081 ./configure 2>&1 | tee configure.log
1093 make 2>&1 | tee make.log
1099 If anything goes wrong, you can review the log files to locate the problem.
1100 Or a relevant part of this can be attached to an email that could be helpful
1101 when requesting help from the mailing list.
1102 \layout Subsubsection
1105 \begin_inset Quotes sld
1109 \begin_inset Quotes srd
1116 \begin_inset Quotes sld
1120 \begin_inset Quotes srd
1123 command is a script that analyzes your system and performs some configuration
1124 to ensure the source package compiles on your system.
1125 It will take a few minutes to run, and will compile a few tests to determine
1126 what compiler features are installed.
1127 \layout Subsubsection
1130 \begin_inset Quotes sld
1134 \begin_inset Quotes srd
1140 This runs the GNU make tool, which automatically compiles all the source
1141 packages into the final installed binary executables.
1142 \layout Subsubsection
1145 \begin_inset Quotes sld
1149 \begin_inset Quotes erd
1155 This will install the compiler, other executables and libraries in to the
1156 appropriate system directories.
1157 The default is to copy the executables to /usr/local/bin and the libraries
1158 and header files to /usr/local/share/sdcc/lib and /usr/local/share/sdcc/include.
1159 On most systems you will need super-user privilages to do this.
1162 Advanced Install Options
1166 \begin_inset Quotes eld
1170 \begin_inset Quotes erd
1173 command has several options.
1174 The most commonly used option is --prefix=<directory name>, where <directory
1175 name> is the final location for the sdcc executables and libraries, (default
1176 location is /usr/local).
1177 The installation process will create the following directory structure
1178 under the <directory name> specified (if they do not already exist).
1183 bin/ - binary exectables (add to PATH environment variable)
1187 bin/share/sdcc/include/ - include header files
1191 bin/share/sdcc/lib/small/ - Object & library files for small model library
1193 bin/share/sdcc/lib/large/ - Object & library files for large model library
1195 bin/share/sdcc/lib/ds390/ - Object & library files for DS80C390 library
1197 bin/share/sdcc/lib/z80/ - Object & library files for Z80 library
1205 \begin_inset Quotes sld
1208 ./configure --prefix=/usr/local
1209 \begin_inset Quotes erd
1215 will configure the compiler to be installed in directory /usr/local.
1221 SDCC is not just a compiler, but a collection of tools by various developers.
1222 These include linkers, assemblers, simulators and other components.
1223 Here is a summary of some of the components.
1224 Note that the included simulator and assembler have separate documentation
1225 which you can find in the source package in their respective directories.
1226 As SDCC grows to include support for other processors, other packages from
1227 various developers are included and may have their own sets of documentation.
1231 You might want to look at the files which are installed in <installdir>.
1232 At the time of this writing, we find the following programs:
1236 In <installdir>/bin:
1239 sdcc - The compiler.
1242 sdcpp - The C preprocessor.
1245 asx8051 - The assembler for 8051 type processors.
1252 as-gbz80 - The Z80 and GameBoy Z80 assemblers.
1255 aslink -The linker for 8051 type processors.
1262 link-gbz80 - The Z80 and GameBoy Z80 linkers.
1265 s51 - The ucSim 8051 simulator.
1268 sdcdb - The source debugger.
1271 packihx - A tool to pack (compress) Intel hex files.
1274 In <installdir>/share/sdcc/include
1280 In <installdir>/share/sdcc/lib
1283 the sources of the runtime library and the subdirs small large and ds390
1284 with the precompiled relocatables.
1287 In <installdir>/share/sdcc/doc
1293 As development for other processors proceeds, this list will expand to include
1294 executables to support processors like AVR, PIC, etc.
1295 \layout Subsubsection
1300 This is the actual compiler, it in turn uses the c-preprocessor and invokes
1301 the assembler and linkage editor.
1302 \layout Subsubsection
1304 sdcpp - The C-Preprocessor)
1307 The preprocessor is a modified version of the GNU preprocessor.
1308 The C preprocessor is used to pull in #include sources, process #ifdef
1309 statements, #defines and so on.
1310 \layout Subsubsection
1312 asx8051, as-z80, as-gbz80, aslink, link-z80, link-gbz80 - The Assemblers
1316 This is retargettable assembler & linkage editor, it was developed by Alan
1318 John Hartman created the version for 8051, and I (Sandeep) have made some
1319 enhancements and bug fixes for it to work properly with the SDCC.
1320 \layout Subsubsection
1325 S51 is a freeware, opensource simulator developed by Daniel Drotos (
1326 \begin_inset LatexCommand \url{mailto:drdani@mazsola.iit.uni-miskolc.hu}
1331 The simulator is built as part of the build process.
1332 For more information visit Daniel's website at:
1333 \begin_inset LatexCommand \url{http://mazsola.iit.uni-miskolc.hu/~drdani/embedded/s51}
1338 It currently support the core mcs51, the Dallas DS80C390 and the Philips
1340 \layout Subsubsection
1342 sdcdb - Source Level Debugger
1348 <todo: is this thing alive?>
1355 Sdcdb is the companion source level debugger.
1356 The current version of the debugger uses Daniel's Simulator S51, but can
1357 be easily changed to use other simulators.
1364 \layout Subsubsection
1366 Single Source File Projects
1369 For single source file 8051 projects the process is very simple.
1370 Compile your programs with the following command
1373 "sdcc sourcefile.c".
1377 This will compile, assemble and link your source file.
1378 Output files are as follows
1382 sourcefile.asm - Assembler source file created by the compiler
1384 sourcefile.lst - Assembler listing file created by the Assembler
1386 sourcefile.rst - Assembler listing file updated with linkedit information,
1387 created by linkage editor
1389 sourcefile.sym - symbol listing for the sourcefile, created by the assembler
1391 sourcefile.rel - Object file created by the assembler, input to Linkage editor
1393 sourcefile.map - The memory map for the load module, created by the Linker
1395 sourcefile.ihx - The load module in Intel hex format (you can select the
1396 Motorola S19 format with --out-fmt-s19)
1398 sourcefile.cdb - An optional file (with --debug) containing debug information
1401 \layout Subsubsection
1403 Projects with Multiple Source Files
1406 SDCC can compile only ONE file at a time.
1407 Let us for example assume that you have a project containing the following
1412 foo1.c (contains some functions)
1414 foo2.c (contains some more functions)
1416 foomain.c (contains more functions and the function main)
1424 The first two files will need to be compiled separately with the commands:
1456 Then compile the source file containing the
1460 function and link the files together with the following command:
1468 foomain.c\SpecialChar ~
1469 foo1.rel\SpecialChar ~
1481 can be separately compiled as well:
1492 sdcc foomain.rel foo1.rel foo2.rel
1499 The file containing the
1514 file specified in the command line, since the linkage editor processes
1515 file in the order they are presented to it.
1516 \layout Subsubsection
1518 Projects with Additional Libraries
1521 Some reusable routines may be compiled into a library, see the documentation
1522 for the assembler and linkage editor (which are in <installdir>/share/sdcc/doc)
1528 Libraries created in this manner can be included in the command line.
1529 Make sure you include the -L <library-path> option to tell the linker where
1530 to look for these files if they are not in the current directory.
1531 Here is an example, assuming you have the source file
1543 (if that is not the same as your current project):
1550 sdcc foomain.c foolib.lib -L mylib
1561 must be an absolute path name.
1565 The most efficient way to use libraries is to keep seperate modules in seperate
1567 The lib file now should name all the modules.rel files.
1568 For an example see the standard library file
1572 in the directory <installdir>/share/lib/small.
1575 Command Line Options
1576 \layout Subsubsection
1578 Processor Selection Options
1580 \labelwidthstring 00.00.0000
1586 Generate code for the MCS51 (8051) family of processors.
1587 This is the default processor target.
1589 \labelwidthstring 00.00.0000
1595 Generate code for the DS80C390 processor.
1597 \labelwidthstring 00.00.0000
1603 Generate code for the Z80 family of processors.
1605 \labelwidthstring 00.00.0000
1611 Generate code for the GameBoy Z80 processor.
1613 \labelwidthstring 00.00.0000
1619 Generate code for the Atmel AVR processor (In development, not complete).
1621 \labelwidthstring 00.00.0000
1627 Generate code for the PIC 14-bit processors (In development, not complete).
1629 \labelwidthstring 00.00.0000
1635 Generate code for the Toshiba TLCS-900H processor (In development, not
1638 \labelwidthstring 00.00.0000
1644 Generate code for the Philips XA51 processor (In development, not complete).
1645 \layout Subsubsection
1647 Preprocessor Options
1649 \labelwidthstring 00.00.0000
1655 The additional location where the pre processor will look for <..h> or
1656 \begin_inset Quotes eld
1660 \begin_inset Quotes erd
1665 \labelwidthstring 00.00.0000
1671 Command line definition of macros.
1672 Passed to the pre processor.
1674 \labelwidthstring 00.00.0000
1680 Tell the preprocessor to output a rule suitable for make describing the
1681 dependencies of each object file.
1682 For each source file, the preprocessor outputs one make-rule whose target
1683 is the object file name for that source file and whose dependencies are
1684 all the files `#include'd in it.
1685 This rule may be a single line or may be continued with `
1687 '-newline if it is long.
1688 The list of rules is printed on standard output instead of the preprocessed
1692 \labelwidthstring 00.00.0000
1698 Tell the preprocessor not to discard comments.
1699 Used with the `-E' option.
1701 \labelwidthstring 00.00.0000
1712 Like `-M' but the output mentions only the user header files included with
1714 \begin_inset Quotes eld
1718 System header files included with `#include <file>' are omitted.
1720 \labelwidthstring 00.00.0000
1726 Assert the answer answer for question, in case it is tested with a preprocessor
1727 conditional such as `#if #question(answer)'.
1728 `-A-' disables the standard assertions that normally describe the target
1731 \labelwidthstring 00.00.0000
1737 (answer) Assert the answer answer for question, in case it is tested with
1738 a preprocessor conditional such as `#if #question(answer)'.
1739 `-A-' disables the standard assertions that normally describe the target
1742 \labelwidthstring 00.00.0000
1748 Undefine macro macro.
1749 `-U' options are evaluated after all `-D' options, but before any `-include'
1750 and `-imacros' options.
1752 \labelwidthstring 00.00.0000
1758 Tell the preprocessor to output only a list of the macro definitions that
1759 are in effect at the end of preprocessing.
1760 Used with the `-E' option.
1762 \labelwidthstring 00.00.0000
1768 Tell the preprocessor to pass all macro definitions into the output, in
1769 their proper sequence in the rest of the output.
1771 \labelwidthstring 00.00.0000
1782 Like `-dD' except that the macro arguments and contents are omitted.
1783 Only `#define name' is included in the output.
1784 \layout Subsubsection
1788 \labelwidthstring 00.00.0000
1795 the output path resp.
1796 file where everything will be placed
1798 \labelwidthstring 00.00.0000
1808 <absolute path to additional libraries> This option is passed to the linkage
1809 editor's additional libraries search path.
1810 The path name must be absolute.
1811 Additional library files may be specified in the command line.
1812 See section Compiling programs for more details.
1814 \labelwidthstring 00.00.0000
1820 <Value> The start location of the external ram, default value is 0.
1821 The value entered can be in Hexadecimal or Decimal format, e.g.: --xram-loc
1822 0x8000 or --xram-loc 32768.
1824 \labelwidthstring 00.00.0000
1830 <Value> The start location of the code segment, default value 0.
1831 Note when this option is used the interrupt vector table is also relocated
1832 to the given address.
1833 The value entered can be in Hexadecimal or Decimal format, e.g.: --code-loc
1834 0x8000 or --code-loc 32768.
1836 \labelwidthstring 00.00.0000
1842 <Value> By default the stack is placed after the data segment.
1843 Using this option the stack can be placed anywhere in the internal memory
1845 The value entered can be in Hexadecimal or Decimal format, e.g.
1846 --stack-loc 0x20 or --stack-loc 32.
1847 Since the sp register is incremented before a push or call, the initial
1848 sp will be set to one byte prior the provided value.
1849 The provided value should not overlap any other memory areas such as used
1850 register banks or the data segment and with enough space for the current
1853 \labelwidthstring 00.00.0000
1859 <Value> The start location of the internal ram data segment.
1860 The value entered can be in Hexadecimal or Decimal format, eg.
1861 --data-loc 0x20 or --data-loc 32.
1862 (By default, the start location of the internal ram data segment is set
1863 as low as possible in memory, taking into account the used register banks
1864 and the bit segment at address 0x20.
1865 For example if register banks 0 and 1 are used without bit variables, the
1866 data segment will be set, if --data-loc is not used, to location 0x10.)
1868 \labelwidthstring 00.00.0000
1874 <Value> The start location of the indirectly addressable internal ram, default
1876 The value entered can be in Hexadecimal or Decimal format, eg.
1877 --idata-loc 0x88 or --idata-loc 136.
1879 \labelwidthstring 00.00.0000
1888 The linker output (final object code) is in Intel Hex format.
1889 (This is the default option).
1891 \labelwidthstring 00.00.0000
1900 The linker output (final object code) is in Motorola S19 format.
1901 \layout Subsubsection
1905 \labelwidthstring 00.00.0000
1911 Generate code for Large model programs see section Memory Models for more
1913 If this option is used all source files in the project should be compiled
1915 In addition the standard library routines are compiled with small model,
1916 they will need to be recompiled.
1918 \labelwidthstring 00.00.0000
1929 Generate code for Small Model programs see section Memory Models for more
1931 This is the default model.
1932 \layout Subsubsection
1936 \labelwidthstring 00.00.0000
1947 Generate 24-bit flat mode code.
1948 This is the one and only that the ds390 code generator supports right now
1949 and is default when using
1954 See section Memory Models for more details.
1956 \labelwidthstring 00.00.0000
1962 Generate code for the 10 bit stack mode of the Dallas DS80C390 part.
1963 This is the one and only that the ds390 code generator supports right now
1964 and is default when using
1969 In this mode, the stack is located in the lower 1K of the internal RAM,
1970 which is mapped to 0x400000.
1971 Note that the support is incomplete, since it still uses a single byte
1972 as the stack pointer.
1973 This means that only the lower 256 bytes of the potential 1K stack space
1974 will actually be used.
1975 However, this does allow you to reclaim the precious 256 bytes of low RAM
1976 for use for the DATA and IDATA segments.
1977 The compiler will not generate any code to put the processor into 10 bit
1979 It is important to ensure that the processor is in this mode before calling
1980 any re-entrant functions compiled with this option.
1981 In principle, this should work with the
1985 option, but that has not been tested.
1986 It is incompatible with the
1991 It also only makes sense if the processor is in 24 bit contiguous addressing
1994 --model-flat24 option
1997 \layout Subsubsection
1999 Optimization Options
2001 \labelwidthstring 00.00.0000
2007 Will not do global subexpression elimination, this option may be used when
2008 the compiler creates undesirably large stack/data spaces to store compiler
2010 A warning message will be generated when this happens and the compiler
2011 will indicate the number of extra bytes it allocated.
2012 It recommended that this option NOT be used, #pragma\SpecialChar ~
2014 to turn off global subexpression elimination for a given function only.
2016 \labelwidthstring 00.00.0000
2022 Will not do loop invariant optimizations, this may be turned off for reasons
2023 explained for the previous option.
2024 For more details of loop optimizations performed see section Loop Invariants.It
2025 recommended that this option NOT be used, #pragma\SpecialChar ~
2026 NOINVARIANT can be used
2027 to turn off invariant optimizations for a given function only.
2029 \labelwidthstring 00.00.0000
2035 Will not do loop induction optimizations, see section strength reduction
2036 for more details.It is recommended that this option is NOT used, #pragma\SpecialChar ~
2038 ION can be used to turn off induction optimizations for a given function
2041 \labelwidthstring 00.00.0000
2052 Will not generate boundary condition check when switch statements are implement
2053 ed using jump-tables.
2054 See section Switch Statements for more details.
2055 It is recommended that this option is NOT used, #pragma\SpecialChar ~
2057 used to turn off boundary checking for jump tables for a given function
2060 \labelwidthstring 00.00.0000
2069 Will not do loop reversal optimization.
2071 \labelwidthstring 00.00.0000
2077 This will disable the memcpy of initialized data in far space from code
2079 \layout Subsubsection
2083 \labelwidthstring 00.00.0000
2090 will compile and assemble the source, but will not call the linkage editor.
2092 \labelwidthstring 00.00.0000
2098 Run only the C preprocessor.
2099 Preprocess all the C source files specified and output the results to standard
2102 \labelwidthstring 00.00.0000
2113 All functions in the source file will be compiled as
2118 the parameters and local variables will be allocated on the stack.
2119 see section Parameters and Local Variables for more details.
2120 If this option is used all source files in the project should be compiled
2124 \labelwidthstring 00.00.0000
2130 Uses a pseudo stack in the first 256 bytes in the external ram for allocating
2131 variables and passing parameters.
2132 See section on external stack for more details.
2134 \labelwidthstring 00.00.0000
2138 --callee-saves function1[,function2][,function3]....
2141 The compiler by default uses a caller saves convention for register saving
2142 across function calls, however this can cause unneccessary register pushing
2143 & popping when calling small functions from larger functions.
2144 This option can be used to switch the register saving convention for the
2145 function names specified.
2146 The compiler will not save registers when calling these functions, no extra
2147 code will be generated at the entry & exit for these functions to save
2148 & restore the registers used by these functions, this can SUBSTANTIALLY
2149 reduce code & improve run time performance of the generated code.
2150 In the future the compiler (with interprocedural analysis) will be able
2151 to determine the appropriate scheme to use for each function call.
2152 DO NOT use this option for built-in functions such as _muluint..., if this
2153 option is used for a library function the appropriate library function
2154 needs to be recompiled with the same option.
2155 If the project consists of multiple source files then all the source file
2156 should be compiled with the same --callee-saves option string.
2157 Also see #pragma\SpecialChar ~
2160 \labelwidthstring 00.00.0000
2169 When this option is used the compiler will generate debug information, that
2170 can be used with the SDCDB.
2171 The debug information is collected in a file with .cdb extension.
2172 For more information see documentation for SDCDB.
2174 \labelwidthstring 00.00.0000
2180 <filename> This option can be used to use additional rules to be used by
2181 the peep hole optimizer.
2182 See section Peep Hole optimizations for details on how to write these rules.
2184 \labelwidthstring 00.00.0000
2195 Stop after the stage of compilation proper; do not assemble.
2196 The output is an assembler code file for the input file specified.
2198 \labelwidthstring 00.00.0000
2202 -Wa_asmOption[,asmOption]
2205 Pass the asmOption to the assembler.
2207 \labelwidthstring 00.00.0000
2211 -Wl_linkOption[,linkOption]
2214 Pass the linkOption to the linker.
2216 \labelwidthstring 00.00.0000
2225 Integer (16 bit) and long (32 bit) libraries have been compiled as reentrant.
2226 Note by default these libraries are compiled as non-reentrant.
2227 See section Installation for more details.
2229 \labelwidthstring 00.00.0000
2238 This option will cause the compiler to generate an information message for
2239 each function in the source file.
2240 The message contains some
2244 information about the function.
2245 The number of edges and nodes the compiler detected in the control flow
2246 graph of the function, and most importantly the
2248 cyclomatic complexity
2250 see section on Cyclomatic Complexity for more details.
2252 \labelwidthstring 00.00.0000
2261 Floating point library is compiled as reentrant.See section Installation
2264 \labelwidthstring 00.00.0000
2270 The compiler will not overlay parameters and local variables of any function,
2271 see section Parameters and local variables for more details.
2273 \labelwidthstring 00.00.0000
2279 This option can be used when the code generated is called by a monitor
2281 The compiler will generate a 'ret' upon return from the 'main' function.
2282 The default option is to lock up i.e.
2285 \labelwidthstring 00.00.0000
2291 Disable peep-hole optimization.
2293 \labelwidthstring 00.00.0000
2299 Pass the inline assembler code through the peep hole optimizer.
2300 This can cause unexpected changes to inline assembler code, please go through
2301 the peephole optimizer rules defined in the source file tree '<target>/peeph.def
2302 ' before using this option.
2304 \labelwidthstring 00.00.0000
2310 <Value> Causes the linker to check if the internal ram usage is within limits
2313 \labelwidthstring 00.00.0000
2319 <Value> Causes the linker to check if the external ram usage is within limits
2322 \labelwidthstring 00.00.0000
2328 <Value> Causes the linker to check if the code usage is within limits of
2331 \labelwidthstring 00.00.0000
2337 This will prevent the compiler from passing on the default include path
2338 to the preprocessor.
2340 \labelwidthstring 00.00.0000
2346 This will prevent the compiler from passing on the default library path
2349 \labelwidthstring 00.00.0000
2355 Shows the various actions the compiler is performing.
2357 \labelwidthstring 00.00.0000
2363 Shows the actual commands the compiler is executing.
2364 \layout Subsubsection
2366 Intermediate Dump Options
2369 The following options are provided for the purpose of retargetting and debugging
2371 These provided a means to dump the intermediate code (iCode) generated
2372 by the compiler in human readable form at various stages of the compilation
2376 \labelwidthstring 00.00.0000
2382 This option will cause the compiler to dump the intermediate code into
2385 <source filename>.dumpraw
2387 just after the intermediate code has been generated for a function, i.e.
2388 before any optimizations are done.
2389 The basic blocks at this stage ordered in the depth first number, so they
2390 may not be in sequence of execution.
2392 \labelwidthstring 00.00.0000
2398 Will create a dump of iCode's, after global subexpression elimination,
2401 <source filename>.dumpgcse.
2403 \labelwidthstring 00.00.0000
2409 Will create a dump of iCode's, after deadcode elimination, into a file
2412 <source filename>.dumpdeadcode.
2414 \labelwidthstring 00.00.0000
2423 Will create a dump of iCode's, after loop optimizations, into a file named
2426 <source filename>.dumploop.
2428 \labelwidthstring 00.00.0000
2437 Will create a dump of iCode's, after live range analysis, into a file named
2440 <source filename>.dumprange.
2442 \labelwidthstring 00.00.0000
2448 Will dump the life ranges for all symbols.
2450 \labelwidthstring 00.00.0000
2459 Will create a dump of iCode's, after register assignment, into a file named
2462 <source filename>.dumprassgn.
2464 \labelwidthstring 00.00.0000
2470 Will create a dump of the live ranges of iTemp's
2472 \labelwidthstring 00.00.0000
2483 Will cause all the above mentioned dumps to be created.
2486 MCS51/DS390 Storage Class Language Extensions
2489 In addition to the ANSI storage classes SDCC allows the following MCS51
2490 specific storage classes.
2491 \layout Subsubsection
2496 Variables declared with this storage class will be placed in the extern
2502 storage class for Large Memory model, e.g.:
2508 xdata unsigned char xduc;
2509 \layout Subsubsection
2518 storage class for Small Memory model.
2519 Variables declared with this storage class will be allocated in the internal
2527 \layout Subsubsection
2532 Variables declared with this storage class will be allocated into the indirectly
2533 addressable portion of the internal ram of a 8051, e.g.:
2540 \layout Subsubsection
2545 This is a data-type and a storage class specifier.
2546 When a variable is declared as a bit, it is allocated into the bit addressable
2547 memory of 8051, e.g.:
2554 \layout Subsubsection
2559 Like the bit keyword,
2563 signifies both a data-type and storage class, they are used to describe
2564 the special function registers and special bit variables of a 8051, eg:
2570 sfr at 0x80 P0; /* special function register P0 at location 0x80 */
2572 sbit at 0xd7 CY; /* CY (Carry Flag) */
2578 SDCC allows (via language extensions) pointers to explicitly point to any
2579 of the memory spaces of the 8051.
2580 In addition to the explicit pointers, the compiler uses (by default) generic
2581 pointers which can be used to point to any of the memory spaces.
2585 Pointer declaration examples:
2594 /* pointer physically in xternal ram pointing to object in internal ram
2597 data unsigned char * xdata p;
2601 /* pointer physically in code rom pointing to data in xdata space */
2603 xdata unsigned char * code p;
2607 /* pointer physically in code space pointing to data in code space */
2609 code unsigned char * code p;
2613 /* the folowing is a generic pointer physically located in xdata space */
2624 Well you get the idea.
2629 All unqualified pointers are treated as 3-byte (4-byte for the ds390)
2642 The highest order byte of the
2646 pointers contains the data space information.
2647 Assembler support routines are called whenever data is stored or retrieved
2653 These are useful for developing reusable library routines.
2654 Explicitly specifying the pointer type will generate the most efficient
2658 Parameters & Local Variables
2661 Automatic (local) variables and parameters to functions can either be placed
2662 on the stack or in data-space.
2663 The default action of the compiler is to place these variables in the internal
2664 RAM (for small model) or external RAM (for large model).
2665 This in fact makes them
2669 so by default functions are non-reentrant.
2673 They can be placed on the stack either by using the
2677 option or by using the
2681 keyword in the function declaration, e.g.:
2690 unsigned char foo(char i) reentrant
2703 Since stack space on 8051 is limited, the
2711 option should be used sparingly.
2712 Note that the reentrant keyword just means that the parameters & local
2713 variables will be allocated to the stack, it
2717 mean that the function is register bank independent.
2721 Local variables can be assigned storage classes and absolute addresses,
2728 unsigned char foo() {
2734 xdata unsigned char i;
2746 data at 0x31 unsiged char j;
2761 In the above example the variable
2765 will be allocated in the external ram,
2769 in bit addressable space and
2778 or when a function is declared as
2782 this should only be done for static variables.
2785 Parameters however are not allowed any storage class, (storage classes for
2786 parameters will be ignored), their allocation is governed by the memory
2787 model in use, and the reentrancy options.
2793 For non-reentrant functions SDCC will try to reduce internal ram space usage
2794 by overlaying parameters and local variables of a function (if possible).
2795 Parameters and local variables of a function will be allocated to an overlayabl
2796 e segment if the function has
2798 no other function calls and the function is non-reentrant and the memory
2802 If an explicit storage class is specified for a local variable, it will
2806 Note that the compiler (not the linkage editor) makes the decision for overlayin
2808 Functions that are called from an interrupt service routine should be preceded
2809 by a #pragma\SpecialChar ~
2810 NOOVERLAY if they are not reentrant.
2813 Also note that the compiler does not do any processing of inline assembler
2814 code, so the compiler might incorrectly assign local variables and parameters
2815 of a function into the overlay segment if the inline assembler code calls
2816 other c-functions that might use the overlay.
2817 In that case the #pragma\SpecialChar ~
2818 NOOVERLAY should be used.
2821 Parameters and Local variables of functions that contain 16 or 32 bit multiplica
2822 tion or division will NOT be overlayed since these are implemented using
2823 external functions, e.g.:
2833 void set_error(unsigned char errcd)
2849 void some_isr () interrupt 2 using 1
2878 In the above example the parameter
2886 would be assigned to the overlayable segment if the #pragma\SpecialChar ~
2888 not present, this could cause unpredictable runtime behavior when called
2890 The #pragma\SpecialChar ~
2891 NOOVERLAY ensures that the parameters and local variables for
2892 the function are NOT overlayed.
2895 Interrupt Service Routines
2898 SDCC allows interrupt service routines to be coded in C, with some extended
2905 void timer_isr (void) interrupt 2 using 1
2918 The number following the
2922 keyword is the interrupt number this routine will service.
2923 The compiler will insert a call to this routine in the interrupt vector
2924 table for the interrupt number specified.
2929 keyword is used to tell the compiler to use the specified register bank
2930 (8051 specific) when generating code for this function.
2931 Note that when some function is called from an interrupt service routine
2932 it should be preceded by a #pragma\SpecialChar ~
2933 NOOVERLAY if it is not reentrant.
2934 A special note here, int (16 bit) and long (32 bit) integer division, multiplic
2935 ation & modulus operations are implemented using external support routines
2936 developed in ANSI-C, if an interrupt service routine needs to do any of
2937 these operations then the support routines (as mentioned in a following
2938 section) will have to be recompiled using the
2942 option and the source file will need to be compiled using the
2949 If you have multiple source files in your project, interrupt service routines
2950 can be present in any of them, but a prototype of the isr MUST be present
2951 or included in the file that contains the function
2958 Interrupt Numbers and the corresponding address & descriptions for the Standard
2959 8051 are listed below.
2960 SDCC will automatically adjust the interrupt vector table to the maximum
2961 interrupt number specified.
2967 \begin_inset Tabular
2968 <lyxtabular version="3" rows="6" columns="3">
2970 <column alignment="center" valignment="top" leftline="true" width="0(null)">
2971 <column alignment="center" valignment="top" leftline="true" width="0(null)">
2972 <column alignment="center" valignment="top" leftline="true" rightline="true" width="0(null)">
2973 <row topline="true" bottomline="true">
2974 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
2982 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
2990 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
2999 <row topline="true">
3000 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3008 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3016 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
3025 <row topline="true">
3026 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3034 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3042 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
3051 <row topline="true">
3052 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3060 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3068 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
3077 <row topline="true">
3078 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3086 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3094 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
3103 <row topline="true" bottomline="true">
3104 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3112 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3120 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
3137 If the interrupt service routine is defined without
3141 a register bank or with register bank 0 (using 0), the compiler will save
3142 the registers used by itself on the stack upon entry and restore them at
3143 exit, however if such an interrupt service routine calls another function
3144 then the entire register bank will be saved on the stack.
3145 This scheme may be advantageous for small interrupt service routines which
3146 have low register usage.
3149 If the interrupt service routine is defined to be using a specific register
3154 are save and restored, if such an interrupt service routine calls another
3155 function (using another register bank) then the entire register bank of
3156 the called function will be saved on the stack.
3157 This scheme is recommended for larger interrupt service routines.
3160 Calling other functions from an interrupt service routine is not recommended,
3161 avoid it if possible.
3165 Also see the _naked modifier.
3173 <TODO: this isn't implemented at all!>
3179 A special keyword may be associated with a function declaring it as
3184 SDCC will generate code to disable all interrupts upon entry to a critical
3185 function and enable them back before returning.
3186 Note that nesting critical functions may cause unpredictable results.
3211 The critical attribute maybe used with other attributes like
3219 A special keyword may be associated with a function declaring it as
3228 function modifier attribute prevents the compiler from generating prologue
3229 and epilogue code for that function.
3230 This means that the user is entirely responsible for such things as saving
3231 any registers that may need to be preserved, selecting the proper register
3232 bank, generating the
3236 instruction at the end, etc.
3237 Practically, this means that the contents of the function must be written
3238 in inline assembler.
3239 This is particularly useful for interrupt functions, which can have a large
3240 (and often unnecessary) prologue/epilogue.
3241 For example, compare the code generated by these two functions:
3247 data unsigned char counter;
3249 void simpleInterrupt(void) interrupt 1
3263 void nakedInterrupt(void) interrupt 2 _naked
3296 ; MUST explicitly include ret in _naked function.
3310 For an 8051 target, the generated simpleInterrupt looks like:
3455 whereas nakedInterrupt looks like:
3480 ; MUST explicitly include ret(i) in _naked function.
3486 While there is nothing preventing you from writing C code inside a _naked
3487 function, there are many ways to shoot yourself in the foot doing this,
3488 and is is recommended that you stick to inline assembler.
3491 Functions using private banks
3498 attribute (which tells the compiler to use a register bank other than the
3499 default bank zero) should only be applied to
3503 functions (see note 1 below).
3504 This will in most circumstances make the generated ISR code more efficient
3505 since it will not have to save registers on the stack.
3512 attribute will have no effect on the generated code for a
3516 function (but may occasionally be useful anyway
3522 possible exception: if a function is called ONLY from 'interrupt' functions
3523 using a particular bank, it can be declared with the same 'using' attribute
3524 as the calling 'interrupt' functions.
3525 For instance, if you have several ISRs using bank one, and all of them
3526 call memcpy(), it might make sense to create a specialized version of memcpy()
3527 'using 1', since this would prevent the ISR from having to save bank zero
3528 to the stack on entry and switch to bank zero before calling the function
3535 (pending: I don't think this has been done yet)
3542 function using a non-zero bank will assume that it can trash that register
3543 bank, and will not save it.
3544 Since high-priority interrupts can interrupt low-priority ones on the 8051
3545 and friends, this means that if a high-priority ISR
3549 a particular bank occurs while processing a low-priority ISR
3553 the same bank, terrible and bad things can happen.
3554 To prevent this, no single register bank should be
3558 by both a high priority and a low priority ISR.
3559 This is probably most easily done by having all high priority ISRs use
3560 one bank and all low priority ISRs use another.
3561 If you have an ISR which can change priority at runtime, you're on your
3562 own: I suggest using the default bank zero and taking the small performance
3566 It is most efficient if your ISR calls no other functions.
3567 If your ISR must call other functions, it is most efficient if those functions
3568 use the same bank as the ISR (see note 1 below); the next best is if the
3569 called functions use bank zero.
3570 It is very inefficient to call a function using a different, non-zero bank
3578 Data items can be assigned an absolute address with the
3582 keyword, in addition to a storage class, e.g.:
3588 xdata at 0x8000 unsigned char PORTA_8255 ;
3594 In the above example the PORTA_8255 will be allocated to the location 0x8000
3595 of the external ram.
3596 Note that this feature is provided to give the programmer access to
3600 devices attached to the controller.
3601 The compiler does not actually reserve any space for variables declared
3602 in this way (they are implemented with an equate in the assembler).
3603 Thus it is left to the programmer to make sure there are no overlaps with
3604 other variables that are declared without the absolute address.
3605 The assembler listing file (.lst) and the linker output files (.rst) and
3606 (.map) are a good places to look for such overlaps.
3610 Absolute address can be specified for variables in all storage classes,
3623 The above example will allocate the variable at offset 0x02 in the bit-addressab
3625 There is no real advantage to assigning absolute addresses to variables
3626 in this manner, unless you want strict control over all the variables allocated.
3632 The compiler inserts a call to the C routine
3634 _sdcc__external__startup()
3639 at the start of the CODE area.
3640 This routine is in the runtime library.
3641 By default this routine returns 0, if this routine returns a non-zero value,
3642 the static & global variable initialization will be skipped and the function
3643 main will be invoked Other wise static & global variables will be initialized
3644 before the function main is invoked.
3647 _sdcc__external__startup()
3649 routine to your program to override the default if you need to setup hardware
3650 or perform some other critical operation prior to static & global variable
3654 Inline Assembler Code
3657 SDCC allows the use of in-line assembler with a few restriction as regards
3659 All labels defined within inline assembler code
3667 where nnnn is a number less than 100 (which implies a limit of utmost 100
3668 inline assembler labels
3676 It is strongly recommended that each assembly instruction (including labels)
3677 be placed in a separate line (as the example shows).
3682 command line option is used, the inline assembler code will be passed through
3683 the peephole optimizer.
3684 This might cause some unexpected changes in the inline assembler code.
3685 Please go throught the peephole optimizer rules defined in file
3689 carefully before using this option.
3729 The inline assembler code can contain any valid code understood by the assembler
3730 , this includes any assembler directives and comment lines.
3731 The compiler does not do any validation of the code within the
3741 Inline assembler code cannot reference any C-Labels, however it can reference
3742 labels defined by the inline assembler, e.g.:
3768 ; some assembler code
3788 /* some more c code */
3790 clabel:\SpecialChar ~
3792 /* inline assembler cannot reference this label */
3804 $0003: ;label (can be reference by inline assembler only)
3816 /* some more c code */
3824 In other words inline assembly code can access labels defined in inline
3825 assembly within the scope of the funtion.
3829 The same goes the other way, ie.
3830 labels defines in inline assembly CANNOT be accessed by C statements.
3833 int(16 bit) and long (32 bit) Support
3836 For signed & unsigned int (16 bit) and long (32 bit) variables, division,
3837 multiplication and modulus operations are implemented by support routines.
3838 These support routines are all developed in ANSI-C to facilitate porting
3839 to other MCUs, although some model specific assembler optimations are used.
3840 The following files contain the described routine, all of them can be found
3841 in <installdir>/share/sdcc/lib.
3847 <pending: tabularise this>
3853 _mulsint.c - signed 16 bit multiplication (calls _muluint)
3855 _muluint.c - unsigned 16 bit multiplication
3857 _divsint.c - signed 16 bit division (calls _divuint)
3859 _divuint.c - unsigned 16 bit division
3861 _modsint.c - signed 16 bit modulus (call _moduint)
3863 _moduint.c - unsigned 16 bit modulus
3865 _mulslong.c - signed 32 bit multiplication (calls _mululong)
3867 _mululong.c - unsigned32 bit multiplication
3869 _divslong.c - signed 32 division (calls _divulong)
3871 _divulong.c - unsigned 32 division
3873 _modslong.c - signed 32 bit modulus (calls _modulong)
3875 _modulong.c - unsigned 32 bit modulus
3883 Since they are compiled as
3887 , interrupt service routines should not do any of the above operations.
3888 If this is unavoidable then the above routines will need to be compiled
3893 option, after which the source program will have to be compiled with
3900 Floating Point Support
3903 SDCC supports IEEE (single precision 4bytes) floating point numbers.The floating
3904 point support routines are derived from gcc's floatlib.c and consists of
3905 the following routines:
3911 <pending: tabularise this>
3917 _fsadd.c - add floating point numbers
3919 _fssub.c - subtract floating point numbers
3921 _fsdiv.c - divide floating point numbers
3923 _fsmul.c - multiply floating point numbers
3925 _fs2uchar.c - convert floating point to unsigned char
3927 _fs2char.c - convert floating point to signed char
3929 _fs2uint.c - convert floating point to unsigned int
3931 _fs2int.c - convert floating point to signed int
3933 _fs2ulong.c - convert floating point to unsigned long
3935 _fs2long.c - convert floating point to signed long
3937 _uchar2fs.c - convert unsigned char to floating point
3939 _char2fs.c - convert char to floating point number
3941 _uint2fs.c - convert unsigned int to floating point
3943 _int2fs.c - convert int to floating point numbers
3945 _ulong2fs.c - convert unsigned long to floating point number
3947 _long2fs.c - convert long to floating point number
3955 Note if all these routines are used simultaneously the data space might
3957 For serious floating point usage it is strongly recommended that the large
3964 SDCC allows two memory models for MCS51 code, small and large.
3965 Modules compiled with different memory models should
3969 be combined together or the results would be unpredictable.
3970 The library routines supplied with the compiler are compiled as both small
3972 The compiled library modules are contained in seperate directories as small
3973 and large so that you can link to either set.
3977 When the large model is used all variables declared without a storage class
3978 will be allocated into the external ram, this includes all parameters and
3979 local variables (for non-reentrant functions).
3980 When the small model is used variables without storage class are allocated
3981 in the internal ram.
3984 Judicious usage of the processor specific storage classes and the 'reentrant'
3985 function type will yield much more efficient code, than using the large
3987 Several optimizations are disabled when the program is compiled using the
3988 large model, it is therefore strongly recommdended that the small model
3989 be used unless absolutely required.
3995 The only model supported is Flat 24.
3996 This generates code for the 24 bit contiguous addressing mode of the Dallas
3998 In this mode, up to four meg of external RAM or code space can be directly
4000 See the data sheets at www.dalsemi.com for further information on this part.
4004 In older versions of the compiler, this option was used with the MCS51 code
4010 Now, however, the '390 has it's own code generator, selected by the
4019 Note that the compiler does not generate any code to place the processor
4020 into 24 bitmode (although
4024 in the ds390 libraries will do that for you).
4029 , the boot loader or similar code must ensure that the processor is in 24
4030 bit contiguous addressing mode before calling the SDCC startup code.
4038 option, variables will by default be placed into the XDATA segment.
4043 Segments may be placed anywhere in the 4 meg address space using the usual
4045 Note that if any segments are located above 64K, the -r flag must be passed
4046 to the linker to generate the proper segment relocations, and the Intel
4047 HEX output format must be used.
4048 The -r flag can be passed to the linker by using the option
4052 on the sdcc command line.
4053 However, currently the linker can not handle code segments > 64k.
4056 Defines Created by the Compiler
4059 The compiler creates the following #defines.
4062 SDCC - this Symbol is always defined.
4065 SDCC_mcs51 or SDCC_ds390 or SDCC_z80, etc - depending on the model used
4069 __mcs51 or __ds390 or __z80, etc - depending on the model used (e.g.
4073 SDCC_STACK_AUTO - this symbol is defined when
4080 SDCC_MODEL_SMALL - when
4087 SDCC_MODEL_LARGE - when
4094 SDCC_USE_XSTACK - when
4101 SDCC_STACK_TENBIT - when
4108 SDCC_MODEL_FLAT24 - when
4121 SDCC performs a host of standard optimizations in addition to some MCU specific
4124 \layout Subsubsection
4126 Sub-expression Elimination
4129 The compiler does local and global common subexpression elimination, e.g.:
4144 will be translated to
4160 Some subexpressions are not as obvious as the above example, e.g.:
4174 In this case the address arithmetic a->b[i] will be computed only once;
4175 the equivalent code in C would be.
4191 The compiler will try to keep these temporary variables in registers.
4192 \layout Subsubsection
4194 Dead-Code Elimination
4209 i = 1; \SpecialChar ~
4214 global = 1;\SpecialChar ~
4227 global = 3;\SpecialChar ~
4242 int global; void f ()
4255 \layout Subsubsection
4316 Note: the dead stores created by this copy propagation will be eliminated
4317 by dead-code elimination.
4318 \layout Subsubsection
4323 Two types of loop optimizations are done by SDCC loop invariant lifting
4324 and strength reduction of loop induction variables.
4325 In addition to the strength reduction the optimizer marks the induction
4326 variables and the register allocator tries to keep the induction variables
4327 in registers for the duration of the loop.
4328 Because of this preference of the register allocator, loop induction optimizati
4329 on causes an increase in register pressure, which may cause unwanted spilling
4330 of other temporary variables into the stack / data space.
4331 The compiler will generate a warning message when it is forced to allocate
4332 extra space either on the stack or data space.
4333 If this extra space allocation is undesirable then induction optimization
4334 can be eliminated either for the entire source file (with --noinduction
4335 option) or for a given function only using #pragma\SpecialChar ~
4346 for (i = 0 ; i < 100 ; i ++)
4364 for (i = 0; i < 100; i++)
4374 As mentioned previously some loop invariants are not as apparent, all static
4375 address computations are also moved out of the loop.
4379 Strength Reduction, this optimization substitutes an expression by a cheaper
4386 for (i=0;i < 100; i++)
4406 for (i=0;i< 100;i++) {
4410 ar[itemp1] = itemp2;
4426 The more expensive multiplication is changed to a less expensive addition.
4427 \layout Subsubsection
4432 This optimization is done to reduce the overhead of checking loop boundaries
4433 for every iteration.
4434 Some simple loops can be reversed and implemented using a
4435 \begin_inset Quotes eld
4438 decrement and jump if not zero
4439 \begin_inset Quotes erd
4443 SDCC checks for the following criterion to determine if a loop is reversible
4444 (note: more sophisticated compilers use data-dependency analysis to make
4445 this determination, SDCC uses a more simple minded analysis).
4448 The 'for' loop is of the form
4454 for (<symbol> = <expression> ; <sym> [< | <=] <expression> ; [<sym>++ |
4464 The <for body> does not contain
4465 \begin_inset Quotes eld
4469 \begin_inset Quotes erd
4473 \begin_inset Quotes erd
4479 All goto's are contained within the loop.
4482 No function calls within the loop.
4485 The loop control variable <sym> is not assigned any value within the loop
4488 The loop control variable does NOT participate in any arithmetic operation
4492 There are NO switch statements in the loop.
4493 \layout Subsubsection
4495 Algebraic Simplifications
4498 SDCC does numerous algebraic simplifications, the following is a small sub-set
4499 of these optimizations.
4505 i = j + 0 ; /* changed to */ i = j;
4507 i /= 2; /* changed to */ i >>= 1;
4509 i = j - j ; /* changed to */ i = 0;
4511 i = j / 1 ; /* changed to */ i = j;
4517 Note the subexpressions given above are generally introduced by macro expansions
4518 or as a result of copy/constant propagation.
4519 \layout Subsubsection
4524 SDCC changes switch statements to jump tables when the following conditions
4529 The case labels are in numerical sequence, the labels need not be in order,
4530 and the starting number need not be one or zero.
4536 switch(i) {\SpecialChar ~
4643 Both the above switch statements will be implemented using a jump-table.
4646 The number of case labels is at least three, since it takes two conditional
4647 statements to handle the boundary conditions.
4650 The number of case labels is less than 84, since each label takes 3 bytes
4651 and a jump-table can be utmost 256 bytes long.
4655 Switch statements which have gaps in the numeric sequence or those that
4656 have more that 84 case labels can be split into more than one switch statement
4657 for efficient code generation, e.g.:
4695 If the above switch statement is broken down into two switch statements
4729 case 9: \SpecialChar ~
4739 case 12:\SpecialChar ~
4749 then both the switch statements will be implemented using jump-tables whereas
4750 the unmodified switch statement will not be.
4751 \layout Subsubsection
4753 Bit-shifting Operations.
4756 Bit shifting is one of the most frequently used operation in embedded programmin
4758 SDCC tries to implement bit-shift operations in the most efficient way
4778 generates the following code:
4796 In general SDCC will never setup a loop if the shift count is known.
4836 Note that SDCC stores numbers in little-endian format (i.e.
4837 lowest order first).
4838 \layout Subsubsection
4843 A special case of the bit-shift operation is bit rotation, SDCC recognizes
4844 the following expression to be a left bit-rotation:
4855 i = ((i << 1) | (i >> 7));
4863 will generate the following code:
4879 SDCC uses pattern matching on the parse tree to determine this operation.Variatio
4880 ns of this case will also be recognized as bit-rotation, i.e.:
4886 i = ((i >> 7) | (i << 1)); /* left-bit rotation */
4887 \layout Subsubsection
4892 It is frequently required to obtain the highest order bit of an integral
4893 type (long, int, short or char types).
4894 SDCC recognizes the following expression to yield the highest order bit
4895 and generates optimized code for it, e.g.:
4916 hob = (gint >> 15) & 1;
4929 will generate the following code:
4968 000A E5*01\SpecialChar ~
4996 000C 33\SpecialChar ~
5027 000D E4\SpecialChar ~
5058 000E 13\SpecialChar ~
5089 000F F5*02\SpecialChar ~
5119 Variations of this case however will
5124 It is a standard C expression, so I heartily recommend this be the only
5125 way to get the highest order bit, (it is portable).
5126 Of course it will be recognized even if it is embedded in other expressions,
5133 xyz = gint + ((gint >> 15) & 1);
5139 will still be recognized.
5140 \layout Subsubsection
5145 The compiler uses a rule based, pattern matching and re-writing mechanism
5146 for peep-hole optimization.
5151 a peep-hole optimizer by Christopher W.
5152 Fraser (cwfraser@microsoft.com).
5153 A default set of rules are compiled into the compiler, additional rules
5154 may be added with the
5156 --peep-file <filename>
5159 The rule language is best illustrated with examples.
5187 The above rule will change the following assembly sequence:
5217 Note: All occurrences of a
5221 (pattern variable) must denote the same string.
5222 With the above rule, the assembly sequence:
5240 will remain unmodified.
5244 Other special case optimizations may be added by the user (via
5250 some variants of the 8051 MCU allow only
5259 The following two rules will change all
5281 replace { lcall %1 } by { acall %1 }
5283 replace { ljmp %1 } by { ajmp %1 }
5291 inline-assembler code
5293 is also passed through the peep hole optimizer, thus the peephole optimizer
5294 can also be used as an assembly level macro expander.
5295 The rules themselves are MCU dependent whereas the rule language infra-structur
5296 e is MCU independent.
5297 Peephole optimization rules for other MCU can be easily programmed using
5302 The syntax for a rule is as follows:
5308 rule := replace [ restart ] '{' <assembly sequence> '
5346 <assembly sequence> '
5364 '}' [if <functionName> ] '
5372 <assembly sequence> := assembly instruction (each instruction including
5373 labels must be on a separate line).
5377 The optimizer will apply to the rules one by one from the top in the sequence
5378 of their appearance, it will terminate when all rules are exhausted.
5379 If the 'restart' option is specified, then the optimizer will start matching
5380 the rules again from the top, this option for a rule is expensive (performance)
5381 , it is intended to be used in situations where a transformation will trigger
5382 the same rule again.
5383 An example of this (not a good one, it has side effects) is the following
5410 Note that the replace pattern cannot be a blank, but can be a comment line.
5411 Without the 'restart' option only the inner most 'pop' 'push' pair would
5412 be eliminated, i.e.:
5464 the restart option the rule will be applied again to the resulting code
5465 and then all the pop-push pairs will be eliminated to yield:
5483 A conditional function can be attached to a rule.
5484 Attaching rules are somewhat more involved, let me illustrate this with
5515 The optimizer does a look-up of a function name table defined in function
5520 in the source file SDCCpeeph.c, with the name
5525 If it finds a corresponding entry the function is called.
5526 Note there can be no parameters specified for these functions, in this
5531 is crucial, since the function
5535 expects to find the label in that particular variable (the hash table containin
5536 g the variable bindings is passed as a parameter).
5537 If you want to code more such functions, take a close look at the function
5538 labelInRange and the calling mechanism in source file SDCCpeeph.c.
5539 I know this whole thing is a little kludgey, but maybe some day we will
5540 have some better means.
5541 If you are looking at this file, you will also see the default rules that
5542 are compiled into the compiler, you can add your own rules in the default
5543 set there if you get tired of specifying the --peep-file option.
5549 SDCC supports the following #pragma directives.
5550 This directives are applicable only at a function level.
5553 SAVE - this will save all the current options.
5556 RESTORE - will restore the saved options from the last save.
5557 Note that SAVES & RESTOREs cannot be nested.
5558 SDCC uses the same buffer to save the options each time a SAVE is called.
5561 NOGCSE - will stop global subexpression elimination.
5564 NOINDUCTION - will stop loop induction optimizations.
5567 NOJTBOUND - will not generate code for boundary value checking, when switch
5568 statements are turned into jump-tables.
5571 NOOVERLAY - the compiler will not overlay the parameters and local variables
5575 NOLOOPREVERSE - Will not do loop reversal optimization
5578 EXCLUDE NONE | {acc[,b[,dpl[,dph]]] - The exclude pragma disables generation
5579 of pair of push/pop instruction in ISR function (using interrupt keyword).
5580 The directive should be placed immediately before the ISR function definition
5581 and it affects ALL ISR functions following it.
5582 To enable the normal register saving for ISR functions use #pragma\SpecialChar ~
5583 EXCLUDE\SpecialChar ~
5587 CALLEE-SAVES function1[,function2[,function3...]] - The compiler by default
5588 uses a caller saves convention for register saving across function calls,
5589 however this can cause unneccessary register pushing & popping when calling
5590 small functions from larger functions.
5591 This option can be used to switch the register saving convention for the
5592 function names specified.
5593 The compiler will not save registers when calling these functions, extra
5594 code will be generated at the entry & exit for these functions to save
5595 & restore the registers used by these functions, this can SUBSTANTIALLY
5596 reduce code & improve run time performance of the generated code.
5597 In future the compiler (with interprocedural analysis) will be able to
5598 determine the appropriate scheme to use for each function call.
5599 If --callee-saves command line option is used, the function names specified
5600 in #pragma\SpecialChar ~
5601 CALLEE-SAVES is appended to the list of functions specified inthe
5605 The pragma's are intended to be used to turn-off certain optimizations which
5606 might cause the compiler to generate extra stack / data space to store
5607 compiler generated temporary variables.
5608 This usually happens in large functions.
5609 Pragma directives should be used as shown in the following example, they
5610 are used to control options & optimizations for a given function; pragmas
5611 should be placed before and/or after a function, placing pragma's inside
5612 a function body could have unpredictable results.
5618 #pragma SAVE /* save the current settings */
5620 #pragma NOGCSE /* turnoff global subexpression elimination */
5622 #pragma NOINDUCTION /* turn off induction optimizations */
5644 #pragma RESTORE /* turn the optimizations back on */
5650 The compiler will generate a warning message when extra space is allocated.
5651 It is strongly recommended that the SAVE and RESTORE pragma's be used when
5652 changing options for a function.
5657 <pending: this is messy and incomplete>
5662 Compiler support routines (_gptrget, _mulint etc)
5665 Stdclib functions (puts, printf, strcat etc)
5668 Math functions (sin, pow, sqrt etc)
5671 Interfacing with Assembly Routines
5672 \layout Subsubsection
5674 Global Registers used for Parameter Passing
5677 The compiler always uses the global registers
5685 to pass the first parameter to a routine.
5686 The second parameter onwards is either allocated on the stack (for reentrant
5687 routines or if --stack-auto is used) or in the internal / external ram
5688 (depending on the memory model).
5690 \layout Subsubsection
5692 Assembler Routine(non-reentrant)
5695 In the following example the function cfunc calls an assembler routine asm_func,
5696 which takes two parameters.
5702 extern int asm_func(unsigned char, unsigned char);
5706 int c_func (unsigned char i, unsigned char j)
5714 return asm_func(i,j);
5728 return c_func(10,9);
5736 The corresponding assembler function is:
5742 .globl _asm_func_PARM_2
5806 add a,_asm_func_PARM_2
5842 Note here that the return values are placed in 'dpl' - One byte return value,
5843 'dpl' LSB & 'dph' MSB for two byte values.
5844 'dpl', 'dph' and 'b' for three byte values (generic pointers) and 'dpl','dph','
5845 b' & 'acc' for four byte values.
5848 The parameter naming convention is _<function_name>_PARM_<n>, where n is
5849 the parameter number starting from 1, and counting from the left.
5850 The first parameter is passed in
5851 \begin_inset Quotes eld
5855 \begin_inset Quotes erd
5858 for One bye parameter,
5859 \begin_inset Quotes eld
5863 \begin_inset Quotes erd
5867 \begin_inset Quotes eld
5871 \begin_inset Quotes erd
5875 \begin_inset Quotes eld
5879 \begin_inset Quotes erd
5882 for four bytes, the varible name for the second parameter will be _<function_na
5887 Assemble the assembler routine with the following command:
5894 asx8051 -losg asmfunc.asm
5901 Then compile and link the assembler routine to the C source file with the
5909 sdcc cfunc.c asmfunc.rel
5910 \layout Subsubsection
5912 Assembler Routine(reentrant)
5915 In this case the second parameter onwards will be passed on the stack, the
5916 parameters are pushed from right to left i.e.
5917 after the call the left most parameter will be on the top of the stack.
5924 extern int asm_func(unsigned char, unsigned char);
5928 int c_func (unsigned char i, unsigned char j) reentrant
5936 return asm_func(i,j);
5950 return c_func(10,9);
5958 The corresponding assembler routine is:
6068 The compiling and linking procedure remains the same, however note the extra
6069 entry & exit linkage required for the assembler code, _bp is the stack
6070 frame pointer and is used to compute the offset into the stack for parameters
6071 and local variables.
6077 The external stack is located at the start of the external ram segment,
6078 and is 256 bytes in size.
6079 When --xstack option is used to compile the program, the parameters and
6080 local variables of all reentrant functions are allocated in this area.
6081 This option is provided for programs with large stack space requirements.
6082 When used with the --stack-auto option, all parameters and local variables
6083 are allocated on the external stack (note support libraries will need to
6084 be recompiled with the same options).
6087 The compiler outputs the higher order address byte of the external ram segment
6088 into PORT P2, therefore when using the External Stack option, this port
6089 MAY NOT be used by the application program.
6095 Deviations from the compliancy.
6098 functions are not always reentrant.
6101 structures cannot be assigned values directly, cannot be passed as function
6102 parameters or assigned to each other and cannot be a return value from
6129 s1 = s2 ; /* is invalid in SDCC although allowed in ANSI */
6140 struct s foo1 (struct s parms) /* is invalid in SDCC although allowed in
6162 return rets;/* is invalid in SDCC although allowed in ANSI */
6167 'long long' (64 bit integers) not supported.
6170 'double' precision floating point not supported.
6173 No support for setjmp and longjmp (for now).
6176 Old K&R style function declarations are NOT allowed.
6182 foo(i,j) /* this old style of function declarations */
6184 int i,j; /* are valid in ANSI but not valid in SDCC */
6198 functions declared as pointers must be dereferenced during the call.
6209 /* has to be called like this */
6211 (*foo)(); /* ansi standard allows calls to be made like 'foo()' */
6214 Cyclomatic Complexity
6217 Cyclomatic complexity of a function is defined as the number of independent
6218 paths the program can take during execution of the function.
6219 This is an important number since it defines the number test cases you
6220 have to generate to validate the function.
6221 The accepted industry standard for complexity number is 10, if the cyclomatic
6222 complexity reported by SDCC exceeds 10 you should think about simplification
6223 of the function logic.
6224 Note that the complexity level is not related to the number of lines of
6226 Large functions can have low complexity, and small functions can have large
6232 SDCC uses the following formula to compute the complexity:
6237 complexity = (number of edges in control flow graph) - (number of nodes
6238 in control flow graph) + 2;
6242 Having said that the industry standard is 10, you should be aware that in
6243 some cases it be may unavoidable to have a complexity level of less than
6245 For example if you have switch statement with more than 10 case labels,
6246 each case label adds one to the complexity level.
6247 The complexity level is by no means an absolute measure of the algorithmic
6248 complexity of the function, it does however provide a good starting point
6249 for which functions you might look at for further optimization.
6255 Here are a few guidelines that will help the compiler generate more efficient
6256 code, some of the tips are specific to this compiler others are generally
6257 good programming practice.
6260 Use the smallest data type to represent your data-value.
6261 If it is known in advance that the value is going to be less than 256 then
6262 use a 'char' instead of a 'short' or 'int'.
6265 Use unsigned when it is known in advance that the value is not going to
6267 This helps especially if you are doing division or multiplication.
6270 NEVER jump into a LOOP.
6273 Declare the variables to be local whenever possible, especially loop control
6274 variables (induction).
6277 Since the compiler does not do implicit integral promotion, the programmer
6278 should do an explicit cast when integral promotion is required.
6281 Reducing the size of division, multiplication & modulus operations can reduce
6282 code size substantially.
6283 Take the following code for example.
6289 foobar(unsigned int p1, unsigned char ch)
6293 unsigned char ch1 = p1 % ch ;
6304 For the modulus operation the variable ch will be promoted to unsigned int
6305 first then the modulus operation will be performed (this will lead to a
6306 call to support routine _moduint()), and the result will be casted to a
6308 If the code is changed to
6314 foobar(unsigned int p1, unsigned char ch)
6318 unsigned char ch1 = (unsigned char)p1 % ch ;
6329 It would substantially reduce the code generated (future versions of the
6330 compiler will be smart enough to detect such optimization oppurtunities).
6333 Notes on MCS51 memory layout
6336 The 8051 family of micro controller have a minimum of 128 bytes of internal
6337 memory which is structured as follows
6341 - Bytes 00-1F - 32 bytes to hold up to 4 banks of the registers R7 to R7
6344 - Bytes 20-2F - 16 bytes to hold 128 bit variables and
6346 - Bytes 30-7F - 60 bytes for general purpose use.
6350 Normally the SDCC compiler will only utilise the first bank of registers,
6351 but it is possible to specify that other banks of registers should be used
6352 in interrupt routines.
6353 By default, the compiler will place the stack after the last bank of used
6355 if the first 2 banks of registers are used, it will position the base of
6356 the internal stack at address 16 (0X10).
6357 This implies that as the stack grows, it will use up the remaining register
6358 banks, and the 16 bytes used by the 128 bit variables, and 60 bytes for
6359 general purpose use.
6362 By default, the compiler uses the 60 general purpose bytes to hold "near
6364 The compiler/optimiser may also declare some Local Variables in this area
6369 If any of the 128 bit variables are used, or near data is being used then
6370 care needs to be taken to ensure that the stack does not grow so much that
6371 it starts to over write either your bit variables or "near data".
6372 There is no runtime checking to prevent this from happening.
6375 The amount of stack being used is affected by the use of the "internal stack"
6376 to save registers before a subroutine call is made (--stack-auto will declare
6377 parameters and local variables on the stack) and the number of nested subroutin
6381 If you detect that the stack is over writing you data, then the following
6383 --xstack will cause an external stack to be used for saving registers and
6384 (if --stack-auto is being used) storing parameters and local variables.
6385 However this will produce more code which will be slower to execute.
6389 --stack-loc will allow you specify the start of the stack, i.e.
6390 you could start it after any data in the general purpose area.
6391 However this may waste the memory not used by the register banks and if
6392 the size of the "near data" increases, it may creep into the bottom of
6396 --stack-after-data, similar to the --stack-loc, but it automatically places
6397 the stack after the end of the "near data".
6398 Again this could waste any spare register space.
6401 --data-loc allows you to specify the start address of the near data.
6402 This could be used to move the "near data" further away from the stack
6403 giving it more room to grow.
6404 This will only work if no bit variables are being used and the stack can
6405 grow to use the bit variable space.
6413 If you find that the stack is over writing your bit variables or "near data"
6414 then the approach which best utilised the internal memory is to position
6415 the "near data" after the last bank of used registers or, if you use bit
6416 variables, after the last bit variable by using the --data-loc, e.g.
6417 if two register banks are being used and no bit variables, --data-loc 16,
6418 and use the --stack-after-data option.
6421 If bit variables are being used, another method would be to try and squeeze
6422 the data area in the unused register banks if it will fit, and start the
6423 stack after the last bit variable.
6426 Retargetting for other MCUs.
6429 The issues for retargetting the compiler are far too numerous to be covered
6431 What follows is a brief description of each of the seven phases of the
6432 compiler and its MCU dependency.
6435 Parsing the source and building the annotated parse tree.
6436 This phase is largely MCU independent (except for the language extensions).
6437 Syntax & semantic checks are also done in this phase, along with some initial
6438 optimizations like back patching labels and the pattern matching optimizations
6439 like bit-rotation etc.
6442 The second phase involves generating an intermediate code which can be easy
6443 manipulated during the later phases.
6444 This phase is entirely MCU independent.
6445 The intermediate code generation assumes the target machine has unlimited
6446 number of registers, and designates them with the name iTemp.
6447 The compiler can be made to dump a human readable form of the code generated
6448 by using the --dumpraw option.
6451 This phase does the bulk of the standard optimizations and is also MCU independe
6453 This phase can be broken down into several sub-phases:
6457 Break down intermediate code (iCode) into basic blocks.
6459 Do control flow & data flow analysis on the basic blocks.
6461 Do local common subexpression elimination, then global subexpression elimination
6463 Dead code elimination
6467 If loop optimizations caused any changes then do 'global subexpression eliminati
6468 on' and 'dead code elimination' again.
6471 This phase determines the live-ranges; by live range I mean those iTemp
6472 variables defined by the compiler that still survive after all the optimization
6474 Live range analysis is essential for register allocation, since these computati
6475 on determines which of these iTemps will be assigned to registers, and for
6479 Phase five is register allocation.
6480 There are two parts to this process.
6484 The first part I call 'register packing' (for lack of a better term).
6485 In this case several MCU specific expression folding is done to reduce
6490 The second part is more MCU independent and deals with allocating registers
6491 to the remaining live ranges.
6492 A lot of MCU specific code does creep into this phase because of the limited
6493 number of index registers available in the 8051.
6496 The Code generation phase is (unhappily), entirely MCU dependent and very
6497 little (if any at all) of this code can be reused for other MCU.
6498 However the scheme for allocating a homogenized assembler operand for each
6499 iCode operand may be reused.
6502 As mentioned in the optimization section the peep-hole optimizer is rule
6503 based system, which can reprogrammed for other MCUs.
6506 SDCDB - Source Level Debugger
6509 SDCC is distributed with a source level debugger.
6510 The debugger uses a command line interface, the command repertoire of the
6511 debugger has been kept as close to gdb (the GNU debugger) as possible.
6512 The configuration and build process is part of the standard compiler installati
6513 on, which also builds and installs the debugger in the target directory
6514 specified during configuration.
6515 The debugger allows you debug BOTH at the C source and at the ASM source
6519 Compiling for Debugging
6524 debug option must be specified for all files for which debug information
6526 The complier generates a .cdb file for each of these files.
6527 The linker updates the .cdb file with the address information.
6528 This .cdb is used by the debugger.
6531 How the Debugger Works
6534 When the --debug option is specified the compiler generates extra symbol
6535 information some of which are put into the the assembler source and some
6536 are put into the .cdb file, the linker updates the .cdb file with the address
6537 information for the symbols.
6538 The debugger reads the symbolic information generated by the compiler &
6539 the address information generated by the linker.
6540 It uses the SIMULATOR (Daniel's S51) to execute the program, the program
6541 execution is controlled by the debugger.
6542 When a command is issued for the debugger, it translates it into appropriate
6543 commands for the simulator.
6546 Starting the Debugger
6549 The debugger can be started using the following command line.
6550 (Assume the file you are debugging has the file name foo).
6564 The debugger will look for the following files.
6567 foo.c - the source file.
6570 foo.cdb - the debugger symbol information file.
6573 foo.ihx - the intel hex format object file.
6576 Command Line Options.
6579 --directory=<source file directory> this option can used to specify the
6580 directory search list.
6581 The debugger will look into the directory list specified for source, cdb
6583 The items in the directory list must be separated by ':', e.g.
6584 if the source files can be in the directories /home/src1 and /home/src2,
6585 the --directory option should be --directory=/home/src1:/home/src2.
6586 Note there can be no spaces in the option.
6590 -cd <directory> - change to the <directory>.
6593 -fullname - used by GUI front ends.
6596 -cpu <cpu-type> - this argument is passed to the simulator please see the
6597 simulator docs for details.
6600 -X <Clock frequency > this options is passed to the simulator please see
6601 the simulator docs for details.
6604 -s <serial port file> passed to simulator see the simulator docs for details.
6607 -S <serial in,out> passed to simulator see the simulator docs for details.
6613 As mention earlier the command interface for the debugger has been deliberately
6614 kept as close the GNU debugger gdb, as possible.
6615 This will help the integration with existing graphical user interfaces
6616 (like ddd, xxgdb or xemacs) existing for the GNU debugger.
6617 \layout Subsubsection
6619 break [line | file:line | function | file:function]
6622 Set breakpoint at specified line or function:
6631 sdcdb>break foo.c:100
6635 sdcdb>break foo.c:funcfoo
6636 \layout Subsubsection
6638 clear [line | file:line | function | file:function ]
6641 Clear breakpoint at specified line or function:
6650 sdcdb>clear foo.c:100
6654 sdcdb>clear foo.c:funcfoo
6655 \layout Subsubsection
6660 Continue program being debugged, after breakpoint.
6661 \layout Subsubsection
6666 Execute till the end of the current function.
6667 \layout Subsubsection
6672 Delete breakpoint number 'n'.
6673 If used without any option clear ALL user defined break points.
6674 \layout Subsubsection
6676 info [break | stack | frame | registers ]
6679 info break - list all breakpoints
6682 info stack - show the function call stack.
6685 info frame - show information about the current execution frame.
6688 info registers - show content of all registers.
6689 \layout Subsubsection
6694 Step program until it reaches a different source line.
6695 \layout Subsubsection
6700 Step program, proceeding through subroutine calls.
6701 \layout Subsubsection
6706 Start debugged program.
6707 \layout Subsubsection
6712 Print type information of the variable.
6713 \layout Subsubsection
6718 print value of variable.
6719 \layout Subsubsection
6724 load the given file name.
6725 Note this is an alternate method of loading file for debugging.
6726 \layout Subsubsection
6731 print information about current frame.
6732 \layout Subsubsection
6737 Toggle between C source & assembly source.
6738 \layout Subsubsection
6743 Send the string following '!' to the simulator, the simulator response is
6745 Note the debugger does not interpret the command being sent to the simulator,
6746 so if a command like 'go' is sent the debugger can loose its execution
6747 context and may display incorrect values.
6748 \layout Subsubsection
6755 My name is Bobby Brown"
6758 Interfacing with XEmacs.
6761 Two files (in emacs lisp) are provided for the interfacing with XEmacs,
6762 sdcdb.el and sdcdbsrc.el.
6763 These two files can be found in the $(prefix)/bin directory after the installat
6765 These files need to be loaded into XEmacs for the interface to work.
6766 This can be done at XEmacs startup time by inserting the following into
6767 your '.xemacs' file (which can be found in your HOME directory):
6773 (load-file sdcdbsrc.el)
6779 .xemacs is a lisp file so the () around the command is REQUIRED.
6780 The files can also be loaded dynamically while XEmacs is running, set the
6781 environment variable 'EMACSLOADPATH' to the installation bin directory
6782 (<installdir>/bin), then enter the following command ESC-x load-file sdcdbsrc.
6783 To start the interface enter the following command:
6797 You will prompted to enter the file name to be debugged.
6802 The command line options that are passed to the simulator directly are bound
6803 to default values in the file sdcdbsrc.el.
6804 The variables are listed below, these values maybe changed as required.
6807 sdcdbsrc-cpu-type '51
6810 sdcdbsrc-frequency '11059200
6816 The following is a list of key mapping for the debugger interface.
6824 ;; Current Listing ::
6841 binding\SpecialChar ~
6880 -------\SpecialChar ~
6920 sdcdb-next-from-src\SpecialChar ~
6946 sdcdb-back-from-src\SpecialChar ~
6972 sdcdb-cont-from-src\SpecialChar ~
6982 SDCDB continue command
6998 sdcdb-step-from-src\SpecialChar ~
7024 sdcdb-whatis-c-sexp\SpecialChar ~
7034 SDCDB ptypecommand for data at
7098 sdcdbsrc-delete\SpecialChar ~
7112 SDCDB Delete all breakpoints if no arg
7160 given or delete arg (C-u arg x)
7176 sdcdbsrc-frame\SpecialChar ~
7191 SDCDB Display current frame if no arg,
7240 given or display frame arg
7305 sdcdbsrc-goto-sdcdb\SpecialChar ~
7315 Goto the SDCDB output buffer
7331 sdcdb-print-c-sexp\SpecialChar ~
7342 SDCDB print command for data at
7406 sdcdbsrc-goto-sdcdb\SpecialChar ~
7416 Goto the SDCDB output buffer
7432 sdcdbsrc-mode\SpecialChar ~
7448 Toggles Sdcdbsrc mode (turns it off)
7452 ;; C-c C-f\SpecialChar ~
7460 sdcdb-finish-from-src\SpecialChar ~
7468 SDCDB finish command
7472 ;; C-x SPC\SpecialChar ~
7480 sdcdb-break\SpecialChar ~
7498 Set break for line with point
7500 ;; ESC t\SpecialChar ~
7510 sdcdbsrc-mode\SpecialChar ~
7526 Toggle Sdcdbsrc mode
7528 ;; ESC m\SpecialChar ~
7538 sdcdbsrc-srcmode\SpecialChar ~
7562 The Z80 and gbz80 port
7565 SDCC can target both the Zilog Z80 and the Nintendo Gameboy's Z80-like gbz80.
7566 The port is incomplete - long support is incomplete (mul, div and mod are
7567 unimplimented), and both float and bitfield support is missing.
7568 Apart from that the code generated is correct.
7571 As always, the code is the authoritave reference - see z80/ralloc.c and z80/gen.c.
7572 The stack frame is similar to that generated by the IAR Z80 compiler.
7573 IX is used as the base pointer, HL is used as a temporary register, and
7574 BC and DE are available for holding varibles.
7575 IY is currently unusued.
7576 Return values are stored in HL.
7577 One bad side effect of using IX as the base pointer is that a functions
7578 stack frame is limited to 127 bytes - this will be fixed in a later version.
7584 SDCC has grown to be a large project.
7585 The compiler alone (without the preprocessor, assembler and linker) is
7586 about 40,000 lines of code (blank stripped).
7587 The open source nature of this project is a key to its continued growth
7589 You gain the benefit and support of many active software developers and
7591 Is SDCC perfect? No, that's why we need your help.
7592 The developers take pride in fixing reported bugs.
7593 You can help by reporting the bugs and helping other SDCC users.
7594 There are lots of ways to contribute, and we encourage you to take part
7595 in making SDCC a great software package.
7601 Send an email to the mailing list at 'user-sdcc@sdcc.sourceforge.net' or 'devel-sd
7602 cc@sdcc.sourceforge.net'.
7603 Bugs will be fixed ASAP.
7604 When reporting a bug, it is very useful to include a small test program
7605 which reproduces the problem.
7606 If you can isolate the problem by looking at the generated assembly code,
7607 this can be very helpful.
7608 Compiling your program with the --dumpall option can sometimes be useful
7609 in locating optimization problems.
7615 Sandeep Dutta (sandeep.dutta@usa.net) - SDCC, the compiler, MCS51 code generator,
7618 Alan Baldwin (baldwin@shop-pdp.kent.edu) - Initial version of ASXXXX & ASLINK.
7621 John Hartman (jhartman@compuserve.com) - Porting ASXXX & ASLINK for 8051
7624 Obukhov (dso@usa.net) - malloc & serial i/o routines.
7627 Daniel Drotos (drdani@mazsola.iit.uni-miskolc.hu) - for his Freeware simulator
7629 Malini Dutta(malini_dutta@hotmail.com) - my wife for her patience and support.
7631 Unknown - for the GNU C - preprocessor.
7633 Michael Hope - The Z80 and Z80GB port, 186 development
7635 Kevin Vigor - The DS390 port.
7637 Johan Knol - Lots of fixes and enhancements, DS390/TINI libs.
7639 Scott Datallo - The PIC port.
7645 Thanks to all the other volunteer developers who have helped with coding,
7646 testing, web-page creation, distribution sets, etc.
7647 You know who you are :-)
7654 This document was initially written by Sandeep Dutta
7657 All product names mentioned herein may be trademarks of their respective
7663 \begin_inset LatexCommand \printindex{}
projects / fw / sdcc / blob