1 #LyX 1.2 created this file. For more info see http://www.lyx.org/
15 \use_numerical_citations 0
16 \paperorientation portrait
19 \paragraph_separation indent
21 \quotes_language swedish
29 SDCC Compiler User Guide
33 \begin_inset LatexCommand \tableofcontents{}
50 is a Freeware, retargettable, optimizing ANSI-C compiler by
54 designed for 8 bit Microprocessors.
55 The current version targets Intel MCS51 based Microprocessors(8051,8052,
56 etc), Zilog Z80 based MCUs, and the Dallas DS80C390 variant.
57 It can be retargetted for other microprocessors, support for PIC, AVR and
58 186 is under development.
59 The entire source code for the compiler is distributed under GPL.
60 SDCC uses ASXXXX & ASLINK, a Freeware, retargettable assembler & linker.
61 SDCC has extensive language extensions suitable for utilizing various microcont
62 rollers and underlying hardware effectively.
67 In addition to the MCU specific optimizations SDCC also does a host of standard
71 global sub expression elimination,
74 loop optimizations (loop invariant, strength reduction of induction variables
78 constant folding & propagation,
94 For the back-end SDCC uses a global register allocation scheme which should
95 be well suited for other 8 bit MCUs.
100 The peep hole optimizer uses a rule based substitution mechanism which is
106 Supported data-types are:
109 char (8 bits, 1 byte),
112 short and int (16 bits, 2 bytes),
115 long (32 bit, 4 bytes)
122 The compiler also allows
124 inline assembler code
126 to be embedded anywhere in a function.
127 In addition, routines developed in assembly can also be called.
131 SDCC also provides an option (--cyclomatic) to report the relative complexity
133 These functions can then be further optimized, or hand coded in assembly
139 SDCC also comes with a companion source level debugger SDCDB, the debugger
140 currently uses ucSim a freeware simulator for 8051 and other micro-controllers.
145 The latest version can be downloaded from
146 \begin_inset LatexCommand \htmlurl{http://sdcc.sourceforge.net/}
158 All packages used in this compiler system are
166 ; source code for all the sub-packages (pre-processor, assemblers, linkers
167 etc) is distributed with the package.
168 This documentation is maintained using a freeware word processor (LyX).
170 This program is free software; you can redistribute it and/or modify it
171 under the terms of the GNU General Public License as published by the Free
172 Software Foundation; either version 2, or (at your option) any later version.
173 This program is distributed in the hope that it will be useful, but WITHOUT
174 ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
175 FOR A PARTICULAR PURPOSE.
176 See the GNU General Public License for more details.
177 You should have received a copy of the GNU General Public License along
178 with this program; if not, write to the Free Software Foundation, 59 Temple
179 Place - Suite 330, Boston, MA 02111-1307, USA.
180 In other words, you are welcome to use, share and improve this program.
181 You are forbidden to forbid anyone else to use, share and improve what
183 Help stamp out software-hoarding!
186 Typographic conventions
189 Throughout this manual, we will use the following convention.
190 Commands you have to type in are printed in
198 Code samples are printed in
203 Interesting items and new terms are printed in
208 Compatibility with previous versions
211 This version has numerous bug fixes compared with the previous version.
212 But we also introduced some incompatibilities with older versions.
213 Not just for the fun of it, but to make the compiler more stable, efficient
220 short is now equivalent to int (16 bits), it used to be equivalent to char
221 (8 bits) which is not ANSI compliant
224 the default directory where include, library and documention files are stored
225 is now in /usr/local/share
228 char type parameters to vararg functions are casted to int unless explicitly
245 will push a as an int and as a char resp.
248 option --regextend has been removed
251 option --noregparms has been removed
254 option --stack-after-data has been removed
259 <pending: more incompatibilities?>
265 What do you need before you start installation of SDCC? A computer, and
267 The preferred method of installation is to compile SDCC from source using
269 For Windows some pre-compiled binary distributions are available for your
271 You should have some experience with command line tools and compiler use.
277 The SDCC home page at
278 \begin_inset LatexCommand \htmlurl{http://sdcc.sourceforge.net/}
282 is a great place to find distribution sets.
283 You can also find links to the user mailing lists that offer help or discuss
284 SDCC with other SDCC users.
285 Web links to other SDCC related sites can also be found here.
286 This document can be found in the DOC directory of the source package as
288 Some of the other tools (simulator and assembler) included with SDCC contain
289 their own documentation and can be found in the source distribution.
290 If you want the latest unreleased software, the complete source package
291 is available directly by anonymous CVS on cvs.sdcc.sourceforge.net.
294 Wishes for the future
297 There are (and always will be) some things that could be done.
298 Here are some I can think of:
305 char KernelFunction3(char p) at 0x340;
311 If you can think of some more, please send them to the list.
317 <pending: And then of course a proper index-table
318 \begin_inset LatexCommand \index{index}
328 Linux/Unix Installation
333 Download the source package, it will be named something like sdcc-
342 Bring up a command line terminal, such as xterm.
347 Unpack the file using a command like:
350 "tar -xzf sdcc-x.x.x.tgz
355 , this will create a sub-directory called sdcc with all of the sources.
358 Change directory into the main SDCC directory, for example type:
375 This configures the package for compilation on your system.
391 All of the source packages will compile, this can take a while.
407 This copies the binary executables, the include files, the libraries and
408 the documentation to the install directories.
416 <pending: is this complete? where is borland, mingw>
419 \layout Subsubsection
421 Windows Install Using a Binary Package
424 Download the binary package and unpack it using your favorite unpacking
425 tool (gunzip, WinZip, etc).
426 This should unpack to a group of sub-directories.
427 An example directory structure after unpacking is: c:
433 bin for the executables, c:
453 lib for the include and libraries.
456 Adjust your environment PATH to include the location of the bin directory.
457 For example, make a setsdcc.bat file with the following: set PATH=c:
466 When you compile with sdcc, you may need to specify the location of the
467 lib and include folders.
468 For example, sdcc test.c -I c:
491 \layout Subsubsection
493 Windows Install Using Cygwin
498 Download and install the cygwin package from the redhat site
501 \begin_inset LatexCommand \htmlurl{http://sources.redhat.com/cygwin/}
508 Currently, this involved downloading a small install program which then
509 automates downloading and installing
515 (a large 80M byte sized dowload for the whole thing)
529 command line terminal from the Cygwin menu.
534 Follow the instructions in the preceding Linux/Unix installation section
535 \layout Subsubsection
537 Windows Install Using Microsoft Visual C++ 6.0/NET
540 (By Jesus Calvino-Fraga (jesus@ieee.org) Jan/31/2003, many thanks to "Borut
541 Razem" <borut.razem@siol.net> for fixing all the sources, projects, and workspace
542 so to build SDCC with Visual C++).
546 SDCC is distributed with all the projects, workspaces, and files you need
547 to build it using Visual C++ 6.0/NET.
548 The workspace name is 'sdcc.dsw'.
549 Please note that as it is now, all the executables are created in a folder
553 Once built you need to copy the executables from sdcc
557 bin before runnng SDCC.
562 In order to build SDCC with Visual C++ 6.0/NET you need win32 executables
563 of bison.exe, flex.exe, and gawk.exe.
564 One good place to get them is
565 \begin_inset LatexCommand \url[here]{http://unxutils.sourceforge.net}
573 Download the file UnxUtils.zip.
574 Now you have to install the utilities and setup Visual C++ so it can locate
575 the required programs.
576 Here there are two alternatives (choose one!):
583 a) Extract UnxUtils.zip to your C:
585 hard disk PRESERVING the original paths, otherwise bison won't work.
586 (If you are using WinZip make certain that 'Use folder names' is selected)
590 b) In the Visual C++ IDE click Tools, Options, select the Directory tab,
591 in 'Show directories for:' select 'Executable files', and in the directories
592 window add a new path: 'C:
602 (As a side effect, you get a bunch of Unix utilities that could be useful,
603 such as diff and patch.)
610 This one avoids extracting a bunch of files you may not use, but requires
615 a) Create a directory were to put the tools needed, or use a directory already
623 b) Extract 'bison.exe', 'bison.hairy', 'bison.simple', 'flex.exe', and gawk.exe
624 to such directory WITHOUT preserving the original paths.
625 (If you are using WinZip make certain that 'Use folder names' is not selected)
629 c) Rename bison.exe to '_bison.exe'.
633 d) Create a batch file 'bison.bat' in 'C:
637 ' and add these lines:
657 _bison %1 %2 %3 %4 %5 %6 %7 %8 %9
661 Steps 'c' and 'd' are needed because bison requires by default that the
662 files 'bison.simple' and 'bison.hairy' reside in some weird Unix directory,
663 '/usr/local/share/' I think.
664 So it is necessary to tell bison where those files are located if they
665 are not in such directory.
666 That is the function of the environment variables BISON_SIMPLE and BISON_HAIRY.
670 e) In the Visual C++ IDE click Tools, Options, select the Directory tab,
671 in 'Show directories for:' select 'Executable files', and in the directories
672 window add a new path: 'c:
675 Note that you can use any other path instead of 'c:
677 util', even the path where the Visual C++ tools are, probably: 'C:
681 Microsoft Visual Studio
686 So you don't have to execute step 'e' :)
690 Open 'sdcc.dsw' in Visual Studio, click 'build all', when it finishes copy
691 the executables from sdcc
695 bin, and you can compile using sdcc.
698 Testing out the SDCC Compiler
701 The first thing you should do after installing your SDCC compiler is to
709 at the prompt, and the program should run and tell you the version.
710 If it doesn't run, or gives a message about not finding sdcc program, then
711 you need to check over your installation.
712 Make sure that the sdcc bin directory is in your executable search path
713 defined by the PATH environment setting (see the Trouble-shooting section
715 Make sure that the sdcc program is in the bin folder, if not perhaps something
716 did not install correctly.
722 SDCC binaries are commonly installed in a directory arrangement like this:
730 <lyxtabular version="3" rows="3" columns="2">
732 <column alignment="left" valignment="top" leftline="true" width="0(null)">
733 <column alignment="left" valignment="top" leftline="true" rightline="true" width="0(null)">
734 <row topline="true" bottomline="true">
735 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
745 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
752 Holds executables(sdcc, s51, aslink,
761 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
768 usr/local/share/sdcc/lib
771 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
784 <row topline="true" bottomline="true">
785 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
792 usr/local/share/sdcc/include
795 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
802 Holds common C header files
816 Make sure the compiler works on a very simple example.
817 Type in the following test.c program using your favorite editor:
848 Compile this using the following command:
857 If all goes well, the compiler will generate a test.asm and test.rel file.
858 Congratulations, you've just compiled your first program with SDCC.
859 We used the -c option to tell SDCC not to link the generated code, just
860 to keep things simple for this step.
868 The next step is to try it with the linker.
878 If all goes well the compiler will link with the libraries and produce
879 a test.ihx output file.
884 (no test.ihx, and the linker generates warnings), then the problem is most
885 likely that sdcc cannot find the
889 usr/local/share/sdcc/lib directory
893 (see the Install trouble-shooting section for suggestions).
901 The final test is to ensure sdcc can use the
905 header files and libraries.
906 Edit test.c and change it to the following:
926 strcpy(str1, "testing");
935 Compile this by typing
942 This should generate a test.ihx output file, and it should give no warnings
943 such as not finding the string.h file.
944 If it cannot find the string.h file, then the problem is that sdcc cannot
945 find the /usr/local/share/sdcc/include directory
949 (see the Install trouble-shooting section for suggestions).
952 Install Trouble-shooting
953 \layout Subsubsection
955 SDCC cannot find libraries or header files.
958 The default installation assumes the libraries and header files are located
960 \begin_inset Quotes eld
963 /usr/local/share/sdcc/lib
964 \begin_inset Quotes erd
968 \begin_inset Quotes eld
971 /usr/local/share/sdcc/include
972 \begin_inset Quotes erd
976 An alternative is to specify these locations as compiler options like this:
982 /usr/local/sdcc/lib/small\SpecialChar ~
984 /usr/local/sdcc/include\SpecialChar ~
989 \layout Subsubsection
991 SDCC does not compile correctly.
994 A thing to try is starting from scratch by unpacking the .tgz source package
995 again in an empty directory.
1002 ./configure 2&>1 | tee configure.log
1014 make 2&>1 | tee make.log
1020 If anything goes wrong, you can review the log files to locate the problem.
1021 Or a relevant part of this can be attached to an email that could be helpful
1022 when requesting help from the mailing list.
1023 \layout Subsubsection
1026 \begin_inset Quotes sld
1030 \begin_inset Quotes srd
1037 \begin_inset Quotes sld
1041 \begin_inset Quotes srd
1044 command is a script that analyzes your system and performs some configuration
1045 to ensure the source package compiles on your system.
1046 It will take a few minutes to run, and will compile a few tests to determine
1047 what compiler features are installed.
1048 \layout Subsubsection
1051 \begin_inset Quotes sld
1055 \begin_inset Quotes srd
1061 This runs the GNU make tool, which automatically compiles all the source
1062 packages into the final installed binary executables.
1063 \layout Subsubsection
1066 \begin_inset Quotes sld
1070 \begin_inset Quotes erd
1076 This will install the compiler, other executables and libraries in to the
1077 appropriate system directories.
1078 The default is to copy the executables to /usr/local/bin and the libraries
1079 and header files to /usr/local/share/sdcc/lib and /usr/local/share/sdcc/include.
1080 On most systems you will need super-user privilages to do this.
1083 Advanced Install Options
1087 \begin_inset Quotes eld
1091 \begin_inset Quotes erd
1094 command has several options.
1095 The most commonly used option is --prefix=<directory name>, where <directory
1096 name> is the final location for the sdcc executables and libraries, (default
1097 location is /usr/local).
1098 The installation process will create the following directory structure
1099 under the <directory name> specified (if they do not already exist).
1104 bin/ - binary exectables (add to PATH environment variable)
1108 bin/share/sdcc/include/ - include header files
1112 bin/share/sdcc/lib/small/ - Object & library files for small model library
1114 bin/share/sdcc/lib/large/ - Object & library files for large model library
1116 bin/share/sdcc/lib/ds390/ - Object & library files forDS80C390 library
1124 \begin_inset Quotes sld
1127 ./configure --prefix=/usr/local
1128 \begin_inset Quotes erd
1134 will configure the compiler to be installed in directory /usr/local.
1140 SDCC is not just a compiler, but a collection of tools by various developers.
1141 These include linkers, assemblers, simulators and other components.
1142 Here is a summary of some of the components.
1143 Note that the included simulator and assembler have separate documentation
1144 which you can find in the source package in their respective directories.
1145 As SDCC grows to include support for other processors, other packages from
1146 various developers are included and may have their own sets of documentation.
1150 You might want to look at the files which are installed in <installdir>.
1151 At the time of this writing, we find the following programs:
1155 In <installdir>/bin:
1158 sdcc - The compiler.
1161 sdcpp - The C preprocessor.
1164 asx8051 - The assembler for 8051 type processors.
1171 as-gbz80 - The Z80 and GameBoy Z80 assemblers.
1174 aslink -The linker for 8051 type processors.
1181 link-gbz80 - The Z80 and GameBoy Z80 linkers.
1184 s51 - The ucSim 8051 simulator.
1187 sdcdb - The source debugger.
1190 packihx - A tool to pack (compress) Intel hex files.
1193 In <installdir>/share/sdcc/include
1199 In <installdir>/share/sdcc/lib
1202 the sources of the runtime library and the subdirs small large and ds390
1203 with the precompiled relocatables.
1206 In <installdir>/share/sdcc/doc
1212 As development for other processors proceeds, this list will expand to include
1213 executables to support processors like AVR, PIC, etc.
1214 \layout Subsubsection
1219 This is the actual compiler, it in turn uses the c-preprocessor and invokes
1220 the assembler and linkage editor.
1221 \layout Subsubsection
1223 sdcpp - The C-Preprocessor)
1226 The preprocessor is a modified version of the GNU preprocessor.
1227 The C preprocessor is used to pull in #include sources, process #ifdef
1228 statements, #defines and so on.
1229 \layout Subsubsection
1231 asx8051, as-z80, as-gbz80, aslink, link-z80, link-gbz80 - The Assemblers
1235 This is retargettable assembler & linkage editor, it was developed by Alan
1237 John Hartman created the version for 8051, and I (Sandeep) have made some
1238 enhancements and bug fixes for it to work properly with the SDCC.
1239 \layout Subsubsection
1244 S51 is a freeware, opensource simulator developed by Daniel Drotos (
1245 \begin_inset LatexCommand \url{mailto:drdani@mazsola.iit.uni-miskolc.hu}
1250 The simulator is built as part of the build process.
1251 For more information visit Daniel's website at:
1252 \begin_inset LatexCommand \url{http://mazsola.iit.uni-miskolc.hu/~drdani/embedded/s51}
1257 It currently support the core mcs51, the Dallas DS80C390 and the Philips
1259 \layout Subsubsection
1261 sdcdb - Source Level Debugger
1267 <todo: is this thing alive?>
1274 Sdcdb is the companion source level debugger.
1275 The current version of the debugger uses Daniel's Simulator S51, but can
1276 be easily changed to use other simulators.
1283 \layout Subsubsection
1285 Single Source File Projects
1288 For single source file 8051 projects the process is very simple.
1289 Compile your programs with the following command
1292 "sdcc sourcefile.c".
1296 This will compile, assemble and link your source file.
1297 Output files are as follows
1301 sourcefile.asm - Assembler source file created by the compiler
1303 sourcefile.lst - Assembler listing file created by the Assembler
1305 sourcefile.rst - Assembler listing file updated with linkedit information,
1306 created by linkage editor
1308 sourcefile.sym - symbol listing for the sourcefile, created by the assembler
1310 sourcefile.rel - Object file created by the assembler, input to Linkage editor
1312 sourcefile.map - The memory map for the load module, created by the Linker
1314 sourcefile.ihx - The load module in Intel hex format (you can select the
1315 Motorola S19 format with --out-fmt-s19)
1317 sourcefile.cdb - An optional file (with --debug) containing debug information
1320 \layout Subsubsection
1322 Projects with Multiple Source Files
1325 SDCC can compile only ONE file at a time.
1326 Let us for example assume that you have a project containing the following
1331 foo1.c (contains some functions)
1333 foo2.c (contains some more functions)
1335 foomain.c (contains more functions and the function main)
1343 The first two files will need to be compiled separately with the commands:
1375 Then compile the source file containing the
1379 function and link the files together with the following command:
1387 foomain.c\SpecialChar ~
1388 foo1.rel\SpecialChar ~
1400 can be separately compiled as well:
1411 sdcc foomain.rel foo1.rel foo2.rel
1418 The file containing the
1433 file specified in the command line, since the linkage editor processes
1434 file in the order they are presented to it.
1435 \layout Subsubsection
1437 Projects with Additional Libraries
1440 Some reusable routines may be compiled into a library, see the documentation
1441 for the assembler and linkage editor (which are in <installdir>/share/sdcc/doc)
1447 Libraries created in this manner can be included in the command line.
1448 Make sure you include the -L <library-path> option to tell the linker where
1449 to look for these files if they are not in the current directory.
1450 Here is an example, assuming you have the source file
1462 (if that is not the same as your current project):
1469 sdcc foomain.c foolib.lib -L mylib
1480 must be an absolute path name.
1484 The most efficient way to use libraries is to keep seperate modules in seperate
1486 The lib file now should name all the modules.rel files.
1487 For an example see the standard library file
1491 in the directory <installdir>/share/lib/small.
1494 Command Line Options
1495 \layout Subsubsection
1497 Processor Selection Options
1499 \labelwidthstring 00.00.0000
1505 Generate code for the MCS51 (8051) family of processors.
1506 This is the default processor target.
1508 \labelwidthstring 00.00.0000
1514 Generate code for the DS80C390 processor.
1516 \labelwidthstring 00.00.0000
1522 Generate code for the Z80 family of processors.
1524 \labelwidthstring 00.00.0000
1530 Generate code for the GameBoy Z80 processor.
1532 \labelwidthstring 00.00.0000
1538 Generate code for the Atmel AVR processor (In development, not complete).
1540 \labelwidthstring 00.00.0000
1546 Generate code for the PIC 14-bit processors (In development, not complete).
1548 \labelwidthstring 00.00.0000
1554 Generate code for the Toshiba TLCS-900H processor (In development, not
1557 \labelwidthstring 00.00.0000
1563 Generate code for the Philips XA51 processor (In development, not complete).
1564 \layout Subsubsection
1566 Preprocessor Options
1568 \labelwidthstring 00.00.0000
1574 The additional location where the pre processor will look for <..h> or
1575 \begin_inset Quotes eld
1579 \begin_inset Quotes erd
1584 \labelwidthstring 00.00.0000
1590 Command line definition of macros.
1591 Passed to the pre processor.
1593 \labelwidthstring 00.00.0000
1599 Tell the preprocessor to output a rule suitable for make describing the
1600 dependencies of each object file.
1601 For each source file, the preprocessor outputs one make-rule whose target
1602 is the object file name for that source file and whose dependencies are
1603 all the files `#include'd in it.
1604 This rule may be a single line or may be continued with `
1606 '-newline if it is long.
1607 The list of rules is printed on standard output instead of the preprocessed
1611 \labelwidthstring 00.00.0000
1617 Tell the preprocessor not to discard comments.
1618 Used with the `-E' option.
1620 \labelwidthstring 00.00.0000
1631 Like `-M' but the output mentions only the user header files included with
1633 \begin_inset Quotes eld
1637 System header files included with `#include <file>' are omitted.
1639 \labelwidthstring 00.00.0000
1645 Assert the answer answer for question, in case it is tested with a preprocessor
1646 conditional such as `#if #question(answer)'.
1647 `-A-' disables the standard assertions that normally describe the target
1650 \labelwidthstring 00.00.0000
1656 (answer) Assert the answer answer for question, in case it is tested with
1657 a preprocessor conditional such as `#if #question(answer)'.
1658 `-A-' disables the standard assertions that normally describe the target
1661 \labelwidthstring 00.00.0000
1667 Undefine macro macro.
1668 `-U' options are evaluated after all `-D' options, but before any `-include'
1669 and `-imacros' options.
1671 \labelwidthstring 00.00.0000
1677 Tell the preprocessor to output only a list of the macro definitions that
1678 are in effect at the end of preprocessing.
1679 Used with the `-E' option.
1681 \labelwidthstring 00.00.0000
1687 Tell the preprocessor to pass all macro definitions into the output, in
1688 their proper sequence in the rest of the output.
1690 \labelwidthstring 00.00.0000
1701 Like `-dD' except that the macro arguments and contents are omitted.
1702 Only `#define name' is included in the output.
1703 \layout Subsubsection
1707 \labelwidthstring 00.00.0000
1717 <absolute path to additional libraries> This option is passed to the linkage
1718 editor's additional libraries search path.
1719 The path name must be absolute.
1720 Additional library files may be specified in the command line.
1721 See section Compiling programs for more details.
1723 \labelwidthstring 00.00.0000
1729 <Value> The start location of the external ram, default value is 0.
1730 The value entered can be in Hexadecimal or Decimal format, e.g.: --xram-loc
1731 0x8000 or --xram-loc 32768.
1733 \labelwidthstring 00.00.0000
1739 <Value> The start location of the code segment, default value 0.
1740 Note when this option is used the interrupt vector table is also relocated
1741 to the given address.
1742 The value entered can be in Hexadecimal or Decimal format, e.g.: --code-loc
1743 0x8000 or --code-loc 32768.
1745 \labelwidthstring 00.00.0000
1751 <Value> The initial value of the stack pointer.
1752 The default value of the stack pointer is 0x07 if only register bank 0
1753 is used, if other register banks are used then the stack pointer is initialized
1754 to the location above the highest register bank used.
1756 if register banks 1 & 2 are used the stack pointer will default to location
1758 The value entered can be in Hexadecimal or Decimal format, eg.
1759 --stack-loc 0x20 or --stack-loc 32.
1760 If all four register banks are used the stack will be placed after the
1761 data segment (equivalent to --stack-after-data)
1763 \labelwidthstring 00.00.0000
1769 <Value> The start location of the internal ram data segment, the default
1770 value is 0x30.The value entered can be in Hexadecimal or Decimal format,
1772 --data-loc 0x20 or --data-loc 32.
1774 \labelwidthstring 00.00.0000
1780 <Value> The start location of the indirectly addressable internal ram, default
1782 The value entered can be in Hexadecimal or Decimal format, eg.
1783 --idata-loc 0x88 or --idata-loc 136.
1785 \labelwidthstring 00.00.0000
1794 The linker output (final object code) is in Intel Hex format.
1795 (This is the default option).
1797 \labelwidthstring 00.00.0000
1806 The linker output (final object code) is in Motorola S19 format.
1807 \layout Subsubsection
1811 \labelwidthstring 00.00.0000
1817 Generate code for Large model programs see section Memory Models for more
1819 If this option is used all source files in the project should be compiled
1821 In addition the standard library routines are compiled with small model,
1822 they will need to be recompiled.
1824 \labelwidthstring 00.00.0000
1835 Generate code for Small Model programs see section Memory Models for more
1837 This is the default model.
1838 \layout Subsubsection
1842 \labelwidthstring 00.00.0000
1853 Generate 24-bit flat mode code.
1854 This is the one and only that the ds390 code generator supports right now
1855 and is default when using
1860 See section Memory Models for more details.
1862 \labelwidthstring 00.00.0000
1868 Generate code for the 10 bit stack mode of the Dallas DS80C390 part.
1869 This is the one and only that the ds390 code generator supports right now
1870 and is default when using
1875 In this mode, the stack is located in the lower 1K of the internal RAM,
1876 which is mapped to 0x400000.
1877 Note that the support is incomplete, since it still uses a single byte
1878 as the stack pointer.
1879 This means that only the lower 256 bytes of the potential 1K stack space
1880 will actually be used.
1881 However, this does allow you to reclaim the precious 256 bytes of low RAM
1882 for use for the DATA and IDATA segments.
1883 The compiler will not generate any code to put the processor into 10 bit
1885 It is important to ensure that the processor is in this mode before calling
1886 any re-entrant functions compiled with this option.
1887 In principle, this should work with the
1891 option, but that has not been tested.
1892 It is incompatible with the
1897 It also only makes sense if the processor is in 24 bit contiguous addressing
1900 --model-flat24 option
1903 \layout Subsubsection
1905 Optimization Options
1907 \labelwidthstring 00.00.0000
1913 Will not do global subexpression elimination, this option may be used when
1914 the compiler creates undesirably large stack/data spaces to store compiler
1916 A warning message will be generated when this happens and the compiler
1917 will indicate the number of extra bytes it allocated.
1918 It recommended that this option NOT be used, #pragma\SpecialChar ~
1920 to turn off global subexpression elimination for a given function only.
1922 \labelwidthstring 00.00.0000
1928 Will not do loop invariant optimizations, this may be turned off for reasons
1929 explained for the previous option.
1930 For more details of loop optimizations performed see section Loop Invariants.It
1931 recommended that this option NOT be used, #pragma\SpecialChar ~
1932 NOINVARIANT can be used
1933 to turn off invariant optimizations for a given function only.
1935 \labelwidthstring 00.00.0000
1941 Will not do loop induction optimizations, see section strength reduction
1942 for more details.It is recommended that this option is NOT used, #pragma\SpecialChar ~
1944 ION can be used to turn off induction optimizations for a given function
1947 \labelwidthstring 00.00.0000
1958 Will not generate boundary condition check when switch statements are implement
1959 ed using jump-tables.
1960 See section Switch Statements for more details.
1961 It is recommended that this option is NOT used, #pragma\SpecialChar ~
1963 used to turn off boundary checking for jump tables for a given function
1966 \labelwidthstring 00.00.0000
1975 Will not do loop reversal optimization.
1977 \labelwidthstring 00.00.0000
1983 This will disable the memcpy of initialized data in far space from code
1985 \layout Subsubsection
1989 \labelwidthstring 00.00.0000
1996 will compile and assemble the source, but will not call the linkage editor.
1998 \labelwidthstring 00.00.0000
2004 Run only the C preprocessor.
2005 Preprocess all the C source files specified and output the results to standard
2008 \labelwidthstring 00.00.0000
2019 All functions in the source file will be compiled as
2024 the parameters and local variables will be allocated on the stack.
2025 see section Parameters and Local Variables for more details.
2026 If this option is used all source files in the project should be compiled
2030 \labelwidthstring 00.00.0000
2036 Uses a pseudo stack in the first 256 bytes in the external ram for allocating
2037 variables and passing parameters.
2038 See section on external stack for more details.
2040 \labelwidthstring 00.00.0000
2044 --callee-saves function1[,function2][,function3]....
2047 The compiler by default uses a caller saves convention for register saving
2048 across function calls, however this can cause unneccessary register pushing
2049 & popping when calling small functions from larger functions.
2050 This option can be used to switch the register saving convention for the
2051 function names specified.
2052 The compiler will not save registers when calling these functions, no extra
2053 code will be generated at the entry & exit for these functions to save
2054 & restore the registers used by these functions, this can SUBSTANTIALLY
2055 reduce code & improve run time performance of the generated code.
2056 In the future the compiler (with interprocedural analysis) will be able
2057 to determine the appropriate scheme to use for each function call.
2058 DO NOT use this option for built-in functions such as _muluint..., if this
2059 option is used for a library function the appropriate library function
2060 needs to be recompiled with the same option.
2061 If the project consists of multiple source files then all the source file
2062 should be compiled with the same --callee-saves option string.
2063 Also see #pragma\SpecialChar ~
2066 \labelwidthstring 00.00.0000
2075 When this option is used the compiler will generate debug information, that
2076 can be used with the SDCDB.
2077 The debug information is collected in a file with .cdb extension.
2078 For more information see documentation for SDCDB.
2080 \labelwidthstring 00.00.0000
2090 This option is obsolete and isn't supported anymore.
2092 \labelwidthstring 00.00.0000
2099 This option is obsolete and isn't supported anymore.
2101 \labelwidthstring 00.00.0000
2107 <filename> This option can be used to use additional rules to be used by
2108 the peep hole optimizer.
2109 See section Peep Hole optimizations for details on how to write these rules.
2111 \labelwidthstring 00.00.0000
2122 Stop after the stage of compilation proper; do not assemble.
2123 The output is an assembler code file for the input file specified.
2125 \labelwidthstring 00.00.0000
2129 -Wa_asmOption[,asmOption]
2132 Pass the asmOption to the assembler.
2134 \labelwidthstring 00.00.0000
2138 -Wl_linkOption[,linkOption]
2141 Pass the linkOption to the linker.
2143 \labelwidthstring 00.00.0000
2152 Integer (16 bit) and long (32 bit) libraries have been compiled as reentrant.
2153 Note by default these libraries are compiled as non-reentrant.
2154 See section Installation for more details.
2156 \labelwidthstring 00.00.0000
2165 This option will cause the compiler to generate an information message for
2166 each function in the source file.
2167 The message contains some
2171 information about the function.
2172 The number of edges and nodes the compiler detected in the control flow
2173 graph of the function, and most importantly the
2175 cyclomatic complexity
2177 see section on Cyclomatic Complexity for more details.
2179 \labelwidthstring 00.00.0000
2188 Floating point library is compiled as reentrant.See section Installation
2191 \labelwidthstring 00.00.0000
2197 The compiler will not overlay parameters and local variables of any function,
2198 see section Parameters and local variables for more details.
2200 \labelwidthstring 00.00.0000
2206 This option can be used when the code generated is called by a monitor
2208 The compiler will generate a 'ret' upon return from the 'main' function.
2209 The default option is to lock up i.e.
2212 \labelwidthstring 00.00.0000
2218 Disable peep-hole optimization.
2220 \labelwidthstring 00.00.0000
2226 Pass the inline assembler code through the peep hole optimizer.
2227 This can cause unexpected changes to inline assembler code, please go through
2228 the peephole optimizer rules defined in the source file tree '<target>/peeph.def
2229 ' before using this option.
2231 \labelwidthstring 00.00.0000
2237 <Value> Causes the linker to check if the interal ram usage is within limits
2240 \labelwidthstring 00.00.0000
2246 This will prevent the compiler from passing on the default include path
2247 to the preprocessor.
2249 \labelwidthstring 00.00.0000
2255 This will prevent the compiler from passing on the default library path
2258 \labelwidthstring 00.00.0000
2264 Shows the various actions the compiler is performing.
2266 \labelwidthstring 00.00.0000
2272 Shows the actual commands the compiler is executing.
2273 \layout Subsubsection
2275 Intermediate Dump Options
2278 The following options are provided for the purpose of retargetting and debugging
2280 These provided a means to dump the intermediate code (iCode) generated
2281 by the compiler in human readable form at various stages of the compilation
2285 \labelwidthstring 00.00.0000
2291 This option will cause the compiler to dump the intermediate code into
2294 <source filename>.dumpraw
2296 just after the intermediate code has been generated for a function, i.e.
2297 before any optimizations are done.
2298 The basic blocks at this stage ordered in the depth first number, so they
2299 may not be in sequence of execution.
2301 \labelwidthstring 00.00.0000
2307 Will create a dump of iCode's, after global subexpression elimination,
2310 <source filename>.dumpgcse.
2312 \labelwidthstring 00.00.0000
2318 Will create a dump of iCode's, after deadcode elimination, into a file
2321 <source filename>.dumpdeadcode.
2323 \labelwidthstring 00.00.0000
2332 Will create a dump of iCode's, after loop optimizations, into a file named
2335 <source filename>.dumploop.
2337 \labelwidthstring 00.00.0000
2346 Will create a dump of iCode's, after live range analysis, into a file named
2349 <source filename>.dumprange.
2351 \labelwidthstring 00.00.0000
2357 Will dump the life ranges for all symbols.
2359 \labelwidthstring 00.00.0000
2368 Will create a dump of iCode's, after register assignment, into a file named
2371 <source filename>.dumprassgn.
2373 \labelwidthstring 00.00.0000
2379 Will create a dump of the live ranges of iTemp's
2381 \labelwidthstring 00.00.0000
2392 Will cause all the above mentioned dumps to be created.
2395 MCS51/DS390 Storage Class Language Extensions
2398 In addition to the ANSI storage classes SDCC allows the following MCS51
2399 specific storage classes.
2400 \layout Subsubsection
2405 Variables declared with this storage class will be placed in the extern
2411 storage class for Large Memory model, e.g.:
2417 xdata unsigned char xduc;
2418 \layout Subsubsection
2427 storage class for Small Memory model.
2428 Variables declared with this storage class will be allocated in the internal
2436 \layout Subsubsection
2441 Variables declared with this storage class will be allocated into the indirectly
2442 addressable portion of the internal ram of a 8051, e.g.:
2449 \layout Subsubsection
2454 This is a data-type and a storage class specifier.
2455 When a variable is declared as a bit, it is allocated into the bit addressable
2456 memory of 8051, e.g.:
2463 \layout Subsubsection
2468 Like the bit keyword,
2472 signifies both a data-type and storage class, they are used to describe
2473 the special function registers and special bit variables of a 8051, eg:
2479 sfr at 0x80 P0; /* special function register P0 at location 0x80 */
2481 sbit at 0xd7 CY; /* CY (Carry Flag) */
2487 SDCC allows (via language extensions) pointers to explicitly point to any
2488 of the memory spaces of the 8051.
2489 In addition to the explicit pointers, the compiler uses (by default) generic
2490 pointers which can be used to point to any of the memory spaces.
2494 Pointer declaration examples:
2503 /* pointer physically in xternal ram pointing to object in internal ram
2506 data unsigned char * xdata p;
2510 /* pointer physically in code rom pointing to data in xdata space */
2512 xdata unsigned char * code p;
2516 /* pointer physically in code space pointing to data in code space */
2518 code unsigned char * code p;
2522 /* the folowing is a generic pointer physically located in xdata space */
2533 Well you get the idea.
2538 All unqualified pointers are treated as 3-byte (4-byte for the ds390)
2551 The highest order byte of the
2555 pointers contains the data space information.
2556 Assembler support routines are called whenever data is stored or retrieved
2562 These are useful for developing reusable library routines.
2563 Explicitly specifying the pointer type will generate the most efficient
2567 Parameters & Local Variables
2570 Automatic (local) variables and parameters to functions can either be placed
2571 on the stack or in data-space.
2572 The default action of the compiler is to place these variables in the internal
2573 RAM (for small model) or external RAM (for large model).
2574 This in fact makes them
2578 so by default functions are non-reentrant.
2582 They can be placed on the stack either by using the
2586 option or by using the
2590 keyword in the function declaration, e.g.:
2599 unsigned char foo(char i) reentrant
2612 Since stack space on 8051 is limited, the
2620 option should be used sparingly.
2621 Note that the reentrant keyword just means that the parameters & local
2622 variables will be allocated to the stack, it
2626 mean that the function is register bank independent.
2630 Local variables can be assigned storage classes and absolute addresses,
2637 unsigned char foo() {
2643 xdata unsigned char i;
2655 data at 0x31 unsiged char j;
2670 In the above example the variable
2674 will be allocated in the external ram,
2678 in bit addressable space and
2687 or when a function is declared as
2691 this should only be done for static variables.
2694 Parameters however are not allowed any storage class, (storage classes for
2695 parameters will be ignored), their allocation is governed by the memory
2696 model in use, and the reentrancy options.
2702 For non-reentrant functions SDCC will try to reduce internal ram space usage
2703 by overlaying parameters and local variables of a function (if possible).
2704 Parameters and local variables of a function will be allocated to an overlayabl
2705 e segment if the function has
2707 no other function calls and the function is non-reentrant and the memory
2711 If an explicit storage class is specified for a local variable, it will
2715 Note that the compiler (not the linkage editor) makes the decision for overlayin
2717 Functions that are called from an interrupt service routine should be preceded
2718 by a #pragma\SpecialChar ~
2719 NOOVERLAY if they are not reentrant.
2722 Also note that the compiler does not do any processing of inline assembler
2723 code, so the compiler might incorrectly assign local variables and parameters
2724 of a function into the overlay segment if the inline assembler code calls
2725 other c-functions that might use the overlay.
2726 In that case the #pragma\SpecialChar ~
2727 NOOVERLAY should be used.
2730 Parameters and Local variables of functions that contain 16 or 32 bit multiplica
2731 tion or division will NOT be overlayed since these are implemented using
2732 external functions, e.g.:
2742 void set_error(unsigned char errcd)
2758 void some_isr () interrupt 2 using 1
2787 In the above example the parameter
2795 would be assigned to the overlayable segment if the #pragma\SpecialChar ~
2797 not present, this could cause unpredictable runtime behavior when called
2799 The #pragma\SpecialChar ~
2800 NOOVERLAY ensures that the parameters and local variables for
2801 the function are NOT overlayed.
2804 Interrupt Service Routines
2807 SDCC allows interrupt service routines to be coded in C, with some extended
2814 void timer_isr (void) interrupt 2 using 1
2827 The number following the
2831 keyword is the interrupt number this routine will service.
2832 The compiler will insert a call to this routine in the interrupt vector
2833 table for the interrupt number specified.
2838 keyword is used to tell the compiler to use the specified register bank
2839 (8051 specific) when generating code for this function.
2840 Note that when some function is called from an interrupt service routine
2841 it should be preceded by a #pragma\SpecialChar ~
2842 NOOVERLAY if it is not reentrant.
2843 A special note here, int (16 bit) and long (32 bit) integer division, multiplic
2844 ation & modulus operations are implemented using external support routines
2845 developed in ANSI-C, if an interrupt service routine needs to do any of
2846 these operations then the support routines (as mentioned in a following
2847 section) will have to be recompiled using the
2851 option and the source file will need to be compiled using the
2858 If you have multiple source files in your project, interrupt service routines
2859 can be present in any of them, but a prototype of the isr MUST be present
2860 or included in the file that contains the function
2867 Interrupt Numbers and the corresponding address & descriptions for the Standard
2868 8051 are listed below.
2869 SDCC will automatically adjust the interrupt vector table to the maximum
2870 interrupt number specified.
2876 \begin_inset Tabular
2877 <lyxtabular version="3" rows="6" columns="3">
2879 <column alignment="center" valignment="top" leftline="true" width="0(null)">
2880 <column alignment="center" valignment="top" leftline="true" width="0(null)">
2881 <column alignment="center" valignment="top" leftline="true" rightline="true" width="0(null)">
2882 <row topline="true" bottomline="true">
2883 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
2891 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
2899 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
2908 <row topline="true">
2909 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
2917 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
2925 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
2934 <row topline="true">
2935 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
2943 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
2951 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
2960 <row topline="true">
2961 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
2969 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
2977 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
2986 <row topline="true">
2987 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
2995 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3003 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
3012 <row topline="true" bottomline="true">
3013 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3021 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
3029 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
3046 If the interrupt service routine is defined without
3050 a register bank or with register bank 0 (using 0), the compiler will save
3051 the registers used by itself on the stack upon entry and restore them at
3052 exit, however if such an interrupt service routine calls another function
3053 then the entire register bank will be saved on the stack.
3054 This scheme may be advantageous for small interrupt service routines which
3055 have low register usage.
3058 If the interrupt service routine is defined to be using a specific register
3063 are save and restored, if such an interrupt service routine calls another
3064 function (using another register bank) then the entire register bank of
3065 the called function will be saved on the stack.
3066 This scheme is recommended for larger interrupt service routines.
3069 Calling other functions from an interrupt service routine is not recommended,
3070 avoid it if possible.
3074 Also see the _naked modifier.
3082 <TODO: this isn't implemented at all!>
3088 A special keyword may be associated with a function declaring it as
3093 SDCC will generate code to disable all interrupts upon entry to a critical
3094 function and enable them back before returning.
3095 Note that nesting critical functions may cause unpredictable results.
3120 The critical attribute maybe used with other attributes like
3128 A special keyword may be associated with a function declaring it as
3137 function modifier attribute prevents the compiler from generating prologue
3138 and epilogue code for that function.
3139 This means that the user is entirely responsible for such things as saving
3140 any registers that may need to be preserved, selecting the proper register
3141 bank, generating the
3145 instruction at the end, etc.
3146 Practically, this means that the contents of the function must be written
3147 in inline assembler.
3148 This is particularly useful for interrupt functions, which can have a large
3149 (and often unnecessary) prologue/epilogue.
3150 For example, compare the code generated by these two functions:
3156 data unsigned char counter;
3158 void simpleInterrupt(void) interrupt 1
3172 void nakedInterrupt(void) interrupt 2 _naked
3205 ; MUST explicitly include ret in _naked function.
3219 For an 8051 target, the generated simpleInterrupt looks like:
3364 whereas nakedInterrupt looks like:
3389 ; MUST explicitly include ret(i) in _naked function.
3395 While there is nothing preventing you from writing C code inside a _naked
3396 function, there are many ways to shoot yourself in the foot doing this,
3397 and is is recommended that you stick to inline assembler.
3400 Functions using private banks
3407 attribute (which tells the compiler to use a register bank other than the
3408 default bank zero) should only be applied to
3412 functions (see note 1 below).
3413 This will in most circumstances make the generated ISR code more efficient
3414 since it will not have to save registers on the stack.
3421 attribute will have no effect on the generated code for a
3425 function (but may occasionally be useful anyway
3431 possible exception: if a function is called ONLY from 'interrupt' functions
3432 using a particular bank, it can be declared with the same 'using' attribute
3433 as the calling 'interrupt' functions.
3434 For instance, if you have several ISRs using bank one, and all of them
3435 call memcpy(), it might make sense to create a specialized version of memcpy()
3436 'using 1', since this would prevent the ISR from having to save bank zero
3437 to the stack on entry and switch to bank zero before calling the function
3444 (pending: I don't think this has been done yet)
3451 function using a non-zero bank will assume that it can trash that register
3452 bank, and will not save it.
3453 Since high-priority interrupts can interrupt low-priority ones on the 8051
3454 and friends, this means that if a high-priority ISR
3458 a particular bank occurs while processing a low-priority ISR
3462 the same bank, terrible and bad things can happen.
3463 To prevent this, no single register bank should be
3467 by both a high priority and a low priority ISR.
3468 This is probably most easily done by having all high priority ISRs use
3469 one bank and all low priority ISRs use another.
3470 If you have an ISR which can change priority at runtime, you're on your
3471 own: I suggest using the default bank zero and taking the small performance
3475 It is most efficient if your ISR calls no other functions.
3476 If your ISR must call other functions, it is most efficient if those functions
3477 use the same bank as the ISR (see note 1 below); the next best is if the
3478 called functions use bank zero.
3479 It is very inefficient to call a function using a different, non-zero bank
3487 Data items can be assigned an absolute address with the
3491 keyword, in addition to a storage class, e.g.:
3497 xdata at 0x8000 unsigned char PORTA_8255 ;
3503 In the above example the PORTA_8255 will be allocated to the location 0x8000
3504 of the external ram.
3505 Note that this feature is provided to give the programmer access to
3509 devices attached to the controller.
3510 The compiler does not actually reserve any space for variables declared
3511 in this way (they are implemented with an equate in the assembler).
3512 Thus it is left to the programmer to make sure there are no overlaps with
3513 other variables that are declared without the absolute address.
3514 The assembler listing file (.lst) and the linker output files (.rst) and
3515 (.map) are a good places to look for such overlaps.
3519 Absolute address can be specified for variables in all storage classes,
3532 The above example will allocate the variable at offset 0x02 in the bit-addressab
3534 There is no real advantage to assigning absolute addresses to variables
3535 in this manner, unless you want strict control over all the variables allocated.
3541 The compiler inserts a call to the C routine
3543 _sdcc__external__startup()
3548 at the start of the CODE area.
3549 This routine is in the runtime library.
3550 By default this routine returns 0, if this routine returns a non-zero value,
3551 the static & global variable initialization will be skipped and the function
3552 main will be invoked Other wise static & global variables will be initialized
3553 before the function main is invoked.
3556 _sdcc__external__startup()
3558 routine to your program to override the default if you need to setup hardware
3559 or perform some other critical operation prior to static & global variable
3563 Inline Assembler Code
3566 SDCC allows the use of in-line assembler with a few restriction as regards
3568 All labels defined within inline assembler code
3576 where nnnn is a number less than 100 (which implies a limit of utmost 100
3577 inline assembler labels
3585 It is strongly recommended that each assembly instruction (including labels)
3586 be placed in a separate line (as the example shows).
3591 command line option is used, the inline assembler code will be passed through
3592 the peephole optimizer.
3593 This might cause some unexpected changes in the inline assembler code.
3594 Please go throught the peephole optimizer rules defined in file
3598 carefully before using this option.
3638 The inline assembler code can contain any valid code understood by the assembler
3639 , this includes any assembler directives and comment lines.
3640 The compiler does not do any validation of the code within the
3650 Inline assembler code cannot reference any C-Labels, however it can reference
3651 labels defined by the inline assembler, e.g.:
3677 ; some assembler code
3697 /* some more c code */
3699 clabel:\SpecialChar ~
3701 /* inline assembler cannot reference this label */
3713 $0003: ;label (can be reference by inline assembler only)
3725 /* some more c code */
3733 In other words inline assembly code can access labels defined in inline
3734 assembly within the scope of the funtion.
3738 The same goes the other way, ie.
3739 labels defines in inline assembly CANNOT be accessed by C statements.
3742 int(16 bit) and long (32 bit) Support
3745 For signed & unsigned int (16 bit) and long (32 bit) variables, division,
3746 multiplication and modulus operations are implemented by support routines.
3747 These support routines are all developed in ANSI-C to facilitate porting
3748 to other MCUs, although some model specific assembler optimations are used.
3749 The following files contain the described routine, all of them can be found
3750 in <installdir>/share/sdcc/lib.
3756 <pending: tabularise this>
3762 _mulsint.c - signed 16 bit multiplication (calls _muluint)
3764 _muluint.c - unsigned 16 bit multiplication
3766 _divsint.c - signed 16 bit division (calls _divuint)
3768 _divuint.c - unsigned 16 bit division
3770 _modsint.c - signed 16 bit modulus (call _moduint)
3772 _moduint.c - unsigned 16 bit modulus
3774 _mulslong.c - signed 32 bit multiplication (calls _mululong)
3776 _mululong.c - unsigned32 bit multiplication
3778 _divslong.c - signed 32 division (calls _divulong)
3780 _divulong.c - unsigned 32 division
3782 _modslong.c - signed 32 bit modulus (calls _modulong)
3784 _modulong.c - unsigned 32 bit modulus
3792 Since they are compiled as
3796 , interrupt service routines should not do any of the above operations.
3797 If this is unavoidable then the above routines will need to be compiled
3802 option, after which the source program will have to be compiled with
3809 Floating Point Support
3812 SDCC supports IEEE (single precision 4bytes) floating point numbers.The floating
3813 point support routines are derived from gcc's floatlib.c and consists of
3814 the following routines:
3820 <pending: tabularise this>
3826 _fsadd.c - add floating point numbers
3828 _fssub.c - subtract floating point numbers
3830 _fsdiv.c - divide floating point numbers
3832 _fsmul.c - multiply floating point numbers
3834 _fs2uchar.c - convert floating point to unsigned char
3836 _fs2char.c - convert floating point to signed char
3838 _fs2uint.c - convert floating point to unsigned int
3840 _fs2int.c - convert floating point to signed int
3842 _fs2ulong.c - convert floating point to unsigned long
3844 _fs2long.c - convert floating point to signed long
3846 _uchar2fs.c - convert unsigned char to floating point
3848 _char2fs.c - convert char to floating point number
3850 _uint2fs.c - convert unsigned int to floating point
3852 _int2fs.c - convert int to floating point numbers
3854 _ulong2fs.c - convert unsigned long to floating point number
3856 _long2fs.c - convert long to floating point number
3864 Note if all these routines are used simultaneously the data space might
3866 For serious floating point usage it is strongly recommended that the large
3873 SDCC allows two memory models for MCS51 code, small and large.
3874 Modules compiled with different memory models should
3878 be combined together or the results would be unpredictable.
3879 The library routines supplied with the compiler are compiled as both small
3881 The compiled library modules are contained in seperate directories as small
3882 and large so that you can link to either set.
3886 When the large model is used all variables declared without a storage class
3887 will be allocated into the external ram, this includes all parameters and
3888 local variables (for non-reentrant functions).
3889 When the small model is used variables without storage class are allocated
3890 in the internal ram.
3893 Judicious usage of the processor specific storage classes and the 'reentrant'
3894 function type will yield much more efficient code, than using the large
3896 Several optimizations are disabled when the program is compiled using the
3897 large model, it is therefore strongly recommdended that the small model
3898 be used unless absolutely required.
3904 The only model supported is Flat 24.
3905 This generates code for the 24 bit contiguous addressing mode of the Dallas
3907 In this mode, up to four meg of external RAM or code space can be directly
3909 See the data sheets at www.dalsemi.com for further information on this part.
3913 In older versions of the compiler, this option was used with the MCS51 code
3919 Now, however, the '390 has it's own code generator, selected by the
3928 Note that the compiler does not generate any code to place the processor
3929 into 24 bitmode (although
3933 in the ds390 libraries will do that for you).
3938 , the boot loader or similar code must ensure that the processor is in 24
3939 bit contiguous addressing mode before calling the SDCC startup code.
3947 option, variables will by default be placed into the XDATA segment.
3952 Segments may be placed anywhere in the 4 meg address space using the usual
3954 Note that if any segments are located above 64K, the -r flag must be passed
3955 to the linker to generate the proper segment relocations, and the Intel
3956 HEX output format must be used.
3957 The -r flag can be passed to the linker by using the option
3961 on the sdcc command line.
3962 However, currently the linker can not handle code segments > 64k.
3965 Defines Created by the Compiler
3968 The compiler creates the following #defines.
3971 SDCC - this Symbol is always defined.
3974 SDCC_mcs51 or SDCC_ds390 or SDCC_z80, etc - depending on the model used
3978 __mcs51 or __ds390 or __z80, etc - depending on the model used (e.g.
3982 SDCC_STACK_AUTO - this symbol is defined when
3989 SDCC_MODEL_SMALL - when
3996 SDCC_MODEL_LARGE - when
4003 SDCC_USE_XSTACK - when
4010 SDCC_STACK_TENBIT - when
4017 SDCC_MODEL_FLAT24 - when
4030 SDCC performs a host of standard optimizations in addition to some MCU specific
4033 \layout Subsubsection
4035 Sub-expression Elimination
4038 The compiler does local and global common subexpression elimination, e.g.:
4053 will be translated to
4069 Some subexpressions are not as obvious as the above example, e.g.:
4083 In this case the address arithmetic a->b[i] will be computed only once;
4084 the equivalent code in C would be.
4100 The compiler will try to keep these temporary variables in registers.
4101 \layout Subsubsection
4103 Dead-Code Elimination
4118 i = 1; \SpecialChar ~
4123 global = 1;\SpecialChar ~
4136 global = 3;\SpecialChar ~
4151 int global; void f ()
4164 \layout Subsubsection
4225 Note: the dead stores created by this copy propagation will be eliminated
4226 by dead-code elimination.
4227 \layout Subsubsection
4232 Two types of loop optimizations are done by SDCC loop invariant lifting
4233 and strength reduction of loop induction variables.
4234 In addition to the strength reduction the optimizer marks the induction
4235 variables and the register allocator tries to keep the induction variables
4236 in registers for the duration of the loop.
4237 Because of this preference of the register allocator, loop induction optimizati
4238 on causes an increase in register pressure, which may cause unwanted spilling
4239 of other temporary variables into the stack / data space.
4240 The compiler will generate a warning message when it is forced to allocate
4241 extra space either on the stack or data space.
4242 If this extra space allocation is undesirable then induction optimization
4243 can be eliminated either for the entire source file (with --noinduction
4244 option) or for a given function only using #pragma\SpecialChar ~
4255 for (i = 0 ; i < 100 ; i ++)
4273 for (i = 0; i < 100; i++)
4283 As mentioned previously some loop invariants are not as apparent, all static
4284 address computations are also moved out of the loop.
4288 Strength Reduction, this optimization substitutes an expression by a cheaper
4295 for (i=0;i < 100; i++)
4315 for (i=0;i< 100;i++) {
4319 ar[itemp1] = itemp2;
4335 The more expensive multiplication is changed to a less expensive addition.
4336 \layout Subsubsection
4341 This optimization is done to reduce the overhead of checking loop boundaries
4342 for every iteration.
4343 Some simple loops can be reversed and implemented using a
4344 \begin_inset Quotes eld
4347 decrement and jump if not zero
4348 \begin_inset Quotes erd
4352 SDCC checks for the following criterion to determine if a loop is reversible
4353 (note: more sophisticated compilers use data-dependency analysis to make
4354 this determination, SDCC uses a more simple minded analysis).
4357 The 'for' loop is of the form
4363 for (<symbol> = <expression> ; <sym> [< | <=] <expression> ; [<sym>++ |
4373 The <for body> does not contain
4374 \begin_inset Quotes eld
4378 \begin_inset Quotes erd
4382 \begin_inset Quotes erd
4388 All goto's are contained within the loop.
4391 No function calls within the loop.
4394 The loop control variable <sym> is not assigned any value within the loop
4397 The loop control variable does NOT participate in any arithmetic operation
4401 There are NO switch statements in the loop.
4402 \layout Subsubsection
4404 Algebraic Simplifications
4407 SDCC does numerous algebraic simplifications, the following is a small sub-set
4408 of these optimizations.
4414 i = j + 0 ; /* changed to */ i = j;
4416 i /= 2; /* changed to */ i >>= 1;
4418 i = j - j ; /* changed to */ i = 0;
4420 i = j / 1 ; /* changed to */ i = j;
4426 Note the subexpressions given above are generally introduced by macro expansions
4427 or as a result of copy/constant propagation.
4428 \layout Subsubsection
4433 SDCC changes switch statements to jump tables when the following conditions
4438 The case labels are in numerical sequence, the labels need not be in order,
4439 and the starting number need not be one or zero.
4445 switch(i) {\SpecialChar ~
4552 Both the above switch statements will be implemented using a jump-table.
4555 The number of case labels is at least three, since it takes two conditional
4556 statements to handle the boundary conditions.
4559 The number of case labels is less than 84, since each label takes 3 bytes
4560 and a jump-table can be utmost 256 bytes long.
4564 Switch statements which have gaps in the numeric sequence or those that
4565 have more that 84 case labels can be split into more than one switch statement
4566 for efficient code generation, e.g.:
4604 If the above switch statement is broken down into two switch statements
4638 case 9: \SpecialChar ~
4648 case 12:\SpecialChar ~
4658 then both the switch statements will be implemented using jump-tables whereas
4659 the unmodified switch statement will not be.
4660 \layout Subsubsection
4662 Bit-shifting Operations.
4665 Bit shifting is one of the most frequently used operation in embedded programmin
4667 SDCC tries to implement bit-shift operations in the most efficient way
4687 generates the following code:
4705 In general SDCC will never setup a loop if the shift count is known.
4745 Note that SDCC stores numbers in little-endian format (i.e.
4746 lowest order first).
4747 \layout Subsubsection
4752 A special case of the bit-shift operation is bit rotation, SDCC recognizes
4753 the following expression to be a left bit-rotation:
4764 i = ((i << 1) | (i >> 7));
4772 will generate the following code:
4788 SDCC uses pattern matching on the parse tree to determine this operation.Variatio
4789 ns of this case will also be recognized as bit-rotation, i.e.:
4795 i = ((i >> 7) | (i << 1)); /* left-bit rotation */
4796 \layout Subsubsection
4801 It is frequently required to obtain the highest order bit of an integral
4802 type (long, int, short or char types).
4803 SDCC recognizes the following expression to yield the highest order bit
4804 and generates optimized code for it, e.g.:
4825 hob = (gint >> 15) & 1;
4838 will generate the following code:
4877 000A E5*01\SpecialChar ~
4905 000C 33\SpecialChar ~
4936 000D E4\SpecialChar ~
4967 000E 13\SpecialChar ~
4998 000F F5*02\SpecialChar ~
5028 Variations of this case however will
5033 It is a standard C expression, so I heartily recommend this be the only
5034 way to get the highest order bit, (it is portable).
5035 Of course it will be recognized even if it is embedded in other expressions,
5042 xyz = gint + ((gint >> 15) & 1);
5048 will still be recognized.
5049 \layout Subsubsection
5054 The compiler uses a rule based, pattern matching and re-writing mechanism
5055 for peep-hole optimization.
5060 a peep-hole optimizer by Christopher W.
5061 Fraser (cwfraser@microsoft.com).
5062 A default set of rules are compiled into the compiler, additional rules
5063 may be added with the
5065 --peep-file <filename>
5068 The rule language is best illustrated with examples.
5096 The above rule will change the following assembly sequence:
5126 Note: All occurrences of a
5130 (pattern variable) must denote the same string.
5131 With the above rule, the assembly sequence:
5149 will remain unmodified.
5153 Other special case optimizations may be added by the user (via
5159 some variants of the 8051 MCU allow only
5168 The following two rules will change all
5190 replace { lcall %1 } by { acall %1 }
5192 replace { ljmp %1 } by { ajmp %1 }
5200 inline-assembler code
5202 is also passed through the peep hole optimizer, thus the peephole optimizer
5203 can also be used as an assembly level macro expander.
5204 The rules themselves are MCU dependent whereas the rule language infra-structur
5205 e is MCU independent.
5206 Peephole optimization rules for other MCU can be easily programmed using
5211 The syntax for a rule is as follows:
5217 rule := replace [ restart ] '{' <assembly sequence> '
5255 <assembly sequence> '
5273 '}' [if <functionName> ] '
5281 <assembly sequence> := assembly instruction (each instruction including
5282 labels must be on a separate line).
5286 The optimizer will apply to the rules one by one from the top in the sequence
5287 of their appearance, it will terminate when all rules are exhausted.
5288 If the 'restart' option is specified, then the optimizer will start matching
5289 the rules again from the top, this option for a rule is expensive (performance)
5290 , it is intended to be used in situations where a transformation will trigger
5291 the same rule again.
5292 An example of this (not a good one, it has side effects) is the following
5319 Note that the replace pattern cannot be a blank, but can be a comment line.
5320 Without the 'restart' option only the inner most 'pop' 'push' pair would
5321 be eliminated, i.e.:
5373 the restart option the rule will be applied again to the resulting code
5374 and then all the pop-push pairs will be eliminated to yield:
5392 A conditional function can be attached to a rule.
5393 Attaching rules are somewhat more involved, let me illustrate this with
5424 The optimizer does a look-up of a function name table defined in function
5429 in the source file SDCCpeeph.c, with the name
5434 If it finds a corresponding entry the function is called.
5435 Note there can be no parameters specified for these functions, in this
5440 is crucial, since the function
5444 expects to find the label in that particular variable (the hash table containin
5445 g the variable bindings is passed as a parameter).
5446 If you want to code more such functions, take a close look at the function
5447 labelInRange and the calling mechanism in source file SDCCpeeph.c.
5448 I know this whole thing is a little kludgey, but maybe some day we will
5449 have some better means.
5450 If you are looking at this file, you will also see the default rules that
5451 are compiled into the compiler, you can add your own rules in the default
5452 set there if you get tired of specifying the --peep-file option.
5458 SDCC supports the following #pragma directives.
5459 This directives are applicable only at a function level.
5462 SAVE - this will save all the current options.
5465 RESTORE - will restore the saved options from the last save.
5466 Note that SAVES & RESTOREs cannot be nested.
5467 SDCC uses the same buffer to save the options each time a SAVE is called.
5470 NOGCSE - will stop global subexpression elimination.
5473 NOINDUCTION - will stop loop induction optimizations.
5476 NOJTBOUND - will not generate code for boundary value checking, when switch
5477 statements are turned into jump-tables.
5480 NOOVERLAY - the compiler will not overlay the parameters and local variables
5484 NOLOOPREVERSE - Will not do loop reversal optimization
5487 EXCLUDE NONE | {acc[,b[,dpl[,dph]]] - The exclude pragma disables generation
5488 of pair of push/pop instruction in ISR function (using interrupt keyword).
5489 The directive should be placed immediately before the ISR function definition
5490 and it affects ALL ISR functions following it.
5491 To enable the normal register saving for ISR functions use #pragma\SpecialChar ~
5492 EXCLUDE\SpecialChar ~
5496 CALLEE-SAVES function1[,function2[,function3...]] - The compiler by default
5497 uses a caller saves convention for register saving across function calls,
5498 however this can cause unneccessary register pushing & popping when calling
5499 small functions from larger functions.
5500 This option can be used to switch the register saving convention for the
5501 function names specified.
5502 The compiler will not save registers when calling these functions, extra
5503 code will be generated at the entry & exit for these functions to save
5504 & restore the registers used by these functions, this can SUBSTANTIALLY
5505 reduce code & improve run time performance of the generated code.
5506 In future the compiler (with interprocedural analysis) will be able to
5507 determine the appropriate scheme to use for each function call.
5508 If --callee-saves command line option is used, the function names specified
5509 in #pragma\SpecialChar ~
5510 CALLEE-SAVES is appended to the list of functions specified inthe
5514 The pragma's are intended to be used to turn-off certain optimizations which
5515 might cause the compiler to generate extra stack / data space to store
5516 compiler generated temporary variables.
5517 This usually happens in large functions.
5518 Pragma directives should be used as shown in the following example, they
5519 are used to control options & optimizations for a given function; pragmas
5520 should be placed before and/or after a function, placing pragma's inside
5521 a function body could have unpredictable results.
5527 #pragma SAVE /* save the current settings */
5529 #pragma NOGCSE /* turnoff global subexpression elimination */
5531 #pragma NOINDUCTION /* turn off induction optimizations */
5553 #pragma RESTORE /* turn the optimizations back on */
5559 The compiler will generate a warning message when extra space is allocated.
5560 It is strongly recommended that the SAVE and RESTORE pragma's be used when
5561 changing options for a function.
5566 <pending: this is messy and incomplete>
5571 Compiler support routines (_gptrget, _mulint etc)
5574 Stdclib functions (puts, printf, strcat etc)
5577 Math functions (sin, pow, sqrt etc)
5580 Interfacing with Assembly Routines
5581 \layout Subsubsection
5583 Global Registers used for Parameter Passing
5586 The compiler always uses the global registers
5594 to pass the first parameter to a routine.
5595 The second parameter onwards is either allocated on the stack (for reentrant
5596 routines or if --stack-auto is used) or in the internal / external ram
5597 (depending on the memory model).
5599 \layout Subsubsection
5601 Assembler Routine(non-reentrant)
5604 In the following example the function cfunc calls an assembler routine asm_func,
5605 which takes two parameters.
5611 extern int asm_func(unsigned char, unsigned char);
5615 int c_func (unsigned char i, unsigned char j)
5623 return asm_func(i,j);
5637 return c_func(10,9);
5645 The corresponding assembler function is:
5651 .globl _asm_func_PARM_2
5715 add a,_asm_func_PARM_2
5751 Note here that the return values are placed in 'dpl' - One byte return value,
5752 'dpl' LSB & 'dph' MSB for two byte values.
5753 'dpl', 'dph' and 'b' for three byte values (generic pointers) and 'dpl','dph','
5754 b' & 'acc' for four byte values.
5757 The parameter naming convention is _<function_name>_PARM_<n>, where n is
5758 the parameter number starting from 1, and counting from the left.
5759 The first parameter is passed in
5760 \begin_inset Quotes eld
5764 \begin_inset Quotes erd
5767 for One bye parameter,
5768 \begin_inset Quotes eld
5772 \begin_inset Quotes erd
5776 \begin_inset Quotes eld
5780 \begin_inset Quotes erd
5784 \begin_inset Quotes eld
5788 \begin_inset Quotes erd
5791 for four bytes, the varible name for the second parameter will be _<function_na
5796 Assemble the assembler routine with the following command:
5803 asx8051 -losg asmfunc.asm
5810 Then compile and link the assembler routine to the C source file with the
5818 sdcc cfunc.c asmfunc.rel
5819 \layout Subsubsection
5821 Assembler Routine(reentrant)
5824 In this case the second parameter onwards will be passed on the stack, the
5825 parameters are pushed from right to left i.e.
5826 after the call the left most parameter will be on the top of the stack.
5833 extern int asm_func(unsigned char, unsigned char);
5837 int c_func (unsigned char i, unsigned char j) reentrant
5845 return asm_func(i,j);
5859 return c_func(10,9);
5867 The corresponding assembler routine is:
5977 The compiling and linking procedure remains the same, however note the extra
5978 entry & exit linkage required for the assembler code, _bp is the stack
5979 frame pointer and is used to compute the offset into the stack for parameters
5980 and local variables.
5986 The external stack is located at the start of the external ram segment,
5987 and is 256 bytes in size.
5988 When --xstack option is used to compile the program, the parameters and
5989 local variables of all reentrant functions are allocated in this area.
5990 This option is provided for programs with large stack space requirements.
5991 When used with the --stack-auto option, all parameters and local variables
5992 are allocated on the external stack (note support libraries will need to
5993 be recompiled with the same options).
5996 The compiler outputs the higher order address byte of the external ram segment
5997 into PORT P2, therefore when using the External Stack option, this port
5998 MAY NOT be used by the application program.
6004 Deviations from the compliancy.
6007 functions are not always reentrant.
6010 structures cannot be assigned values directly, cannot be passed as function
6011 parameters or assigned to each other and cannot be a return value from
6038 s1 = s2 ; /* is invalid in SDCC although allowed in ANSI */
6049 struct s foo1 (struct s parms) /* is invalid in SDCC although allowed in
6071 return rets;/* is invalid in SDCC although allowed in ANSI */
6076 'long long' (64 bit integers) not supported.
6079 'double' precision floating point not supported.
6082 No support for setjmp and longjmp (for now).
6085 Old K&R style function declarations are NOT allowed.
6091 foo(i,j) /* this old style of function declarations */
6093 int i,j; /* are valid in ANSI but not valid in SDCC */
6107 functions declared as pointers must be dereferenced during the call.
6118 /* has to be called like this */
6120 (*foo)(); /* ansi standard allows calls to be made like 'foo()' */
6123 Cyclomatic Complexity
6126 Cyclomatic complexity of a function is defined as the number of independent
6127 paths the program can take during execution of the function.
6128 This is an important number since it defines the number test cases you
6129 have to generate to validate the function.
6130 The accepted industry standard for complexity number is 10, if the cyclomatic
6131 complexity reported by SDCC exceeds 10 you should think about simplification
6132 of the function logic.
6133 Note that the complexity level is not related to the number of lines of
6135 Large functions can have low complexity, and small functions can have large
6141 SDCC uses the following formula to compute the complexity:
6146 complexity = (number of edges in control flow graph) - (number of nodes
6147 in control flow graph) + 2;
6151 Having said that the industry standard is 10, you should be aware that in
6152 some cases it be may unavoidable to have a complexity level of less than
6154 For example if you have switch statement with more than 10 case labels,
6155 each case label adds one to the complexity level.
6156 The complexity level is by no means an absolute measure of the algorithmic
6157 complexity of the function, it does however provide a good starting point
6158 for which functions you might look at for further optimization.
6164 Here are a few guidelines that will help the compiler generate more efficient
6165 code, some of the tips are specific to this compiler others are generally
6166 good programming practice.
6169 Use the smallest data type to represent your data-value.
6170 If it is known in advance that the value is going to be less than 256 then
6171 use a 'char' instead of a 'short' or 'int'.
6174 Use unsigned when it is known in advance that the value is not going to
6176 This helps especially if you are doing division or multiplication.
6179 NEVER jump into a LOOP.
6182 Declare the variables to be local whenever possible, especially loop control
6183 variables (induction).
6186 Since the compiler does not do implicit integral promotion, the programmer
6187 should do an explicit cast when integral promotion is required.
6190 Reducing the size of division, multiplication & modulus operations can reduce
6191 code size substantially.
6192 Take the following code for example.
6198 foobar(unsigned int p1, unsigned char ch)
6202 unsigned char ch1 = p1 % ch ;
6213 For the modulus operation the variable ch will be promoted to unsigned int
6214 first then the modulus operation will be performed (this will lead to a
6215 call to support routine _moduint()), and the result will be casted to a
6217 If the code is changed to
6223 foobar(unsigned int p1, unsigned char ch)
6227 unsigned char ch1 = (unsigned char)p1 % ch ;
6238 It would substantially reduce the code generated (future versions of the
6239 compiler will be smart enough to detect such optimization oppurtunities).
6242 Notes on MCS51 memory layout
6245 The 8051 family of micro controller have a minimum of 128 bytes of internal
6246 memory which is structured as follows
6250 - Bytes 00-1F - 32 bytes to hold up to 4 banks of the registers R7 to R7
6253 - Bytes 20-2F - 16 bytes to hold 128 bit variables and
6255 - Bytes 30-7F - 60 bytes for general purpose use.
6259 Normally the SDCC compiler will only utilise the first bank of registers,
6260 but it is possible to specify that other banks of registers should be used
6261 in interrupt routines.
6262 By default, the compiler will place the stack after the last bank of used
6264 if the first 2 banks of registers are used, it will position the base of
6265 the internal stack at address 16 (0X10).
6266 This implies that as the stack grows, it will use up the remaining register
6267 banks, and the 16 bytes used by the 128 bit variables, and 60 bytes for
6268 general purpose use.
6271 By default, the compiler uses the 60 general purpose bytes to hold "near
6273 The compiler/optimiser may also declare some Local Variables in this area
6278 If any of the 128 bit variables are used, or near data is being used then
6279 care needs to be taken to ensure that the stack does not grow so much that
6280 it starts to over write either your bit variables or "near data".
6281 There is no runtime checking to prevent this from happening.
6284 The amount of stack being used is affected by the use of the "internal stack"
6285 to save registers before a subroutine call is made (--stack-auto will declare
6286 parameters and local variables on the stack) and the number of nested subroutin
6290 If you detect that the stack is over writing you data, then the following
6292 --xstack will cause an external stack to be used for saving registers and
6293 (if --stack-auto is being used) storing parameters and local variables.
6294 However this will produce more code which will be slower to execute.
6298 --stack-loc will allow you specify the start of the stack, i.e.
6299 you could start it after any data in the general purpose area.
6300 However this may waste the memory not used by the register banks and if
6301 the size of the "near data" increases, it may creep into the bottom of
6305 --stack-after-data, similar to the --stack-loc, but it automatically places
6306 the stack after the end of the "near data".
6307 Again this could waste any spare register space.
6310 --data-loc allows you to specify the start address of the near data.
6311 This could be used to move the "near data" further away from the stack
6312 giving it more room to grow.
6313 This will only work if no bit variables are being used and the stack can
6314 grow to use the bit variable space.
6322 If you find that the stack is over writing your bit variables or "near data"
6323 then the approach which best utilised the internal memory is to position
6324 the "near data" after the last bank of used registers or, if you use bit
6325 variables, after the last bit variable by using the --data-loc, e.g.
6326 if two register banks are being used and no bit variables, --data-loc 16,
6327 and use the --stack-after-data option.
6330 If bit variables are being used, another method would be to try and squeeze
6331 the data area in the unused register banks if it will fit, and start the
6332 stack after the last bit variable.
6335 Retargetting for other MCUs.
6338 The issues for retargetting the compiler are far too numerous to be covered
6340 What follows is a brief description of each of the seven phases of the
6341 compiler and its MCU dependency.
6344 Parsing the source and building the annotated parse tree.
6345 This phase is largely MCU independent (except for the language extensions).
6346 Syntax & semantic checks are also done in this phase, along with some initial
6347 optimizations like back patching labels and the pattern matching optimizations
6348 like bit-rotation etc.
6351 The second phase involves generating an intermediate code which can be easy
6352 manipulated during the later phases.
6353 This phase is entirely MCU independent.
6354 The intermediate code generation assumes the target machine has unlimited
6355 number of registers, and designates them with the name iTemp.
6356 The compiler can be made to dump a human readable form of the code generated
6357 by using the --dumpraw option.
6360 This phase does the bulk of the standard optimizations and is also MCU independe
6362 This phase can be broken down into several sub-phases:
6366 Break down intermediate code (iCode) into basic blocks.
6368 Do control flow & data flow analysis on the basic blocks.
6370 Do local common subexpression elimination, then global subexpression elimination
6372 Dead code elimination
6376 If loop optimizations caused any changes then do 'global subexpression eliminati
6377 on' and 'dead code elimination' again.
6380 This phase determines the live-ranges; by live range I mean those iTemp
6381 variables defined by the compiler that still survive after all the optimization
6383 Live range analysis is essential for register allocation, since these computati
6384 on determines which of these iTemps will be assigned to registers, and for
6388 Phase five is register allocation.
6389 There are two parts to this process.
6393 The first part I call 'register packing' (for lack of a better term).
6394 In this case several MCU specific expression folding is done to reduce
6399 The second part is more MCU independent and deals with allocating registers
6400 to the remaining live ranges.
6401 A lot of MCU specific code does creep into this phase because of the limited
6402 number of index registers available in the 8051.
6405 The Code generation phase is (unhappily), entirely MCU dependent and very
6406 little (if any at all) of this code can be reused for other MCU.
6407 However the scheme for allocating a homogenized assembler operand for each
6408 iCode operand may be reused.
6411 As mentioned in the optimization section the peep-hole optimizer is rule
6412 based system, which can reprogrammed for other MCUs.
6415 SDCDB - Source Level Debugger
6418 SDCC is distributed with a source level debugger.
6419 The debugger uses a command line interface, the command repertoire of the
6420 debugger has been kept as close to gdb (the GNU debugger) as possible.
6421 The configuration and build process is part of the standard compiler installati
6422 on, which also builds and installs the debugger in the target directory
6423 specified during configuration.
6424 The debugger allows you debug BOTH at the C source and at the ASM source
6428 Compiling for Debugging
6433 debug option must be specified for all files for which debug information
6435 The complier generates a .cdb file for each of these files.
6436 The linker updates the .cdb file with the address information.
6437 This .cdb is used by the debugger.
6440 How the Debugger Works
6443 When the --debug option is specified the compiler generates extra symbol
6444 information some of which are put into the the assembler source and some
6445 are put into the .cdb file, the linker updates the .cdb file with the address
6446 information for the symbols.
6447 The debugger reads the symbolic information generated by the compiler &
6448 the address information generated by the linker.
6449 It uses the SIMULATOR (Daniel's S51) to execute the program, the program
6450 execution is controlled by the debugger.
6451 When a command is issued for the debugger, it translates it into appropriate
6452 commands for the simulator.
6455 Starting the Debugger
6458 The debugger can be started using the following command line.
6459 (Assume the file you are debugging has the file name foo).
6473 The debugger will look for the following files.
6476 foo.c - the source file.
6479 foo.cdb - the debugger symbol information file.
6482 foo.ihx - the intel hex format object file.
6485 Command Line Options.
6488 --directory=<source file directory> this option can used to specify the
6489 directory search list.
6490 The debugger will look into the directory list specified for source, cdb
6492 The items in the directory list must be separated by ':', e.g.
6493 if the source files can be in the directories /home/src1 and /home/src2,
6494 the --directory option should be --directory=/home/src1:/home/src2.
6495 Note there can be no spaces in the option.
6499 -cd <directory> - change to the <directory>.
6502 -fullname - used by GUI front ends.
6505 -cpu <cpu-type> - this argument is passed to the simulator please see the
6506 simulator docs for details.
6509 -X <Clock frequency > this options is passed to the simulator please see
6510 the simulator docs for details.
6513 -s <serial port file> passed to simulator see the simulator docs for details.
6516 -S <serial in,out> passed to simulator see the simulator docs for details.
6522 As mention earlier the command interface for the debugger has been deliberately
6523 kept as close the GNU debugger gdb, as possible.
6524 This will help the integration with existing graphical user interfaces
6525 (like ddd, xxgdb or xemacs) existing for the GNU debugger.
6526 \layout Subsubsection
6528 break [line | file:line | function | file:function]
6531 Set breakpoint at specified line or function:
6540 sdcdb>break foo.c:100
6544 sdcdb>break foo.c:funcfoo
6545 \layout Subsubsection
6547 clear [line | file:line | function | file:function ]
6550 Clear breakpoint at specified line or function:
6559 sdcdb>clear foo.c:100
6563 sdcdb>clear foo.c:funcfoo
6564 \layout Subsubsection
6569 Continue program being debugged, after breakpoint.
6570 \layout Subsubsection
6575 Execute till the end of the current function.
6576 \layout Subsubsection
6581 Delete breakpoint number 'n'.
6582 If used without any option clear ALL user defined break points.
6583 \layout Subsubsection
6585 info [break | stack | frame | registers ]
6588 info break - list all breakpoints
6591 info stack - show the function call stack.
6594 info frame - show information about the current execution frame.
6597 info registers - show content of all registers.
6598 \layout Subsubsection
6603 Step program until it reaches a different source line.
6604 \layout Subsubsection
6609 Step program, proceeding through subroutine calls.
6610 \layout Subsubsection
6615 Start debugged program.
6616 \layout Subsubsection
6621 Print type information of the variable.
6622 \layout Subsubsection
6627 print value of variable.
6628 \layout Subsubsection
6633 load the given file name.
6634 Note this is an alternate method of loading file for debugging.
6635 \layout Subsubsection
6640 print information about current frame.
6641 \layout Subsubsection
6646 Toggle between C source & assembly source.
6647 \layout Subsubsection
6652 Send the string following '!' to the simulator, the simulator response is
6654 Note the debugger does not interpret the command being sent to the simulator,
6655 so if a command like 'go' is sent the debugger can loose its execution
6656 context and may display incorrect values.
6657 \layout Subsubsection
6664 My name is Bobby Brown"
6667 Interfacing with XEmacs.
6670 Two files (in emacs lisp) are provided for the interfacing with XEmacs,
6671 sdcdb.el and sdcdbsrc.el.
6672 These two files can be found in the $(prefix)/bin directory after the installat
6674 These files need to be loaded into XEmacs for the interface to work.
6675 This can be done at XEmacs startup time by inserting the following into
6676 your '.xemacs' file (which can be found in your HOME directory):
6682 (load-file sdcdbsrc.el)
6688 .xemacs is a lisp file so the () around the command is REQUIRED.
6689 The files can also be loaded dynamically while XEmacs is running, set the
6690 environment variable 'EMACSLOADPATH' to the installation bin directory
6691 (<installdir>/bin), then enter the following command ESC-x load-file sdcdbsrc.
6692 To start the interface enter the following command:
6706 You will prompted to enter the file name to be debugged.
6711 The command line options that are passed to the simulator directly are bound
6712 to default values in the file sdcdbsrc.el.
6713 The variables are listed below, these values maybe changed as required.
6716 sdcdbsrc-cpu-type '51
6719 sdcdbsrc-frequency '11059200
6725 The following is a list of key mapping for the debugger interface.
6733 ;; Current Listing ::
6750 binding\SpecialChar ~
6789 -------\SpecialChar ~
6829 sdcdb-next-from-src\SpecialChar ~
6855 sdcdb-back-from-src\SpecialChar ~
6881 sdcdb-cont-from-src\SpecialChar ~
6891 SDCDB continue command
6907 sdcdb-step-from-src\SpecialChar ~
6933 sdcdb-whatis-c-sexp\SpecialChar ~
6943 SDCDB ptypecommand for data at
7007 sdcdbsrc-delete\SpecialChar ~
7021 SDCDB Delete all breakpoints if no arg
7069 given or delete arg (C-u arg x)
7085 sdcdbsrc-frame\SpecialChar ~
7100 SDCDB Display current frame if no arg,
7149 given or display frame arg
7214 sdcdbsrc-goto-sdcdb\SpecialChar ~
7224 Goto the SDCDB output buffer
7240 sdcdb-print-c-sexp\SpecialChar ~
7251 SDCDB print command for data at
7315 sdcdbsrc-goto-sdcdb\SpecialChar ~
7325 Goto the SDCDB output buffer
7341 sdcdbsrc-mode\SpecialChar ~
7357 Toggles Sdcdbsrc mode (turns it off)
7361 ;; C-c C-f\SpecialChar ~
7369 sdcdb-finish-from-src\SpecialChar ~
7377 SDCDB finish command
7381 ;; C-x SPC\SpecialChar ~
7389 sdcdb-break\SpecialChar ~
7407 Set break for line with point
7409 ;; ESC t\SpecialChar ~
7419 sdcdbsrc-mode\SpecialChar ~
7435 Toggle Sdcdbsrc mode
7437 ;; ESC m\SpecialChar ~
7447 sdcdbsrc-srcmode\SpecialChar ~
7471 The Z80 and gbz80 port
7474 SDCC can target both the Zilog Z80 and the Nintendo Gameboy's Z80-like gbz80.
7475 The port is incomplete - long support is incomplete (mul, div and mod are
7476 unimplimented), and both float and bitfield support is missing.
7477 Apart from that the code generated is correct.
7480 As always, the code is the authoritave reference - see z80/ralloc.c and z80/gen.c.
7481 The stack frame is similar to that generated by the IAR Z80 compiler.
7482 IX is used as the base pointer, HL is used as a temporary register, and
7483 BC and DE are available for holding varibles.
7484 IY is currently unusued.
7485 Return values are stored in HL.
7486 One bad side effect of using IX as the base pointer is that a functions
7487 stack frame is limited to 127 bytes - this will be fixed in a later version.
7493 SDCC has grown to be a large project.
7494 The compiler alone (without the preprocessor, assembler and linker) is
7495 about 40,000 lines of code (blank stripped).
7496 The open source nature of this project is a key to its continued growth
7498 You gain the benefit and support of many active software developers and
7500 Is SDCC perfect? No, that's why we need your help.
7501 The developers take pride in fixing reported bugs.
7502 You can help by reporting the bugs and helping other SDCC users.
7503 There are lots of ways to contribute, and we encourage you to take part
7504 in making SDCC a great software package.
7510 Send an email to the mailing list at 'user-sdcc@sdcc.sourceforge.net' or 'devel-sd
7511 cc@sdcc.sourceforge.net'.
7512 Bugs will be fixed ASAP.
7513 When reporting a bug, it is very useful to include a small test program
7514 which reproduces the problem.
7515 If you can isolate the problem by looking at the generated assembly code,
7516 this can be very helpful.
7517 Compiling your program with the --dumpall option can sometimes be useful
7518 in locating optimization problems.
7524 Sandeep Dutta (sandeep.dutta@usa.net) - SDCC, the compiler, MCS51 code generator,
7527 Alan Baldwin (baldwin@shop-pdp.kent.edu) - Initial version of ASXXXX & ASLINK.
7530 John Hartman (jhartman@compuserve.com) - Porting ASXXX & ASLINK for 8051
7533 Obukhov (dso@usa.net) - malloc & serial i/o routines.
7536 Daniel Drotos (drdani@mazsola.iit.uni-miskolc.hu) - for his Freeware simulator
7538 Malini Dutta(malini_dutta@hotmail.com) - my wife for her patience and support.
7540 Unknown - for the GNU C - preprocessor.
7542 Michael Hope - The Z80 and Z80GB port, 186 development
7544 Kevin Vigor - The DS390 port.
7546 Johan Knol - Lots of fixes and enhancements, DS390/TINI libs.
7548 Scott Datallo - The PIC port.
7554 Thanks to all the other volunteer developers who have helped with coding,
7555 testing, web-page creation, distribution sets, etc.
7556 You know who you are :-)
7563 This document was initially written by Sandeep Dutta
7566 All product names mentioned herein may be trademarks of their respective
7572 \begin_inset LatexCommand \printindex{}
projects / fw / sdcc / blob