1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
3 <!--Converted with LaTeX2HTML 2K.1beta (1.47)
4 original version by: Nikos Drakos, CBLU, University of Leeds
5 * revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
6 * with significant contributions from:
7 Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
10 <TITLE>lSDCC Compiler User Guide</TITLE>
11 <META NAME="description" CONTENT="lSDCC Compiler User Guide">
12 <META NAME="keywords" CONTENT="SDCCUdoc">
13 <META NAME="resource-type" CONTENT="document">
14 <META NAME="distribution" CONTENT="global">
16 <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
17 <META NAME="Generator" CONTENT="LaTeX2HTML v2K.1beta">
18 <META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
20 <LINK REL="STYLESHEET" HREF="SDCCUdoc.css">
25 <!--Navigation Panel-->
26 <IMG WIDTH="81" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next_inactive"
27 SRC="file:/usr/share/latex2html/icons/nx_grp_g.png">
28 <IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
29 SRC="file:/usr/share/latex2html/icons/up_g.png">
30 <IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
31 SRC="file:/usr/share/latex2html/icons/prev_g.png">
35 <!--End of Navigation Panel-->
40 <H1 ALIGN="CENTER">lSDCC Compiler User Guide</H1>
43 <H2><A NAME="SECTION00010000000000000000">
46 <!--Table of Contents-->
49 <LI><A NAME="tex2html122"
50 HREF="SDCCUdoc.html">1 Introduction</A>
52 <LI><A NAME="tex2html123"
53 HREF="#SECTION00021000000000000000">1.1 About SDCC</A>
54 <LI><A NAME="tex2html124"
55 HREF="#SECTION00022000000000000000">1.2 Open Source</A>
56 <LI><A NAME="tex2html125"
57 HREF="#SECTION00023000000000000000">1.3 Typographic conventions</A>
58 <LI><A NAME="tex2html126"
59 HREF="#SECTION00024000000000000000">1.4 Pending: compatibilaty with previous versions</A>
60 <LI><A NAME="tex2html127"
61 HREF="#SECTION00025000000000000000">1.5 System Requirements</A>
62 <LI><A NAME="tex2html128"
63 HREF="#SECTION00026000000000000000">1.6 Other Resources</A>
66 <LI><A NAME="tex2html129"
67 HREF="#SECTION00030000000000000000">2 Installation</A>
69 <LI><A NAME="tex2html130"
70 HREF="#SECTION00031000000000000000">2.1 Linux/Unix Installation</A>
71 <LI><A NAME="tex2html131"
72 HREF="#SECTION00032000000000000000">2.2 Windows Installation</A>
73 <LI><A NAME="tex2html132"
74 HREF="#SECTION00033000000000000000">2.3 Testing out the SDCC Compiler</A>
75 <LI><A NAME="tex2html133"
76 HREF="#SECTION00034000000000000000">2.4 Install Trouble-shooting</A>
77 <LI><A NAME="tex2html134"
78 HREF="#SECTION00035000000000000000">2.5 Additional Information for Windows Users</A>
79 <LI><A NAME="tex2html135"
80 HREF="#SECTION00036000000000000000">2.6 SDCC on Other Platforms</A>
81 <LI><A NAME="tex2html136"
82 HREF="#SECTION00037000000000000000">2.7 Advanced Install Options</A>
83 <LI><A NAME="tex2html137"
84 HREF="#SECTION00038000000000000000">2.8 Components of SDCC</A>
87 <LI><A NAME="tex2html138"
88 HREF="#SECTION00040000000000000000">3 Using SDCC</A>
90 <LI><A NAME="tex2html139"
91 HREF="#SECTION00041000000000000000">3.1 Compiling</A>
92 <LI><A NAME="tex2html140"
93 HREF="#SECTION00042000000000000000">3.2 Command Line Options</A>
94 <LI><A NAME="tex2html141"
95 HREF="#SECTION00043000000000000000">3.3 MCS51/DS390 Storage Class Language Extensions</A>
96 <LI><A NAME="tex2html142"
97 HREF="#SECTION00044000000000000000">3.4 Pointers</A>
98 <LI><A NAME="tex2html143"
99 HREF="#SECTION00045000000000000000">3.5 Parameters & Local Variables</A>
100 <LI><A NAME="tex2html144"
101 HREF="#SECTION00046000000000000000">3.6 Overlaying</A>
102 <LI><A NAME="tex2html145"
103 HREF="#SECTION00047000000000000000">3.7 Interrupt Service Routines</A>
104 <LI><A NAME="tex2html146"
105 HREF="#SECTION00048000000000000000">3.8 Critical Functions</A>
106 <LI><A NAME="tex2html147"
107 HREF="#SECTION00049000000000000000">3.9 Naked Functions</A>
108 <LI><A NAME="tex2html148"
109 HREF="#SECTION000410000000000000000">3.10 Functions using private banks</A>
110 <LI><A NAME="tex2html149"
111 HREF="#SECTION000411000000000000000">3.11 Absolute Addressing</A>
112 <LI><A NAME="tex2html150"
113 HREF="#SECTION000412000000000000000">3.12 Startup Code</A>
114 <LI><A NAME="tex2html151"
115 HREF="#SECTION000413000000000000000">3.13 Inline Assembler Code</A>
116 <LI><A NAME="tex2html152"
117 HREF="#SECTION000414000000000000000">3.14 int(16 bit) and long (32 bit) Support</A>
118 <LI><A NAME="tex2html153"
119 HREF="#SECTION000415000000000000000">3.15 Floating Point Support</A>
120 <LI><A NAME="tex2html154"
121 HREF="#SECTION000416000000000000000">3.16 MCS51 Memory Models</A>
122 <LI><A NAME="tex2html155"
123 HREF="#SECTION000417000000000000000">3.17 DS390 Memory Models</A>
124 <LI><A NAME="tex2html156"
125 HREF="#SECTION000418000000000000000">3.18 Defines Created by the Compiler</A>
128 <LI><A NAME="tex2html157"
129 HREF="#SECTION00050000000000000000">4 SDCC Technical Data</A>
131 <LI><A NAME="tex2html158"
132 HREF="#SECTION00051000000000000000">4.1 Optimizations</A>
133 <LI><A NAME="tex2html159"
134 HREF="#SECTION00052000000000000000">4.2 Pragmas</A>
135 <LI><A NAME="tex2html160"
136 HREF="#SECTION00053000000000000000">4.3 Library Routines</A>
137 <LI><A NAME="tex2html161"
138 HREF="#SECTION00054000000000000000">4.4 Interfacing with Assembly Routines</A>
139 <LI><A NAME="tex2html162"
140 HREF="#SECTION00055000000000000000">4.5 Global Registers used for Parameter Passing</A>
141 <LI><A NAME="tex2html163"
142 HREF="#SECTION00056000000000000000">4.6 External Stack</A>
143 <LI><A NAME="tex2html164"
144 HREF="#SECTION00057000000000000000">4.7 ANSI-Compliance</A>
145 <LI><A NAME="tex2html165"
146 HREF="#SECTION00058000000000000000">4.8 Cyclomatic Complexity</A>
149 <LI><A NAME="tex2html166"
150 HREF="#SECTION00060000000000000000">5 TIPS</A>
151 <LI><A NAME="tex2html167"
152 HREF="#SECTION00070000000000000000">6 Retargetting for other MCUs.</A>
153 <LI><A NAME="tex2html168"
154 HREF="#SECTION00080000000000000000">7 SDCDB - Source Level Debugger</A>
156 <LI><A NAME="tex2html169"
157 HREF="#SECTION00081000000000000000">7.1 Compiling for Debugging</A>
158 <LI><A NAME="tex2html170"
159 HREF="#SECTION00082000000000000000">7.2 How the Debugger Works</A>
160 <LI><A NAME="tex2html171"
161 HREF="#SECTION00083000000000000000">7.3 Starting the Debugger</A>
162 <LI><A NAME="tex2html172"
163 HREF="#SECTION00084000000000000000">7.4 Command Line Options.</A>
164 <LI><A NAME="tex2html173"
165 HREF="#SECTION00085000000000000000">7.5 Debugger Commands.</A>
166 <LI><A NAME="tex2html174"
167 HREF="#SECTION00086000000000000000">7.6 Interfacing with XEmacs.</A>
170 <LI><A NAME="tex2html175"
171 HREF="#SECTION00090000000000000000">8 Other Processors</A>
173 <LI><A NAME="tex2html176"
174 HREF="#SECTION00091000000000000000">8.1 The Z80 and gbz80 port</A>
177 <LI><A NAME="tex2html177"
178 HREF="#SECTION000100000000000000000">9 Support</A>
180 <LI><A NAME="tex2html178"
181 HREF="#SECTION000101000000000000000">9.1 Reporting Bugs</A>
182 <LI><A NAME="tex2html179"
183 HREF="#SECTION000102000000000000000">9.2 Acknowledgments</A>
186 <LI><A NAME="tex2html180"
187 HREF="#SECTION000110000000000000000">About this document ...</A>
189 <!--End of Table of Contents-->
193 <H1><A NAME="SECTION00020000000000000000">
199 <H2><A NAME="SECTION00021000000000000000">
204 <I><pending: tabularise these features, this is unreadeble></I>
206 <BR><B>SDCC</B> is a Free ware, retargettable, optimizing ANSI-C compiler
207 by <B>Sandeep Dutta</B> designed for 8 bit Microprocessors. The
208 current version targets Intel MCS51 based Microprocessors(8051,8052,
209 etc), Zilog Z80 based MCUs, and the Dallas 80C390 MCS51 variant. It
210 can be retargetted for other microprocessors, support for PIC, AVR
211 and 186 is under development. The entire source code for the compiler
212 is distributed under GPL. SDCC uses ASXXXX & ASLINK, a Freeware,
213 retargettable assembler & linker. SDCC has extensive language extensions
214 suitable for utilizing various microcontrollers underlying hardware
215 effectively. In addition to the MCU specific optimizations SDCC also
216 does a host of standard optimizations like <I>global sub expression
217 elimination, loop optimizations (loop invariant, strength reduction
218 of induction variables and loop reversing), constant folding & propagation,
219 copy propagation, dead code elimination and jumptables for 'switch'
220 statements.</I> For the back-end SDCC uses a global register allocation
221 scheme which should be well suited for other 8 bit MCUs. The peep
222 hole optimizer uses a rule based substitution mechanism which is MCU
223 dependent. Supported data-types are <I>char (8 bits, 1 byte), short
224 and int (16 bits, 2 bytes), long (32 bit, 4 bytes)</I> and <I>float
225 (4 byte IEEE).</I> The compiler also allows <I>inline assembler code</I>
226 to be embedded anywhere in a function. In addition routines developed
227 in assembly can also be called. SDCC also provides an option to report
228 the relative complexity of a function, these functions can then be
229 further optimized, or hand coded in assembly if needed. SDCC also
230 comes with a companion source level debugger SDCDB, the debugger currently
231 uses ucSim a freeware simulator for 8051 and other micro-controllers.
232 The latest version can be downloaded from <B>http://sdcc.sourceforge.net/
237 <H2><A NAME="SECTION00022000000000000000">
242 All packages used in this compiler system are <I>opensource</I> and
243 <I>freeware</I>; source code for all the sub-packages (asxxxx assembler/linker,
244 pre-processor) is distributed with the package. This documentation
245 is maintained using a freeware word processor (LYX).
248 This program is free software; you can redistribute it and/or modify
249 it under the terms of the GNU General Public License as published
250 by the Free Software Foundation; either version 2, or (at your option)
251 any later version. This program is distributed in the hope that it
252 will be useful, but WITHOUT ANY WARRANTY; without even the implied
253 warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
254 the GNU General Public License for more details. You should have received
255 a copy of the GNU General Public License along with this program;
256 if not, write to the Free Software Foundation, 59 Temple Place - Suite
257 330, Boston, MA 02111-1307, USA. In other words, you are welcome to
258 use, share and improve this program. You are forbidden to forbid anyone
259 else to use, share and improve what you give them. Help stamp out
262 <BR><I><pending: add a link to gnu></I>
266 <H2><A NAME="SECTION00023000000000000000">
267 1.3 Typographic conventions</A>
271 Throughout this manual, we will use the following convention. Commands
272 you have to type in are printed in <I><B>"sans
273 serif"</B></I><I>.</I> Code samples are printed in <TT>typewriter
274 font.</TT> Interesting items and new terms are printed in <I>italicised
279 <H2><A NAME="SECTION00024000000000000000">
280 1.4 Pending: compatibilaty with previous versions</A>
284 This version has numerous bug fixes comperated with the previous version.
285 But we also introduced some incompatibilaties with older versions.
286 Not just for the fun of it, but to make the compiler more stable,
287 efficient and ANSI compliant.
292 directory structure (2.7)
294 vararg pars expl int unless casted
296 never had a regextend
298 no -noreparms anymore
305 <H2><A NAME="SECTION00025000000000000000">
306 1.5 System Requirements</A>
310 What do you need before you start installation of SDCC? A computer,
311 and a desire to compute. The preferred method of installation is to
312 compile SDCC from source using GNU GCC and make. For Windows some
313 pre-compiled binary distributions are available for your convenience.
314 You should have some experience with command line tools and compiler
319 <H2><A NAME="SECTION00026000000000000000">
320 1.6 Other Resources</A>
324 The SDCC home page at http://sdcc.sourceforge.net/ is a great
325 place to find distribution sets. You can also find links to the user
326 mailing lists that offer help or discuss SDCC with other SDCC users.
327 Web links to other SDCC related sites can also be found here. This
328 document can be found in the DOC directory of the source package as
329 a text or HTML file. Some of the other tools (simulator and assembler)
330 included with SDCC contain their own documentation and can be found
331 in the source distribution. If you want the latest unreleased software,
332 the complete source package is available directly by anonymous CVS
333 on cvs.sdcc.sourceforge.net.
337 <H1><A NAME="SECTION00030000000000000000">
343 <H2><A NAME="SECTION00031000000000000000">
344 2.1 Linux/Unix Installation</A>
350 <LI>Download the source package, it will be named something like sdcc-2.x.x.tgz.
352 <LI>Bring up a command line terminal, such as xterm.
354 <LI>Unpack the file using a command like: <I><B>"tar
355 -xzf sdcc-2.x.x.tgz"</B></I>, this will create a sub-directory
356 called sdcc with all of the sources.
358 <LI>Change directory into the main SDCC directory, for example type: <I><B>"cd
359 sdcc"</B></I><I>.</I>
361 <LI>Type <I><B>"./configure"</B></I>. This configures
362 the package for compilation on your system.
364 <LI>Type <I><B>"make"</B></I>. All of the source
365 packages will compile, this can take a while.
367 <LI>Type <I><B>"make install"</B></I> as root. This
368 copies the binary executables to the install directories.
374 <H2><A NAME="SECTION00032000000000000000">
375 2.2 Windows Installation</A>
379 <I><pending: is this complete? where is borland, mingw></I>
382 For installation under Windows you first need to pick between a pre-compiled
383 binary package, or installing the source package along with the Cygwin
384 package. The binary package is the quickest to install, while the
385 Cygwin package includes all of the open source power tools used to
386 compile the complete SDCC source package in the Windows environment.
387 If you are not familiar with the Unix command line environment, you
388 may want to read the section on additional information for Windows
389 users prior to your initial installation.
393 <H3><A NAME="SECTION00032100000000000000">
394 2.2.1 Windows Install Using a Binary Package</A>
400 <LI>Download the binary package and unpack it using your favorite unpacking
401 tool (gunzip, WinZip, etc). This should unpack to a group of sub-directories.
402 An example directory structure after unpacking is: c:\usr\local\bin
403 for the executables, c:\usr\local\share\sdcc\include
404 and c:\usr\local\share\sdcc\lib
405 for the include and libraries.
407 <LI>Adjust your environment PATH to include the location of the bin directory.
408 For example, make a setsdcc.bat file with the following: set PATH=c:\usr\local\bin;%PATH%
410 <LI>When you compile with sdcc, you may need to specify the location of
411 the lib and include folders. For example, sdcc -I c:\usr\local\share\sdcc\include
412 -L c:\usr\local\share\sdcc\lib\small
419 <H3><A NAME="SECTION00032200000000000000">
420 2.2.2 Windows Install Using Cygwin</A>
426 <LI>Download and install the cygwin package from the redhat sitehttp://sources.redhat.com/cygwin/.
427 Currently, this involved downloading a small install program which
428 then automates downloading and installing selected parts of the package
429 (a large 80M byte sized dowload for the whole thing).
431 <LI>Bring up a Unix/Bash command line terminal from the Cygwin menu.
433 <LI>Follow the instructions in the preceding Linux/Unix installation section.
439 <H2><A NAME="SECTION00033000000000000000">
440 2.3 Testing out the SDCC Compiler</A>
444 The first thing you should do after installing your SDCC compiler
445 is to see if it runs. Type <I><B>"sdcc -version"</B></I>
446 at the prompt, and the program should run and tell you the version.
447 If it doesn't run, or gives a message about not finding sdcc program,
448 then you need to check over your installation. Make sure that the
449 sdcc bin directory is in your executable search path defined by the
450 PATH environment setting (see the Trouble-shooting section for suggestions).
451 Make sure that the sdcc program is in the bin folder, if not perhaps
452 something did not install correctly.
455 SDCC binaries are commonly installed in a directory arrangement like
459 <TABLE CELLPADDING=3 BORDER="1">
460 <TR><TD ALIGN="LEFT">/usr/local/bin</TD>
461 <TD ALIGN="LEFT">Holds executables(sdcc, s51, aslink, ...)</TD>
463 <TR><TD ALIGN="LEFT">/usr/local/share/sdcc/lib</TD>
464 <TD ALIGN="LEFT">Holds common C libraries</TD>
466 <TR><TD ALIGN="LEFT">/usr/local/share/sdcc/include</TD>
467 <TD ALIGN="LEFT">Holds common C header files</TD>
472 Make sure the compiler works on a very simple example. Type in the
473 following test.c program using your favorite editor:
476 Compile this using the following command: <I><B>"sdcc
477 -c test.c"</B></I> If all goes well, the compiler will generate
478 a test.asm and test.rel file. Congratulations, you've just compiled
479 your first program with SDCC. We used the -c option to tell SDCC not
480 to link the generated code, just to keep things simple for this step.
483 The next step is to try it with the linker. Type in <I><B>"sdcc
484 test.c"</B></I>. If all goes well the compiler will link with the
485 libraries and produce a test.ihx output file. If this step fails (no
486 test.ihx, and the linker generates warnings), then the problem is
487 most likely that sdcc cannot find the /usr/local/share/sdcc/lib directory
488 (see the Install trouble-shooting section for suggestions).
491 The final test is to ensure sdcc can use the standard header files
492 and libraries. Edit test.c and change it to the following:
494 <BR>#include <string.h>
497 <BR><TT>char str1[10];</TT>
498 <BR><TT> strcpy(str1, "testing");</TT>
502 Compile this by typing <I><B>"sdcc test.c"</B></I>.
503 This should generate a test.ihx output file, and it should give no
504 warnings such as not finding the string.h file. If it cannot find
505 the string.h file, then the problem is that sdcc cannot find the /usr/local/share/sdcc/include
506 directory (see the Install trouble-shooting section for suggestions).
510 <H2><A NAME="SECTION00034000000000000000">
511 2.4 Install Trouble-shooting</A>
516 <H3><A NAME="SECTION00034100000000000000">
517 2.4.1 SDCC cannot find libraries or header files.</A>
521 The default installation assumes the libraries and header files are
522 located at ``/usr/local/share/sdcc/lib'' and ``/usr/local/share/sdcc/include''.
523 An alternative is to specify these locations as compiler options like
524 this: <I><B>"sdcc -L /usr/local/sdcc/lib/small -I /usr/local/sdcc/include test.c"</B></I>.
528 <H3><A NAME="SECTION00034200000000000000">
529 2.4.2 SDCC does not compile correctly.</A>
533 A thing to try is starting from scratch by unpacking the .tgz source
534 package again in an empty directory. Confure it again and build like:
536 <BR><I><B>make 2SPMamp;>1 | tee make.log</B></I>
539 After this you can review the make.log file to locate the problem.
540 Or a relevant part of this be attached to an email that could be helpful
541 when requesting help from the mailing list.
545 <H3><A NAME="SECTION00034300000000000000">
546 2.4.3 What the ''./configure'' does</A>
550 The ''./configure'' command is a script that analyzes your system
551 and performs some configuration to ensure the source package compiles
552 on your system. It will take a few minutes to run, and will compile
553 a few tests to determine what compiler features are installed.
557 <H3><A NAME="SECTION00034400000000000000">
558 2.4.4 What the ''make'' does.</A>
562 This runs the GNU make tool, which automatically compiles all the
563 source packages into the final installed binary executables.
567 <H3><A NAME="SECTION00034500000000000000">
568 2.4.5 What the ''make install'' command does.</A>
572 This will install the compiler, other executables and libraries in
573 to the appropriate system directories. The default is to copy the
574 executables to /usr/local/bin and the libraries and header files to
575 /usr/local/share/sdcc/lib and /usr/local/share/sdcc/include.
579 <H2><A NAME="SECTION00035000000000000000">
580 2.5 Additional Information for Windows Users</A>
584 <I><pending: is this up to date?></I>
587 The standard method of installing on a Unix system involves compiling
588 the source package. This is easily done under Unix, but under Windows
589 it can be a more difficult process. The Cygwin is a large package
590 to download, and the compilation runs considerably slower under Windows
591 due to the overhead of the Cygwin tool set. An alternative is to install
592 a pre-compiled Windows binary package. There are various trade-offs
593 between each of these methods.
596 The Cygwin package allows a Windows user to run a Unix command line
597 interface (bash shell) and also implements a Unix like file system
598 on top of Windows. Included are many of the famous GNU software development
599 tools which can augment the SDCC compiler.This is great if you have
600 some experience with Unix command line tools and file system conventions,
601 if not you may find it easier to start by installing a binary Windows
602 package. The binary packages work with the Windows file system conventions.
606 <H3><A NAME="SECTION00035100000000000000">
607 2.5.1 Getting started with Cygwin</A>
611 SDCC is typically distributed as a tarred/gzipped file (.tgz). This
612 is a packed file similar to a .zip file. Cygwin includes the tools
613 you will need to unpack the SDCC distribution (tar and gzip). To unpack
614 it, simply follow the instructions under the Linux/Unix install section.
615 Before you do this you need to learn how to start a cygwin shell and
616 some of the basic commands used to move files, change directory, run
617 commands and so on. The change directory command is <I><B>``cd''</B></I>,
618 the move command is <I><B>``mv''</B></I>. To print the current
619 working directory, type <I><B>``pwd''</B></I>. To make a directory,
620 use <I><B>``mkdir''</B></I>.
623 There are some basic differences between Unix and Windows file systems
624 you should understand. When you type in directory paths, Unix and
625 the Cygwin bash prompt uses forward slashes '/' between directories
626 while Windows traditionally uses '\' backward slashes.
627 So when you work at the Cygwin bash prompt, you will need to use the
628 forward '/' slashes. Unix does not have a concept of drive letters,
629 such as ``c:``, instead all files systems attach and appear
634 <H3><A NAME="SECTION00035200000000000000">
635 2.5.2 Running SDCC as Native Compiled Executables</A>
639 If you use the pre-compiled binaries, the install directories for
640 the libraries and header files may need to be specified on the sdcc
641 command line like this: <I><B>"sdcc -L c:\usr\local\sdcc\lib\small
642 -I c:\usr\local\sdcc\include
643 test.c"</B></I> if you are running outside of a Unix bash shell.
646 If you have successfully installed and compiled SDCC with the Cygwin
647 package, it is possible to compile into native .exe files by using
648 the additional makefiles included for this purpose. For example, with
649 the Borland 32-bit compiler you would run <I><B>"make
650 -f Makefile.bcc"</B></I>. A command line version of the Borland
651 32-bit compiler can be downloaded from the Inprise web site.
655 <H2><A NAME="SECTION00036000000000000000">
656 2.6 SDCC on Other Platforms</A>
662 <LI><B>FreeBSD and other non-GNU Unixes</B> - Make sure the GNU make
663 is installed as the default make tool.
665 <LI>SDCC has been ported to run under a variety of operating systems and
666 processors. If you can run GNU GCC/make then chances are good SDCC
667 can be compiled and run on your system.
673 <H2><A NAME="SECTION00037000000000000000">
674 2.7 Advanced Install Options</A>
678 The ``configure'' command has several options. The most commonly
679 used option is -prefix=<directory name>, where <directory name> is
680 the final location for the sdcc executables and libraries, (default
681 location is /usr/local). The installation process will create the
682 following directory structure under the <directory name> specified
683 (if they do not already exist).
686 bin/ - binary exectables (add to PATH environment variable)
690 bin/share/sdcc/include/ - include header files
694 bin/share/sdcc/lib/small/ - Object & library files for small model
697 bin/share/sdcc/lib/large/ - Object & library files for large model
700 bin/share/sdcc/lib/ds390/ - Object & library files forDS80C390 library
703 The command <I><B>''./configure -prefix=/usr/local''</B></I>
704 will configure the compiler to be installed in directory /usr/local/bin.
708 <H2><A NAME="SECTION00038000000000000000">
709 2.8 Components of SDCC</A>
713 SDCC is not just a compiler, but a collection of tools by various
714 developers. These include linkers, assemblers, simulators and other
715 components. Here is a summary of some of the components. Note that
716 the included simulator and assembler have separate documentation which
717 you can find in the source package in their respective directories.
718 As SDCC grows to include support for other processors, other packages
719 from various developers are included and may have their own sets of
723 You might want to look at the various executables which are installed
724 in the bin directory. At the time of this writing, we find the following
727 <BR><I><pending: tabularize this></I>
729 <BR><B>sdcc</B> - The compiler.
730 <BR><B>sdcpp</B> - The C preprocessor.
731 <BR><B>asx8051</B> - The assembler for 8051 type processors.
732 <BR><B>as-z80, as-gbz80</B> - The Z80 and GameBoy Z80 assemblers.
733 <BR><B>aslink</B> -The linker for 8051 type processors.
734 <BR><B>link-z80, link-gbz80</B> - The Z80 and GameBoy Z80 linkers.
735 <BR><B>s51</B> - The ucSim 8051 simulator.
736 <BR><B>sdcdb</B> - The source debugger.
737 <BR><B>packihx</B> - A tool to pack Intel hex files.
740 As development for other processors proceeds, this list will expand
741 to include executables to support processors like AVR, PIC, etc.
745 <H3><A NAME="SECTION00038100000000000000">
746 2.8.1 sdcc - The Compiler</A>
750 This is the actual compiler, it in turn uses the c-preprocessor and
751 invokes the assembler and linkage editor.
755 <H3><A NAME="SECTION00038200000000000000">
756 2.8.2 sdcpp (C-Preprocessor)</A>
760 The preprocessor is a modified version of the GNU preprocessor. The
761 C preprocessor is used to pull in #include sources, process #ifdef
762 statements, #defines and so on.
766 <H3><A NAME="SECTION00038300000000000000">
767 2.8.3 asx8051, as-z80, as-gbz80, aslink, link-z80, link-gbz80 (The Assemblers
768 and Linkage Editors)</A>
772 This is retargettable assembler & linkage editor, it was developed
773 by Alan Baldwin. John Hartman created the version for 8051, and I
774 (Sandeep) have made some enhancements and bug fixes for it to work
775 properly with the SDCC.
779 <H3><A NAME="SECTION00038400000000000000">
780 2.8.4 s51 - Simulator</A>
784 S51 is a freeware, opensource simulator developed by Daniel Drotos
785 (mailto:drdani@mazsola.iit.uni-miskolc.hu). The simulator is
786 built as part of the build process. For more information visit Daniel's
787 website at: http://mazsola.iit.uni-miskolc.hu/ drdani/embedded/s51
792 <H3><A NAME="SECTION00038500000000000000">
793 2.8.5 sdcdb - Source Level Debugger</A>
797 Sdcdb is the companion source level debugger. The current version
798 of the debugger uses Daniel's Simulator S51, but can be easily changed
799 to use other simulators.
803 <H1><A NAME="SECTION00040000000000000000">
809 <H2><A NAME="SECTION00041000000000000000">
815 <H3><A NAME="SECTION00041100000000000000">
816 3.1.1 Single Source File Projects</A>
820 For single source file 8051 projects the process is very simple. Compile
821 your programs with the following command <I><B>"sdcc
822 sourcefile.c".</B></I> This will compile, assemble and link your
823 source file. Output files are as follows
826 sourcefile.asm - Assembler source file created by the compiler
828 sourcefile.lst - Assembler listing file created by the Assembler
830 sourcefile.rst - Assembler listing file updated with linkedit information,
831 created by linkage editor
833 sourcefile.sym - symbol listing for the sourcefile, created by the
836 sourcefile.rel - Object file created by the assembler, input to Linkage
839 sourcefile.map - The memory map for the load module, created by the
842 sourcefile.ihx - The load module in Intel hex format (you can select
843 the Motorola S19 format with -out-fmt-s19)
845 sourcefile.cdb - An optional file (with -debug) containing debug
850 <H3><A NAME="SECTION00041200000000000000">
851 3.1.2 Projects with Multiple Source Files</A>
855 SDCC can compile only ONE file at a time. Let us for example assume
856 that you have a project containing the following files:
859 foo1.c (contains some functions)
861 foo2.c (contains some more functions)
863 foomain.c (contains more functions and the function main)
866 The first two files will need to be compiled separately with the commands:
869 <BR><I><B>sdcc -c foo1.c</B></I>
870 <BR><I><B>sdcc -c foo2.c</B></I>
873 Then compile the source file containing the <I>main()</I> function
874 and link the files together with the following command:
876 <BR><I><B>sdcc foomain.c foo1.rel foo2.rel</B></I>
879 Alternatively, <I>foomain.c</I> can be separately compiled as well:
881 <BR><I><B>sdcc -c foomain.c</B></I>
882 <BR><I><B>sdcc foomain.rel foo1.rel foo2.rel</B></I>
885 The file containing the <I>main()</I> function <SMALL>MUST</SMALL>
886 be the <SMALL>FIRST</SMALL> file specified in the command line, since the
887 linkage editor processes file in the order they are presented to it.
891 <H3><A NAME="SECTION00041300000000000000">
892 3.1.3 Projects with Additional Libraries</A>
896 Some reusable routines may be compiled into a library, see the documentation
897 for the assembler and linkage editor (which are in <installdir>/share/sdcc/doc)
898 for how to create a <I>.lib</I> library file. Libraries created in
899 this manner can be included in the command line. Make sure you include
900 the -L <library-path> option to tell the linker where to look for
901 these files if they are not in the current directory. Here is an example,
902 assuming you have the source file <I>foomain.c</I> and a library <I>foolib.lib</I>
903 in the directory <I>mylib</I> (if that is not the same as your current
906 <BR><I><B>sdcc foomain.c foolib.lib -L mylib</B></I>
909 Note here that <I>mylib</I> must be an absolute path name.
912 The most efficient way to use libraries is to keep seperate modules
913 in seperate source files. The lib file now should name all the modules.rel
914 files. For an example see the standard library file <I>libsdcc.lib</I>
915 in the directory <installdir>/share/lib/small.
919 <H2><A NAME="SECTION00042000000000000000">
920 3.2 Command Line Options</A>
925 <H3><A NAME="SECTION00042100000000000000">
926 3.2.1 Processor Selection Options</A>
932 <LI>[<B>-mmcs51</B>]Generate code for the MCS51 (8051) family of processors.
933 This is the default processor target.
935 <LI>[<B>-mds390</B>]Generate code for the DS80C390 processor.
937 <LI>[<B>-mz80</B>]Generate code for the Z80 family of processors.
939 <LI>[<B>-mgbz80</B>]Generate code for the GameBoy Z80 processor.
941 <LI>[<B>-mavr</B>]Generate code for the Atmel AVR processor(In development,
944 <LI>[<B>-mpic14</B>]Generate code for the PIC 14-bit processors(In development,
947 <LI>[<B>-mtlcs900h</B>]Generate code for the Toshiba TLCS-900H processor(In
948 development, not complete).
953 <H3><A NAME="SECTION00042200000000000000">
954 3.2.2 Preprocessor Options</A>
960 <LI>[<B>-I<path></B>]The additional location where the pre processor
961 will look for <..h> or ``..h'' files.
963 <LI>[<B>-D<macro[=value]></B>]Command line definition of macros.
964 Passed to the pre processor.
966 <LI>[<B>-M</B>]Tell the preprocessor to output a rule suitable for make
967 describing the dependencies of each object file. For each source file,
968 the preprocessor outputs one make-rule whose target is the object
969 file name for that source file and whose dependencies are all the
970 files `#include'd in it. This rule may be a single line or may be
971 continued with `\'-newline if it is long. The list
972 of rules is printed on standard output instead of the preprocessed
973 C program. `-M' implies `-E'.
975 <LI>[<B>-C</B>]Tell the preprocessor not to discard comments. Used with
978 <LI>[<B>-MM</B>]Like `-M' but the output mentions only the user header
979 files included with `#include ``file"'. System header
980 files included with `#include <file>' are omitted.
982 <LI>[<B>-Aquestion(answer)</B>]Assert the answer answer for question,
983 in case it is tested with a preprocessor conditional such as `#if
984 #question(answer)'. `-A-' disables the standard assertions that normally
985 describe the target machine.
987 <LI>[<B>-Aquestion</B>](answer) Assert the answer answer for question,
988 in case it is tested with a preprocessor conditional such as `#if
989 #question(answer)'. `-A-' disables the standard assertions that normally
990 describe the target machine.
992 <LI>[<B>-Umacro</B>]Undefine macro macro. `-U' options are evaluated
993 after all `-D' options, but before any `-include' and `-imacros' options.
995 <LI>[<B>-dM</B>]Tell the preprocessor to output only a list of the macro
996 definitions that are in effect at the end of preprocessing. Used with
999 <LI>[<B>-dD</B>]Tell the preprocessor to pass all macro definitions
1000 into the output, in their proper sequence in the rest of the output.
1002 <LI>[<B>-dN</B>]Like `-dD' except that the macro arguments and contents
1003 are omitted. Only `#define name' is included in the output.
1008 <H3><A NAME="SECTION00042300000000000000">
1009 3.2.3 Linker Options</A>
1015 <LI>[<B>-L -lib-path</B>]<absolute path to additional libraries> This
1016 option is passed to the linkage editor's additional libraries search
1017 path. The path name must be absolute. Additional library files may
1018 be specified in the command line. See section Compiling programs for
1021 <LI>[<B>-xram-loc</B><Value>]The start location of the external ram,
1022 default value is 0. The value entered can be in Hexadecimal or Decimal
1023 format, e.g.: -xram-loc 0x8000 or -xram-loc 32768.
1025 <LI>[<B>-code-loc</B><Value>]The start location of the code segment,
1026 default value 0. Note when this option is used the interrupt vector
1027 table is also relocated to the given address. The value entered can
1028 be in Hexadecimal or Decimal format, e.g.: -code-loc 0x8000 or -code-loc
1031 <LI>[<B>-stack-loc</B><Value>]The initial value of the stack pointer.
1032 The default value of the stack pointer is 0x07 if only register bank
1033 0 is used, if other register banks are used then the stack pointer
1034 is initialized to the location above the highest register bank used.
1035 eg. if register banks 1 & 2 are used the stack pointer will default
1036 to location 0x18. The value entered can be in Hexadecimal or Decimal
1037 format, eg. -stack-loc 0x20 or -stack-loc 32. If all four register
1038 banks are used the stack will be placed after the data segment (equivalent
1039 to -stack-after-data)
1041 <LI>[<B>-stack-after-data</B>]This option will cause the stack to be
1042 located in the internal ram after the data segment.
1044 <LI>[<B>-data-loc</B><Value>]The start location of the internal ram
1045 data segment, the default value is 0x30.The value entered can be in
1046 Hexadecimal or Decimal format, eg. -data-loc 0x20 or -data-loc 32.
1048 <LI>[<B>-idata-loc</B><Value>]The start location of the indirectly
1049 addressable internal ram, default value is 0x80. The value entered
1050 can be in Hexadecimal or Decimal format, eg. -idata-loc 0x88 or -idata-loc
1053 <LI>[<B>-out-fmt-ihx</B>]The linker output (final object code) is in
1054 Intel Hex format. (This is the default option).
1056 <LI>[<B>-out-fmt-s19</B>]The linker output (final object code) is in
1057 Motorola S19 format.
1062 <H3><A NAME="SECTION00042400000000000000">
1063 3.2.4 MCS51 Options</A>
1069 <LI>[<B>-model-large</B>]Generate code for Large model programs see
1070 section Memory Models for more details. If this option is used all
1071 source files in the project should be compiled with this option. In
1072 addition the standard library routines are compiled with small model,
1073 they will need to be recompiled.
1075 <LI>[<B>-model-small</B>]Generate code for Small Model programs see
1076 section Memory Models for more details. This is the default model.
1081 <H3><A NAME="SECTION00042500000000000000">
1082 3.2.5 DS390 Options</A>
1088 <LI>[<B>-model-flat24</B>]Generate 24-bit flat mode code. This is the
1089 one and only that the ds390 code generator supports right now and
1090 is default when using <I>-mds390</I>. See section Memory Models for
1093 <LI>[<B>-stack-10bit</B>]Generate code for the 10 bit stack mode of
1094 the Dallas DS80C390 part. This is the one and only that the ds390
1095 code generator supports right now and is default when using <I>-mds390</I>.
1096 In this mode, the stack is located in the lower 1K of the internal
1097 RAM, which is mapped to 0x400000. Note that the support is incomplete,
1098 since it still uses a single byte as the stack pointer. This means
1099 that only the lower 256 bytes of the potential 1K stack space will
1100 actually be used. However, this does allow you to reclaim the precious
1101 256 bytes of low RAM for use for the DATA and IDATA segments. The
1102 compiler will not generate any code to put the processor into 10 bit
1103 stack mode. It is important to ensure that the processor is in this
1104 mode before calling any re-entrant functions compiled with this option.
1105 In principle, this should work with the <I>-stack-auto</I> option,
1106 but that has not been tested. It is incompatible with the <I>-xstack</I>
1107 option. It also only makes sense if the processor is in 24 bit contiguous
1108 addressing mode (see the <I>-model-flat24 option</I>).
1113 <H3><A NAME="SECTION00042600000000000000">
1114 3.2.6 Optimization Options</A>
1120 <LI>[<B>-nogcse</B>]Will not do global subexpression elimination, this
1121 option may be used when the compiler creates undesirably large stack/data
1122 spaces to store compiler temporaries. A warning message will be generated
1123 when this happens and the compiler will indicate the number of extra
1124 bytes it allocated. It recommended that this option NOT be used, #pragma NOGCSE
1125 can be used to turn off global subexpression elimination for a given
1128 <LI>[<B>-noinvariant</B>]Will not do loop invariant optimizations,
1129 this may be turned off for reasons explained for the previous option.
1130 For more details of loop optimizations performed see section Loop
1131 Invariants.It recommended that this option NOT be used, #pragma NOINVARIANT
1132 can be used to turn off invariant optimizations for a given function
1135 <LI>[<B>-noinduction</B>]Will not do loop induction optimizations,
1136 see section strength reduction for more details.It is recommended
1137 that this option is NOT used, #pragma NOINDUCTION can be used to
1138 turn off induction optimizations for a given function only.
1140 <LI>[<B>-nojtbound</B>] Will not generate boundary condition check
1141 when switch statements are implemented using jump-tables. See section
1142 Switch Statements for more details. It is recommended that this option
1143 is NOT used, #pragma NOJTBOUND can be used to turn off boundary
1144 checking for jump tables for a given function only.
1146 <LI>[<B>-noloopreverse</B>]Will not do loop reversal optimization.
1151 <H3><A NAME="SECTION00042700000000000000">
1152 3.2.7 Other Options</A>
1158 <LI>[<B>-c -compile-only</B>]will compile and assemble the source,
1159 but will not call the linkage editor.
1161 <LI>[<B>-E</B>]Run only the C preprocessor. Preprocess all the C source
1162 files specified and output the results to standard output.
1164 <LI>[<B>-stack-auto</B>]All functions in the source file will be compiled
1165 as <I>reentrant</I>, i.e. the parameters and local variables will
1166 be allocated on the stack. see section Parameters and Local Variables
1167 for more details. If this option is used all source files in the project
1168 should be compiled with this option.
1170 <LI>[<B>-xstack</B>]Uses a pseudo stack in the first 256 bytes in the
1171 external ram for allocating variables and passing parameters. See
1172 section on external stack for more details.
1174 <LI>[<B>-callee-saves</B>]<B>function1[,function2][,function3]....</B>
1175 The compiler by default uses a caller saves convention for register
1176 saving across function calls, however this can cause unneccessary
1177 register pushing & popping when calling small functions from larger
1178 functions. This option can be used to switch the register saving convention
1179 for the function names specified. The compiler will not save registers
1180 when calling these functions, no extra code will be generated at the
1181 entry & exit for these functions to save & restore the registers
1182 used by these functions, this can SUBSTANTIALLY reduce code & improve
1183 run time performance of the generated code. In the future the compiler
1184 (with interprocedural analysis) will be able to determine the appropriate
1185 scheme to use for each function call. DO NOT use this option for built-in
1186 functions such as _muluint..., if this option is used for a library
1187 function the appropriate library function needs to be recompiled with
1188 the same option. If the project consists of multiple source files
1189 then all the source file should be compiled with the same -callee-saves
1190 option string. Also see #pragma CALLEE-SAVES.
1192 <LI>[<B>-debug</B>]When this option is used the compiler will generate
1193 debug information, that can be used with the SDCDB. The debug information
1194 is collected in a file with .cdb extension. For more information see
1195 documentation for SDCDB.
1197 <LI>[<B><I>-regextend</I></B>] <I>This option is obsolete and isn't
1198 supported anymore.</I>
1200 <LI>[<B><I>-noregparms</I></B>]<I>This option is obsolete and isn't
1201 supported anymore.</I>
1203 <LI>[<B>-peep-file</B><filename>]This option can be used to use additional
1204 rules to be used by the peep hole optimizer. See section Peep Hole
1205 optimizations for details on how to write these rules.
1207 <LI>[<B>-S</B>]Stop after the stage of compilation proper; do not assemble.
1208 The output is an assembler code file for the input file specified.
1210 <LI>[<B>-Wa_asmOption[,asmOption]</B>...]Pass the asmOption to
1213 <LI>[<B>-Wl_linkOption[,linkOption]</B>...]Pass the linkOption
1216 <LI>[<B>-int-long-reent</B>] Integer (16 bit) and long (32 bit) libraries
1217 have been compiled as reentrant. Note by default these libraries are
1218 compiled as non-reentrant. See section Installation for more details.
1220 <LI>[<B>-cyclomatic</B>]This option will cause the compiler to generate
1221 an information message for each function in the source file. The message
1222 contains some <I>important</I> information about the function. The
1223 number of edges and nodes the compiler detected in the control flow
1224 graph of the function, and most importantly the <I>cyclomatic complexity</I>
1225 see section on Cyclomatic Complexity for more details.
1227 <LI>[<B>-float-reent</B>] Floating point library is compiled as reentrant.See
1228 section Installation for more details.
1230 <LI>[<B>-nooverlay</B>] The compiler will not overlay parameters and
1231 local variables of any function, see section Parameters and local
1232 variables for more details.
1234 <LI>[<B>-main-return</B>]This option can be used when the code generated
1235 is called by a monitor program. The compiler will generate a 'ret'
1236 upon return from the 'main' function. The default option is to lock
1237 up i.e. generate a 'ljmp '.
1239 <LI>[<B>-no-peep</B>] Disable peep-hole optimization.
1241 <LI>[<B>-peep-asm</B>] Pass the inline assembler code through the peep
1242 hole optimizer. This can cause unexpected changes to inline assembler
1243 code, please go through the peephole optimizer rules defined in the
1244 source file tree '<target>/peeph.def' before using this option.
1246 <LI>[<B>-iram-size</B><Value>]Causes the linker to check if the interal
1247 ram usage is within limits of the given value.
1249 <LI>[<B>-nostdincl</B>]This will prevent the compiler from passing
1250 on the default include path to the preprocessor.
1252 <LI>[<B>-nostdlib</B>]This will prevent the compiler from passing on
1253 the default library path to the linker.
1255 <LI>[<B>-verbose</B>]Shows the various actions the compiler is performing.
1257 <LI>[<B>-V</B>]Shows the actual commands the compiler is executing.
1262 <H3><A NAME="SECTION00042800000000000000">
1263 3.2.8 Intermediate Dump Options</A>
1267 The following options are provided for the purpose of retargetting
1268 and debugging the compiler. These provided a means to dump the intermediate
1269 code (iCode) generated by the compiler in human readable form at various
1270 stages of the compilation process.
1275 <LI>[<B>-dumpraw</B>]This option will cause the compiler to dump the
1276 intermediate code into a file of named <I><source filename>.dumpraw</I>
1277 just after the intermediate code has been generated for a function,
1278 i.e. before any optimizations are done. The basic blocks at this stage
1279 ordered in the depth first number, so they may not be in sequence
1282 <LI>[<B>-dumpgcse</B>]Will create a dump of iCode's, after global subexpression
1283 elimination, into a file named <I><source filename>.dumpgcse.</I>
1285 <LI>[<B>-dumpdeadcode</B>]Will create a dump of iCode's, after deadcode
1286 elimination, into a file named <I><source filename>.dumpdeadcode.</I>
1288 <LI>[<B>-dumploop</B>]Will create a dump of iCode's, after loop optimizations,
1289 into a file named <I><source filename>.dumploop.</I>
1291 <LI>[<B>-dumprange</B>]Will create a dump of iCode's, after live range
1292 analysis, into a file named <I><source filename>.dumprange.</I>
1294 <LI>[<B>-dumlrange</B>]Will dump the life ranges for all symbols.
1296 <LI>[<B>-dumpregassign</B>]Will create a dump of iCode's, after register
1297 assignment, into a file named <I><source filename>.dumprassgn.</I>
1299 <LI>[<B>-dumplrange</B>]Will create a dump of the live ranges of iTemp's
1301 <LI>[<B>-dumpall</B>]Will cause all the above mentioned dumps to be
1307 <H2><A NAME="SECTION00043000000000000000">
1308 3.3 MCS51/DS390 Storage Class Language Extensions</A>
1312 In addition to the ANSI storage classes SDCC allows the following
1313 MCS51 specific storage classes.
1317 <H3><A NAME="SECTION00043100000000000000">
1322 Variables declared with this storage class will be placed in the extern
1323 RAM. This is the <B>default</B> storage class for Large Memory model,
1326 <BR><TT>xdata unsigned char xduc;</TT>
1330 <H3><A NAME="SECTION00043200000000000000">
1335 This is the <B>default</B> storage class for Small Memory model.
1336 Variables declared with this storage class will be allocated in the
1339 <BR><TT>data int iramdata;</TT>
1343 <H3><A NAME="SECTION00043300000000000000">
1348 Variables declared with this storage class will be allocated into
1349 the indirectly addressable portion of the internal ram of a 8051,
1352 <BR><TT>idata int idi;</TT>
1356 <H3><A NAME="SECTION00043400000000000000">
1361 This is a data-type and a storage class specifier. When a variable
1362 is declared as a bit, it is allocated into the bit addressable memory
1365 <BR><TT>bit iFlag;</TT>
1369 <H3><A NAME="SECTION00043500000000000000">
1370 3.3.5 sfr / sbit</A>
1374 Like the bit keyword, <I>sfr / sbit</I> signifies both a data-type
1375 and storage class, they are used to describe the special function
1376 registers and special bit variables of a 8051, eg:
1378 <BR><TT>sfr at 0x80 P0; /* special function register P0 at location
1380 <BR><TT>sbit at 0xd7 CY; /* CY (Carry Flag) */</TT>
1384 <H2><A NAME="SECTION00044000000000000000">
1389 SDCC allows (via language extensions) pointers to explicitly point
1390 to any of the memory spaces of the 8051. In addition to the explicit
1391 pointers, the compiler also allows a <I>_generic</I> class of pointers
1392 which can be used to point to any of the memory spaces.
1395 Pointer declaration examples:
1397 <BR><TT>/* pointer physically in xternal ram pointing to object
1398 in internal ram */ </TT>
1399 <BR><TT>data unsigned char * xdata p;</TT>
1401 <BR><TT>/* pointer physically in code rom pointing to data in xdata
1402 space */ </TT>
1403 <BR><TT>xdata unsigned char * code p;</TT>
1405 <BR><TT>/* pointer physically in code space pointing to data in
1406 code space */ </TT>
1407 <BR><TT>code unsigned char * code p;</TT>
1409 <BR><TT>/* the folowing is a generic pointer physically located
1410 in xdata space */</TT>
1411 <BR><TT>char * xdata p;</TT>
1414 Well you get the idea.
1416 <BR><I>For compatibility with the previous version of the compiler,
1417 the following syntax for pointer declaration is still supported but
1418 will disappear int the near future. </I>
1420 <BR><TT><I>unsigned char _xdata *ucxdp; /* pointer to data
1421 in external ram */ </I></TT>
1422 <BR><TT><I>unsigned char _data *ucdp ; /* pointer to data
1423 in internal ram */ </I></TT>
1424 <BR><TT><I>unsigned char _code *uccp ; /* pointer to data
1425 in R/O code space */</I></TT>
1426 <BR><TT><I>unsigned char _idata *uccp; /* pointer to upper
1427 128 bytes of ram */</I></TT>
1430 All unqualified pointers are treated as 3-byte (4-byte for the ds390)
1431 <I>generic</I> pointers. These type of pointers can also to be explicitly
1434 <BR><TT>unsigned char _generic *ucgp;</TT>
1437 The highest order byte of the <I>generic</I> pointers contains the
1438 data space information. Assembler support routines are called whenever
1439 data is stored or retrieved using <I>generic</I> pointers. These are
1440 useful for developing reusable library routines. Explicitly specifying
1441 the pointer type will generate the most efficient code. Pointers declared
1442 using a mixture of OLD and NEW style could have unpredictable results.
1446 <H2><A NAME="SECTION00045000000000000000">
1447 3.5 Parameters & Local Variables</A>
1451 Automatic (local) variables and parameters to functions can either
1452 be placed on the stack or in data-space. The default action of the
1453 compiler is to place these variables in the internal RAM (for small
1454 model) or external RAM (for Large model). This in fact makes them
1455 <I>static</I> so by default functions are non-reentrant.
1458 They can be placed on the stack either by using the <I>-stack-auto</I>
1459 compiler option or by using the <I>reentrant</I> keyword in the function
1462 <BR><TT>unsigned char foo(char i) reentrant </TT>
1463 <BR><TT>{ </TT>
1464 <BR><TT>... </TT>
1465 <BR><TT>}</TT>
1468 Since stack space on 8051 is limited, the <I>reentrant</I> keyword
1469 or the <I>-stack-auto</I> option should be used sparingly. Note that
1470 the reentrant keyword just means that the parameters & local variables
1471 will be allocated to the stack, it <I>does not</I> mean that the function
1472 is register bank independent.
1475 Local variables can be assigned storage classes and absolute addresses,
1478 <BR><TT>unsigned char foo() {</TT>
1479 <BR><TT> xdata unsigned char i;</TT>
1480 <BR><TT> bit bvar;</TT>
1481 <BR><TT> data at 0x31 unsiged char j;</TT>
1482 <BR><TT> ... </TT>
1483 <BR><TT>}</TT>
1486 In the above example the variable <I>i</I> will be allocated in the
1487 external ram, <I>bvar</I> in bit addressable space and <I>j</I> in
1488 internal ram. When compiled with <I>-stack-auto</I> or when a function
1489 is declared as <I>reentrant</I> this can only be done for static variables.
1492 Parameters however are not allowed any storage class, (storage classes
1493 for parameters will be ignored), their allocation is governed by the
1494 memory model in use, and the reentrancy options.
1498 <H2><A NAME="SECTION00046000000000000000">
1503 For non-reentrant functions SDCC will try to reduce internal ram space
1504 usage by overlaying parameters and local variables of a function (if
1505 possible). Parameters and local variables of a function will be allocated
1506 to an overlayable segment if the function has <I>no other function
1507 calls and the function is non-reentrant and the memory model is small.</I>
1508 If an explicit storage class is specified for a local variable, it
1509 will NOT be overlayed.
1512 Note that the compiler (not the linkage editor) makes the decision
1513 for overlaying the data items. Functions that are called from an interrupt
1514 service routine should be preceded by a #pragma NOOVERLAY if they
1518 Also note that the compiler does not do any processing of inline assembler
1519 code, so the compiler might incorrectly assign local variables and
1520 parameters of a function into the overlay segment if the inline assembler
1521 code calls other c-functions that might use the overlay. In that case
1522 the #pragma NOOVERLAY should be used.
1525 Parameters and Local variables of functions that contain 16 or 32
1526 bit multiplication or division will NOT be overlayed since these are
1527 implemented using external functions, e.g.:
1529 <BR><TT>#pragma SAVE </TT>
1530 <BR><TT>#pragma NOOVERLAY </TT>
1531 <BR><TT>void set_error(unsigned char errcd) </TT>
1532 <BR><TT>{</TT>
1533 <BR><TT> P3 = errcd;</TT>
1534 <BR><TT>} </TT>
1535 <BR><TT>#pragma RESTORE </TT>
1537 <BR><TT>void some_isr () interrupt 2 using 1 </TT>
1538 <BR><TT>{</TT>
1539 <BR><TT> ...</TT>
1540 <BR><TT> set_error(10);</TT>
1541 <BR><TT> ... </TT>
1542 <BR><TT>}</TT>
1545 In the above example the parameter <I>errcd</I> for the function <I>set_error</I>
1546 would be assigned to the overlayable segment if the #pragma NOOVERLAY
1547 was not present, this could cause unpredictable runtime behavior when
1548 called from an ISR. The #pragma NOOVERLAY ensures that the parameters
1549 and local variables for the function are NOT overlayed.
1553 <H2><A NAME="SECTION00047000000000000000">
1554 3.7 Interrupt Service Routines</A>
1558 SDCC allows interrupt service routines to be coded in C, with some
1561 <BR><TT>void timer_isr (void) interrupt 2 using 1 </TT>
1562 <BR><TT>{ </TT>
1563 <BR><TT>.. </TT>
1564 <BR><TT>}</TT>
1567 The number following the <I>interrupt</I> keyword is the interrupt
1568 number this routine will service. The compiler will insert a call
1569 to this routine in the interrupt vector table for the interrupt number
1570 specified. The <I>using</I> keyword is used to tell the compiler to
1571 use the specified register bank (8051 specific) when generating code
1572 for this function. Note that when some function is called from an
1573 interrupt service routine it should be preceded by a #pragma NOOVERLAY
1574 if it is not reentrant. A special note here, int (16 bit) and long
1575 (32 bit) integer division, multiplication & modulus operations are
1576 implemented using external support routines developed in ANSI-C, if
1577 an interrupt service routine needs to do any of these operations then
1578 the support routines (as mentioned in a following section) will have
1579 to be recompiled using the <I>-stack-auto</I> option and the source
1580 file will need to be compiled using the <I>-int-long-ren</I>t compiler
1584 If you have multiple source files in your project, interrupt service
1585 routines can be present in any of them, but a prototype of the isr
1586 MUST be present or included in the file that contains the function
1590 Interrupt Numbers and the corresponding address & descriptions for
1591 the Standard 8051 are listed below. SDCC will automatically adjust
1592 the interrupt vector table to the maximum interrupt number specified.
1595 <TABLE CELLPADDING=3 BORDER="1">
1596 <TR><TD ALIGN="CENTER">Interrupt #</TD>
1597 <TD ALIGN="CENTER">Description</TD>
1598 <TD ALIGN="CENTER">Vector Address</TD>
1600 <TR><TD ALIGN="CENTER">0</TD>
1601 <TD ALIGN="CENTER">External 0</TD>
1602 <TD ALIGN="CENTER">0x0003</TD>
1604 <TR><TD ALIGN="CENTER">1</TD>
1605 <TD ALIGN="CENTER">Timer 0</TD>
1606 <TD ALIGN="CENTER">0x000B</TD>
1608 <TR><TD ALIGN="CENTER">2</TD>
1609 <TD ALIGN="CENTER">External 1</TD>
1610 <TD ALIGN="CENTER">0x0013</TD>
1612 <TR><TD ALIGN="CENTER">3</TD>
1613 <TD ALIGN="CENTER">Timer 1</TD>
1614 <TD ALIGN="CENTER">0x001B</TD>
1616 <TR><TD ALIGN="CENTER">4</TD>
1617 <TD ALIGN="CENTER">Serial</TD>
1618 <TD ALIGN="CENTER">0x0023</TD>
1623 If the interrupt service routine is defined without <I>using</I> a
1624 register bank or with register bank 0 (using 0), the compiler will
1625 save the registers used by itself on the stack upon entry and restore
1626 them at exit, however if such an interrupt service routine calls another
1627 function then the entire register bank will be saved on the stack.
1628 This scheme may be advantageous for small interrupt service routines
1629 which have low register usage.
1632 If the interrupt service routine is defined to be using a specific
1633 register bank then only <I>a, b & dptr</I> are save and restored,
1634 if such an interrupt service routine calls another function (using
1635 another register bank) then the entire register bank of the called
1636 function will be saved on the stack. This scheme is recommended for
1637 larger interrupt service routines.
1640 Calling other functions from an interrupt service routine is not recommended,
1641 avoid it if possible.
1644 Also see the _naked modifier.
1648 <H2><A NAME="SECTION00048000000000000000">
1649 3.8 Critical Functions</A>
1653 A special keyword may be associated with a function declaring it as
1654 <I>critical</I>. SDCC will generate code to disable all interrupts
1655 upon entry to a critical function and enable them back before returning.
1656 Note that nesting critical functions may cause unpredictable results.
1658 <BR><TT>int foo () critical </TT>
1659 <BR><TT>{ </TT>
1660 <BR><TT>... </TT>
1661 <BR><TT>... </TT>
1662 <BR><TT>}</TT>
1665 The critical attribute maybe used with other attributes like <I>reentrant.</I>
1669 <H2><A NAME="SECTION00049000000000000000">
1670 3.9 Naked Functions</A>
1674 A special keyword may be associated with a function declaring it as
1675 <I>_naked.</I> The <I>_naked</I> function modifier attribute prevents
1676 the compiler from generating prologue and epilogue code for that function.
1677 This means that the user is entirely responsible for such things as
1678 saving any registers that may need to be preserved, selecting the
1679 proper register bank, generating the <I>return</I> instruction at
1680 the end, etc. Practically, this means that the contents of the function
1681 must be written in inline assembler. This is particularly useful for
1682 interrupt functions, which can have a large (and often unnecessary)
1683 prologue/epilogue. For example, compare the code generated by these
1686 <BR><TT>data unsigned char counter;</TT>
1687 <BR><TT>void simpleInterrupt(void) interrupt 1</TT>
1688 <BR><TT>{</TT>
1689 <BR><TT> counter++;</TT>
1690 <BR><TT>}</TT>
1692 <BR><TT>void nakedInterrupt(void) interrupt 2 _naked</TT>
1693 <BR><TT>{</TT>
1694 <BR><TT> _asm</TT>
1695 <BR><TT> inc _counter</TT>
1696 <BR><TT> reti ; MUST explicitly include ret in _naked
1697 function.</TT>
1698 <BR><TT> _endasm;</TT>
1702 For an 8051 target, the generated simpleInterrupt looks like:
1704 <BR><TT>_simpleIterrupt:</TT>
1705 <BR><TT> push acc</TT>
1706 <BR><TT> push b</TT>
1707 <BR><TT> push dpl</TT>
1708 <BR><TT> push dph</TT>
1709 <BR><TT> push psw</TT>
1710 <BR><TT> mov psw,#0x00</TT>
1711 <BR><TT> inc _counter</TT>
1712 <BR><TT> pop psw</TT>
1713 <BR><TT> pop dph</TT>
1714 <BR><TT> pop dpl</TT>
1715 <BR><TT> pop b</TT>
1716 <BR><TT> pop acc</TT>
1717 <BR><TT> reti</TT>
1720 whereas nakedInterrupt looks like:
1722 <BR><TT>_nakedInterrupt:</TT>
1723 <BR><TT> inc _counter</TT>
1724 <BR><TT> reti ; MUST explicitly include ret(i) in _naked
1728 While there is nothing preventing you from writing C code inside a
1729 _naked function, there are many ways to shoot yourself in the foot
1730 doing this, and is is recommended that you stick to inline assembler.
1734 <H2><A NAME="SECTION000410000000000000000">
1735 3.10 Functions using private banks</A>
1739 The <I>using</I> attribute (which tells the compiler to use a register
1740 bank other than the default bank zero) should only be applied to <I>interrupt</I>
1741 functions (see note 1 below). This will in most circumstances make
1742 the generated ISR code more efficient since it will not have to save
1743 registers on the stack.
1746 The <I>using</I> attribute will have no effect on the generated code
1747 for a <I>non-interrupt</I> function (but may occasionally be useful
1748 anyway<A NAME="tex2html1"
1749 HREF="#foot513"><SUP>1</SUP></A>).
1750 <BR><I>(pending: I don't think this has been done yet)</I>
1753 An <I>interrupt</I> function using a non-zero bank will assume that
1754 it can trash that register bank, and will not save it. Since high-priority
1755 interrupts can interrupt low-priority ones on the 8051 and friends,
1756 this means that if a high-priority ISR <I>using</I> a particular bank
1757 occurs while processing a low-priority ISR <I>using</I> the same bank,
1758 terrible and bad things can happen. To prevent this, no single register
1759 bank should be <I>used</I> by both a high priority and a low priority
1760 ISR. This is probably most easily done by having all high priority
1761 ISRs use one bank and all low priority ISRs use another. If you have
1762 an ISR which can change priority at runtime, you're on your own: I
1763 suggest using the default bank zero and taking the small performance
1767 It is most efficient if your ISR calls no other functions. If your
1768 ISR must call other functions, it is most efficient if those functions
1769 use the same bank as the ISR (see note 1 below); the next best is
1770 if the called functions use bank zero. It is very inefficient to call
1771 a function using a different, non-zero bank from an ISR.
1775 <H2><A NAME="SECTION000411000000000000000">
1776 3.11 Absolute Addressing</A>
1780 Data items can be assigned an absolute address with the <I>at <address></I>
1781 keyword, in addition to a storage class, e.g.:
1783 <BR><TT>xdata at 0x8000 unsigned char PORTA_8255 ;</TT>
1786 In the above example the PORTA_8255 will be allocated to the location
1787 0x8000 of the external ram. Note that this feature is provided to
1788 give the programmer access to <I>memory mapped</I> devices attached
1789 to the controller. The compiler does not actually reserve any space
1790 for variables declared in this way (they are implemented with an equate
1791 in the assembler). Thus it is left to the programmer to make sure
1792 there are no overlaps with other variables that are declared without
1793 the absolute address. The assembler listing file (.lst) and the linker
1794 output files (.rst) and (.map) are a good places to look for such
1798 Absolute address can be specified for variables in all storage classes,
1801 <BR><TT>bit at 0x02 bvar;</TT>
1804 The above example will allocate the variable at offset 0x02 in the
1805 bit-addressable space. There is no real advantage to assigning absolute
1806 addresses to variables in this manner, unless you want strict control
1807 over all the variables allocated.
1811 <H2><A NAME="SECTION000412000000000000000">
1812 3.12 Startup Code</A>
1816 The compiler inserts a call to the C routine <I>_sdcc__external__startup()</I>
1817 at the start of the CODE area. This routine is in the runtime library.
1818 By default this routine returns 0, if this routine returns a non-zero
1819 value, the static & global variable initialization will be skipped
1820 and the function main will be invoked Other wise static & global
1821 variables will be initialized before the function main is invoked.
1822 You could add a <I>_sdcc__external__startup()</I> routine to
1823 your program to override the default if you need to setup hardware
1824 or perform some other critical operation prior to static & global
1825 variable initialization.
1829 <H2><A NAME="SECTION000413000000000000000">
1830 3.13 Inline Assembler Code</A>
1834 SDCC allows the use of in-line assembler with a few restriction as
1835 regards labels. All labels defined within inline assembler code <I>has
1836 to be</I> of the form <I>nnnnn$</I> where nnnn is a number less than
1837 100 (which implies a limit of utmost 100 inline assembler labels <I>per
1838 function</I>). It is strongly recommended that each assembly
1839 instruction (including labels) be placed in a separate line (as the
1840 example shows). When the <I>-peep-asm</I> command line option is
1841 used, the inline assembler code will be passed through the peephole
1842 optimizer. This might cause some unexpected changes in the inline
1843 assembler code. Please go throught the peephole optimizer rules defined
1844 in file <I>SDCCpeeph.def</I> carefully before using this option.
1846 <BR><TT>_asm </TT>
1847 <BR><TT> mov b,#10 </TT>
1848 <BR><TT>00001$: </TT>
1849 <BR><TT> djnz b,00001$ </TT>
1850 <BR><TT>_endasm ;</TT>
1853 The inline assembler code can contain any valid code understood by
1854 the assembler, this includes any assembler directives and comment
1855 lines. The compiler does not do any validation of the code within
1856 the <TT>_asm ... _endasm;</TT> keyword pair.
1859 Inline assembler code cannot reference any C-Labels, however it can
1860 reference labels defined by the inline assembler, e.g.:
1862 <BR><TT>foo() { </TT>
1863 <BR><TT> /* some c code */ </TT>
1864 <BR><TT> _asm </TT>
1865 <BR><TT> ; some assembler code </TT>
1866 <BR><TT> ljmp $0003 </TT>
1867 <BR><TT> _endasm; </TT>
1868 <BR><TT> /* some more c code */ </TT>
1869 <BR><TT>clabel: /* inline assembler cannot reference this label
1871 <BR><TT> _asm</TT>
1872 <BR><TT> $0003: ;label (can be reference by inline assembler
1874 <BR><TT> _endasm ; </TT>
1875 <BR><TT> /* some more c code */</TT>
1876 <BR><TT>}</TT>
1879 In other words inline assembly code can access labels defined in inline
1880 assembly within the scope of the funtion.
1883 The same goes the other way, ie. labels defines in inline assembly
1884 CANNOT be accessed by C statements.
1888 <H2><A NAME="SECTION000414000000000000000">
1889 3.14 int(16 bit) and long (32 bit) Support</A>
1893 For signed & unsigned int (16 bit) and long (32 bit) variables, division,
1894 multiplication and modulus operations are implemented by support routines.
1895 These support routines are all developed in ANSI-C to facilitate porting
1896 to other MCUs, although some model specific assembler optimations
1897 are used. The following files contain the described routine, all of
1898 them can be found in <installdir>/share/sdcc/lib.
1900 <BR><I><pending: tabularise this></I>
1903 _mulsint.c - signed 16 bit multiplication (calls _muluint)
1905 _muluint.c - unsigned 16 bit multiplication
1907 _divsint.c - signed 16 bit division (calls _divuint)
1909 _divuint.c - unsigned 16 bit division
1911 _modsint.c - signed 16 bit modulus (call _moduint)
1913 _moduint.c - unsigned 16 bit modulus
1915 _mulslong.c - signed 32 bit multiplication (calls _mululong)
1917 _mululong.c - unsigned32 bit multiplication
1919 _divslong.c - signed 32 division (calls _divulong)
1921 _divulong.c - unsigned 32 division
1923 _modslong.c - signed 32 bit modulus (calls _modulong)
1925 _modulong.c - unsigned 32 bit modulus
1928 Since they are compiled as <I>non-reentrant</I>, interrupt service
1929 routines should not do any of the above operations. If this is unavoidable
1930 then the above routines will need to be compiled with the <I>-stack-auto</I>
1931 option, after which the source program will have to be compiled with
1932 <I>-int-long-rent</I> option.
1936 <H2><A NAME="SECTION000415000000000000000">
1937 3.15 Floating Point Support</A>
1941 SDCC supports IEEE (single precision 4bytes) floating point numbers.The
1942 floating point support routines are derived from gcc's floatlib.c
1943 and consists of the following routines:
1945 <BR><I><pending: tabularise this></I>
1948 _fsadd.c - add floating point numbers
1950 _fssub.c - subtract floating point numbers
1952 _fsdiv.c - divide floating point numbers
1954 _fsmul.c - multiply floating point numbers
1956 _fs2uchar.c - convert floating point to unsigned char
1958 _fs2char.c - convert floating point to signed char
1960 _fs2uint.c - convert floating point to unsigned int
1962 _fs2int.c - convert floating point to signed int
1964 _fs2ulong.c - convert floating point to unsigned long
1966 _fs2long.c - convert floating point to signed long
1968 _uchar2fs.c - convert unsigned char to floating point
1970 _char2fs.c - convert char to floating point number
1972 _uint2fs.c - convert unsigned int to floating point
1974 _int2fs.c - convert int to floating point numbers
1976 _ulong2fs.c - convert unsigned long to floating point number
1978 _long2fs.c - convert long to floating point number
1981 Note if all these routines are used simultaneously the data space
1982 might overflow. For serious floating point usage it is strongly recommended
1983 that the large model be used.
1987 <H2><A NAME="SECTION000416000000000000000">
1988 3.16 MCS51 Memory Models</A>
1992 SDCC allows two memory models for MCS51 code, small and large. Modules
1993 compiled with different memory models should <I>never</I> be combined
1994 together or the results would be unpredictable. The library routines
1995 supplied with the compiler are compiled as both small and large. The
1996 compiled library modules are contained in seperate directories as
1997 small and large so that you can link to either set.
2000 When the large model is used all variables declared without a storage
2001 class will be allocated into the external ram, this includes all parameters
2002 and local variables (for non-reentrant functions). When the small
2003 model is used variables without storage class are allocated in the
2007 Judicious usage of the processor specific storage classes and the
2008 'reentrant' function type will yield much more efficient code, than
2009 using the large model. Several optimizations are disabled when the
2010 program is compiled using the large model, it is therefore strongly
2011 recommdended that the small model be used unless absolutely required.
2015 <H2><A NAME="SECTION000417000000000000000">
2016 3.17 DS390 Memory Models</A>
2020 The only model supported is Flat 24. This generates code for the 24
2021 bit contiguous addressing mode of the Dallas DS80C390 part. In this
2022 mode, up to four meg of external RAM or code space can be directly
2023 addressed. See the data sheets at www.dalsemi.com for further information
2027 In older versions of the compiler, this option was used with the MCS51
2028 code generator (<I>-mmcs51</I>). Now, however, the '390 has it's own
2029 code generator, selected by the <I>-mds390</I> switch.
2032 Note that the compiler does not generate any code to place the processor
2033 into 24 bitmode (although <I>tinibios</I> in the ds390 libraries will
2034 do that for you). If you don't use <I>tinibios</I>, the boot loader
2035 or similar code must ensure that the processor is in 24 bit contiguous
2036 addressing mode before calling the SDCC startup code.
2039 Like the <I>-model-large</I> option, variables will by default be
2040 placed into the XDATA segment.
2043 Segments may be placed anywhere in the 4 meg address space using the
2044 usual -*-loc options. Note that if any segments are located above
2045 64K, the -r flag must be passed to the linker to generate the proper
2046 segment relocations, and the Intel HEX output format must be used.
2047 The -r flag can be passed to the linker by using the option <I>-Wl-r</I>
2048 on the sdcc command line. However, currently the linker can not handle
2049 code segments > 64k.
2053 <H2><A NAME="SECTION000418000000000000000">
2054 3.18 Defines Created by the Compiler</A>
2058 The compiler creates the following #defines.
2063 <LI>SDCC - this Symbol is always defined.
2065 <LI>SDCC_mcs51 or SDCC_ds390 or SDCC_z80, etc - depending on the model
2066 used (e.g.: -mds390)
2068 <LI>__mcs51 or __ds390 or __z80, etc - depending on the model used
2071 <LI>SDCC_STACK_AUTO - this symbol is defined when <I>-stack-auto</I>
2074 <LI>SDCC_MODEL_SMALL - when <I>-model-small</I> is used.
2076 <LI>SDCC_MODEL_LARGE - when <I>-model-large</I> is used.
2078 <LI>SDCC_USE_XSTACK - when <I>-xstack</I> option is used.
2080 <LI>SDCC_STACK_TENBIT - when <I>-mds390</I> is used
2082 <LI>SDCC_MODEL_FLAT24 - when <I>-mds390</I> is used
2088 <H1><A NAME="SECTION00050000000000000000">
2089 4 SDCC Technical Data</A>
2094 <H2><A NAME="SECTION00051000000000000000">
2095 4.1 Optimizations</A>
2099 SDCC performs a host of standard optimizations in addition to some
2100 MCU specific optimizations.
2104 <H3><A NAME="SECTION00051100000000000000">
2105 4.1.1 Sub-expression Elimination</A>
2109 The compiler does local and global common subexpression elimination,
2112 <BR><TT>i = x + y + 1; </TT>
2113 <BR><TT>j = x + y;</TT>
2116 will be translated to
2118 <BR><TT>iTemp = x + y </TT>
2119 <BR><TT>i = iTemp + 1 </TT>
2120 <BR><TT>j = iTemp</TT>
2123 Some subexpressions are not as obvious as the above example, e.g.:
2125 <BR><TT>a->b[i].c = 10; </TT>
2126 <BR><TT>a->b[i].d = 11;</TT>
2129 In this case the address arithmetic a->b[i] will be computed only
2130 once; the equivalent code in C would be.
2132 <BR><TT>iTemp = a->b[i]; </TT>
2133 <BR><TT>iTemp.c = 10; </TT>
2134 <BR><TT>iTemp.d = 11;</TT>
2137 The compiler will try to keep these temporary variables in registers.
2141 <H3><A NAME="SECTION00051200000000000000">
2142 4.1.2 Dead-Code Elimination</A>
2146 <TT>int global; </TT>
2147 <BR><TT>void f () { </TT>
2148 <BR><TT> int i; </TT>
2149 <BR><TT> i = 1; /* dead store */ </TT>
2150 <BR><TT> global = 1; /* dead store */ </TT>
2151 <BR><TT> global = 2; </TT>
2152 <BR><TT> return; </TT>
2153 <BR><TT> global = 3; /* unreachable */ </TT>
2159 <BR><TT>int global; void f () </TT>
2160 <BR><TT>{</TT>
2161 <BR><TT> global = 2; </TT>
2162 <BR><TT> return; </TT>
2167 <H3><A NAME="SECTION00051300000000000000">
2168 4.1.3 Copy-Propagation</A>
2172 <TT>int f() { </TT>
2173 <BR><TT> int i, j; </TT>
2174 <BR><TT> i = 10; </TT>
2175 <BR><TT> j = i; </TT>
2176 <BR><TT> return j; </TT>
2182 <BR><TT>int f() { </TT>
2183 <BR><TT> int i,j; </TT>
2184 <BR><TT> i = 10; </TT>
2185 <BR><TT> j = 10; </TT>
2186 <BR><TT> return 10; </TT>
2187 <BR><TT>}</TT>
2190 Note: the dead stores created by this copy propagation will be eliminated
2191 by dead-code elimination.
2195 <H3><A NAME="SECTION00051400000000000000">
2196 4.1.4 Loop Optimizations</A>
2200 Two types of loop optimizations are done by SDCC loop invariant lifting
2201 and strength reduction of loop induction variables. In addition to
2202 the strength reduction the optimizer marks the induction variables
2203 and the register allocator tries to keep the induction variables in
2204 registers for the duration of the loop. Because of this preference
2205 of the register allocator, loop induction optimization causes an increase
2206 in register pressure, which may cause unwanted spilling of other temporary
2207 variables into the stack / data space. The compiler will generate
2208 a warning message when it is forced to allocate extra space either
2209 on the stack or data space. If this extra space allocation is undesirable
2210 then induction optimization can be eliminated either for the entire
2211 source file (with -noinduction option) or for a given function only
2212 using #pragma NOINDUCTION.
2217 <BR><TT>for (i = 0 ; i < 100 ; i ++) </TT>
2218 <BR> <TT> f += k + l;</TT>
2223 <BR><TT>itemp = k + l; </TT>
2224 <BR><TT>for (i = 0; i < 100; i++) </TT>
2225 <BR><TT> f += itemp;</TT>
2228 As mentioned previously some loop invariants are not as apparent,
2229 all static address computations are also moved out of the loop.
2232 Strength Reduction, this optimization substitutes an expression by
2233 a cheaper expression:
2235 <BR><TT>for (i=0;i < 100; i++)</TT>
2236 <BR><TT> ar[i*5] = i*3;</TT>
2241 <BR><TT>itemp1 = 0; </TT>
2242 <BR><TT>itemp2 = 0; </TT>
2243 <BR><TT>for (i=0;i< 100;i++) { </TT>
2244 <BR> <TT> ar[itemp1] = itemp2; </TT>
2245 <BR> <TT> itemp1 += 5; </TT>
2246 <BR> <TT> itemp2 += 3; </TT>
2250 The more expensive multiplication is changed to a less expensive addition.
2254 <H3><A NAME="SECTION00051500000000000000">
2255 4.1.5 Loop Reversing</A>
2259 This optimization is done to reduce the overhead of checking loop
2260 boundaries for every iteration. Some simple loops can be reversed
2261 and implemented using a ``decrement and jump if not zero'' instruction.
2262 SDCC checks for the following criterion to determine if a loop is
2263 reversible (note: more sophisticated compilers use data-dependency
2264 analysis to make this determination, SDCC uses a more simple minded
2270 <LI>The 'for' loop is of the form
2272 <BR><TT>for (<symbol> = <expression> ; <sym> [< | <=] <expression>
2273 ; [<sym>++ | <sym> += 1])</TT>
2274 <BR><TT> <for body></TT>
2276 <LI>The <for body> does not contain ``continue'' or 'break''.
2278 <LI>All goto's are contained within the loop.
2280 <LI>No function calls within the loop.
2282 <LI>The loop control variable <sym> is not assigned any value within the
2285 <LI>The loop control variable does NOT participate in any arithmetic operation
2288 <LI>There are NO switch statements in the loop.
2291 Note djnz instruction can be used for 8-bit values <I>only</I>, therefore
2292 it is advantageous to declare loop control symbols as <I>char</I>.
2293 Ofcourse this may not be possible on all situations.
2297 <H3><A NAME="SECTION00051600000000000000">
2298 4.1.6 Algebraic Simplifications</A>
2302 SDCC does numerous algebraic simplifications, the following is a small
2303 sub-set of these optimizations.
2305 <BR><TT>i = j + 0 ; /* changed to */ i = j; </TT>
2306 <BR><TT>i /= 2; /* changed to */ i >>= 1; </TT>
2307 <BR><TT>i = j - j ; /* changed to */ i = 0; </TT>
2308 <BR><TT>i = j / 1 ; /* changed to */ i = j;</TT>
2311 Note the subexpressions given above are generally introduced by macro
2312 expansions or as a result of copy/constant propagation.
2316 <H3><A NAME="SECTION00051700000000000000">
2317 4.1.7 'switch' Statements</A>
2321 SDCC changes switch statements to jump tables when the following conditions
2327 <LI>The case labels are in numerical sequence, the labels need not be
2328 in order, and the starting number need not be one or zero.
2331 <TT>switch(i) { switch (i)
2333 <BR><TT>case 4:... case 1: ... </TT>
2334 <BR><TT>case 5:... case 2: ... </TT>
2335 <BR><TT>case 3:... case 3: ... </TT>
2336 <BR><TT>case 6:... case 4: ... </TT>
2337 <BR><TT>} }</TT>
2340 Both the above switch statements will be implemented using a jump-table.
2345 <LI>The number of case labels is at least three, since it takes two conditional
2346 statements to handle the boundary conditions.
2348 <LI>The number of case labels is less than 84, since each label takes
2349 3 bytes and a jump-table can be utmost 256 bytes long.
2352 Switch statements which have gaps in the numeric sequence or those
2353 that have more that 84 case labels can be split into more than one
2354 switch statement for efficient code generation, e.g.:
2356 <BR><TT>switch (i) { </TT>
2357 <BR><TT>case 1: ... </TT>
2358 <BR><TT>case 2: ... </TT>
2359 <BR><TT>case 3: ... </TT>
2360 <BR><TT>case 4: ... </TT>
2361 <BR><TT>case 9: ... </TT>
2362 <BR><TT>case 10: ... </TT>
2363 <BR><TT>case 11: ... </TT>
2364 <BR><TT>case 12: ... </TT>
2368 If the above switch statement is broken down into two switch statements
2370 <BR><TT>switch (i) { </TT>
2371 <BR><TT>case 1: ... </TT>
2372 <BR><TT>case 2: ... </TT>
2373 <BR><TT>case 3: ... </TT>
2374 <BR><TT>case 4: ... </TT>
2375 <BR><TT>}</TT>
2380 <BR><TT>switch (i) { </TT>
2381 <BR><TT>case 9: ... </TT>
2382 <BR><TT>case 10: ... </TT>
2383 <BR><TT>case 11: ... </TT>
2384 <BR><TT>case 12: ... </TT>
2385 <BR><TT>}</TT>
2388 then both the switch statements will be implemented using jump-tables
2389 whereas the unmodified switch statement will not be.
2393 <H3><A NAME="SECTION00051800000000000000">
2394 4.1.8 Bit-shifting Operations.</A>
2398 Bit shifting is one of the most frequently used operation in embedded
2399 programming. SDCC tries to implement bit-shift operations in the most
2400 efficient way possible, e.g.:
2410 generates the following code:
2422 In general SDCC will never setup a loop if the shift count is known.
2425 <BR><TT>unsigned int i; </TT>
2426 <BR><TT>... </TT>
2427 <BR><TT>i >>= 9; </TT>
2433 <BR><TT>mov a,(_i + 1) </TT>
2434 <BR><TT>mov (_i + 1),#0x00 </TT>
2435 <BR><TT>clr c </TT>
2436 <BR><TT>rrc a </TT>
2437 <BR><TT>mov _i,a</TT>
2440 Note that SDCC stores numbers in little-endian format (i.e. lowest
2445 <H3><A NAME="SECTION00051900000000000000">
2446 4.1.9 Bit-rotation</A>
2450 A special case of the bit-shift operation is bit rotation, SDCC recognizes
2451 the following expression to be a left bit-rotation:
2453 <BR><TT>unsigned char i; </TT>
2454 <BR><TT>... </TT>
2455 <BR><TT>i = ((i << 1) | (i >>
2460 will generate the following code:
2462 <BR><TT>mov a,_i </TT>
2463 <BR><TT>rl a </TT>
2464 <BR><TT>mov _i,a</TT>
2467 SDCC uses pattern matching on the parse tree to determine this operation.Variations
2468 of this case will also be recognized as bit-rotation, i.e.:
2470 <BR><TT>i = ((i >> 7) | (i <<
2471 1)); /* left-bit rotation */</TT>
2475 <H3><A NAME="SECTION000511000000000000000">
2476 4.1.10 Highest Order Bit</A>
2480 It is frequently required to obtain the highest order bit of an integral
2481 type (long, int, short or char types). SDCC recognizes the following
2482 expression to yield the highest order bit and generates optimized
2485 <BR> <TT>unsigned int gint; </TT>
2487 <BR><TT>foo () { </TT>
2488 <BR><TT>unsigned char hob; </TT>
2489 <BR><TT> ... </TT>
2490 <BR><TT> hob = (gint >> 15) & 1; </TT>
2491 <BR><TT> .. </TT>
2495 will generate the following code:
2497 <BR><TT> 61
2498 ; hob.c 7 </TT>
2499 <BR><TT> 000A E5*01 62
2500 mov a,(_gint + 1) </TT>
2501 <BR><TT> 000C 33 63
2502 rlc a </TT>
2503 <BR><TT> 000D E4 64
2504 clr a </TT>
2505 <BR><TT> 000E 13 65
2506 rrc a </TT>
2507 <BR><TT> 000F F5*02 66
2508 mov _foo_hob_1_1,a</TT>
2511 Variations of this case however will <I>not</I> be recognized. It
2512 is a standard C expression, so I heartily recommend this be the only
2513 way to get the highest order bit, (it is portable). Of course it will
2514 be recognized even if it is embedded in other expressions, e.g.:
2516 <BR><TT>xyz = gint + ((gint >> 15) & 1);</TT>
2519 will still be recognized.
2523 <H3><A NAME="SECTION000511100000000000000">
2524 4.1.11 Peep-hole Optimizer</A>
2528 The compiler uses a rule based, pattern matching and re-writing mechanism
2529 for peep-hole optimization. It is inspired by <I>copt</I> a peep-hole
2530 optimizer by Christopher W. Fraser (cwfraser@microsoft.com). A default
2531 set of rules are compiled into the compiler, additional rules may
2532 be added with the <I>-peep-file <filename></I> option. The rule language
2533 is best illustrated with examples.
2535 <BR><TT>replace { </TT>
2536 <BR><TT> mov %1,a </TT>
2537 <BR><TT> mov a,%1</TT>
2538 <BR><TT>} by {</TT>
2539 <BR><TT> mov %1,a</TT>
2543 The above rule will change the following assembly sequence:
2545 <BR><TT> mov r1,a </TT>
2546 <BR><TT> mov a,r1</TT>
2551 <BR><TT>mov r1,a</TT>
2554 Note: All occurrences of a <I>%n</I> (pattern variable) must denote
2555 the same string. With the above rule, the assembly sequence:
2557 <BR><TT> mov r1,a </TT>
2558 <BR><TT> mov a,r2</TT>
2561 will remain unmodified.
2564 Other special case optimizations may be added by the user (via <I>-peep-file
2565 option</I>). E.g. some variants of the 8051 MCU allow only <TT>ajmp</TT>
2566 and <TT>acall</TT>. The following two rules will change all <TT>ljmp</TT>
2567 and <TT>lcall</TT> to <TT>ajmp</TT> and <TT>acall</TT>
2569 <BR><TT>replace { lcall %1 } by { acall %1 } </TT>
2570 <BR><TT>replace { ljmp %1 } by { ajmp %1 }</TT>
2573 The <I>inline-assembler code</I> is also passed through the peep hole
2574 optimizer, thus the peephole optimizer can also be used as an assembly
2575 level macro expander. The rules themselves are MCU dependent whereas
2576 the rule language infra-structure is MCU independent. Peephole optimization
2577 rules for other MCU can be easily programmed using the rule language.
2580 The syntax for a rule is as follows:
2582 <BR><TT>rule := replace [ restart ] '{' <assembly sequence> '\n'
2584 <BR><TT> '}' by '{' '\n'
2586 <BR><TT> <assembly
2587 sequence> '\n' </TT>
2588 <BR><TT> '}' [if <functionName>
2589 ] '\n' </TT>
2591 <BR><assembly sequence> := assembly instruction (each instruction including
2592 labels must be on a separate line).
2595 The optimizer will apply to the rules one by one from the top in the
2596 sequence of their appearance, it will terminate when all rules are
2597 exhausted. If the 'restart' option is specified, then the optimizer
2598 will start matching the rules again from the top, this option for
2599 a rule is expensive (performance), it is intended to be used in situations
2600 where a transformation will trigger the same rule again. A good example
2601 of this the following rule:
2605 <BR> pop %1
2606 <BR> push %1 } by {
2607 <BR> ; nop
2611 Note that the replace pattern cannot be a blank, but can be a comment
2612 line. Without the 'restart' option only the inner most 'pop' 'push'
2613 pair would be eliminated, i.e.:
2615 <BR><TT> pop ar1 </TT>
2616 <BR><TT> pop ar2 </TT>
2617 <BR><TT> push ar2 </TT>
2618 <BR><TT> push ar1</TT>
2623 <BR><TT>pop ar1 </TT>
2624 <BR><TT>; nop </TT>
2625 <BR><TT>push ar1</TT>
2627 <BR><I>with</I> the restart option the rule will be applied again to the
2628 resulting code and then all the pop-push pairs will be eliminated
2631 <BR><TT>; nop </TT>
2635 A conditional function can be attached to a rule. Attaching rules
2636 are somewhat more involved, let me illustrate this with an example.
2638 <BR><TT>replace { </TT>
2639 <BR><TT> ljmp %5 </TT>
2640 <BR><TT>%2:} by { </TT>
2641 <BR><TT> sjmp %5 </TT>
2642 <BR><TT>%2:} if labelInRange</TT>
2645 The optimizer does a look-up of a function name table defined in function
2646 <I>callFuncByName</I> in the source file SDCCpeeph.c, with the name
2647 <I>labelInRange</I>. If it finds a corresponding entry the function
2648 is called. Note there can be no parameters specified for these functions,
2649 in this case the use of <I>%5</I> is crucial, since the function
2650 <I>labelInRange</I> expects to find the label in that particular variable
2651 (the hash table containing the variable bindings is passed as a parameter).
2652 If you want to code more such functions, take a close look at the
2653 function labelInRange and the calling mechanism in source file SDCCpeeph.c.
2654 I know this whole thing is a little kludgey, but maybe some day we
2655 will have some better means. If you are looking at this file, you
2656 will also see the default rules that are compiled into the compiler,
2657 you can add your own rules in the default set there if you get tired
2658 of specifying the -peep-file option.
2660 <BR><I><pending: this is as far as I got></I>
2664 <H2><A NAME="SECTION00052000000000000000">
2669 SDCC supports the following #pragma directives. This directives are
2670 applicable only at a function level.
2675 <LI>SAVE - this will save all the current options.
2677 <LI>RESTORE - will restore the saved options from the last save. Note
2678 that SAVES & RESTOREs cannot be nested. SDCC uses the same buffer
2679 to save the options each time a SAVE is called.
2681 <LI>NOGCSE - will stop global subexpression elimination.
2683 <LI>NOINDUCTION - will stop loop induction optimizations.
2685 <LI>NOJTBOUND - will not generate code for boundary value checking, when
2686 switch statements are turned into jump-tables.
2688 <LI>NOOVERLAY - the compiler will not overlay the parameters and local
2689 variables of a function.
2691 <LI>NOLOOPREVERSE - Will not do loop reversal optimization
2693 <LI>EXCLUDE NONE | {acc[,b[,dpl[,dph]]] - The exclude pragma
2694 disables generation of pair of push/pop instruction in ISR function
2695 (using interrupt keyword). The directive should be placed immediately
2696 before the ISR function definition and it affects ALL ISR functions
2697 following it. To enable the normal register saving for ISR functions
2698 use #pragma EXCLUDE none.
2700 <LI>CALLEE-SAVES function1[,function2[,function3...]] - The compiler
2701 by default uses a caller saves convention for register saving across
2702 function calls, however this can cause unneccessary register pushing
2703 & popping when calling small functions from larger functions. This
2704 option can be used to switch the register saving convention for the
2705 function names specified. The compiler will not save registers when
2706 calling these functions, extra code will be generated at the entry
2707 & exit for these functions to save & restore the registers used
2708 by these functions, this can SUBSTANTIALLY reduce code & improve
2709 run time performance of the generated code. In future the compiler
2710 (with interprocedural analysis) will be able to determine the appropriate
2711 scheme to use for each function call. If -callee-saves command line
2712 option is used, the function names specified in #pragma CALLEE-SAVES
2713 is appended to the list of functions specified inthe command line.
2716 The pragma's are intended to be used to turn-off certain optimizations
2717 which might cause the compiler to generate extra stack / data space
2718 to store compiler generated temporary variables. This usually happens
2719 in large functions. Pragma directives should be used as shown in the
2720 following example, they are used to control options & optimizations
2721 for a given function; pragmas should be placed before and/or after
2722 a function, placing pragma's inside a function body could have unpredictable
2729 #pragma SAVE /* save the current settings */
2730 <BR>#pragma NOGCSE /* turnoff global subexpression elimination */
2732 <BR>#pragma NOINDUCTION /* turn off induction optimizations */
2736 <BR> ...
2737 <BR> /* large code */
2738 <BR> ...
2740 <BR>#pragma RESTORE /* turn the optimizations back on */
2743 The compiler will generate a warning message when extra space is allocated.
2744 It is strongly recommended that the SAVE and RESTORE pragma's be used
2745 when changing options for a function.
2749 <H2><A NAME="SECTION00053000000000000000">
2750 4.3 Library Routines</A>
2754 The following library routines are provided for your convenience.
2757 stdio.h - Contains the following functions printf & sprintf these
2758 routines are developed by Martijn van Balen <balen@natlab.research.philips.com>.
2761 %[flags][width][b|B|l|L]type
2764 flags: - left justify output in
2765 specified field width
2766 <BR> + prefix output with
2767 +/- sign if output is signed type
2768 <BR> space prefix output with a
2769 blank if it's a signed positive value
2770 <BR> width: specifies minimum number
2771 of characters outputted for numbers
2772 <BR> or strings.
2773 <BR> - For numbers,
2774 spaces are added on the left when needed.
2775 <BR> If width starts
2776 with a zero character, zeroes and used
2777 <BR> instead of
2779 <BR> - For strings,
2780 spaces are are added on the left or right (when
2781 <BR> flag '-' is
2783 <BR>
2784 <BR> b/B: byte argument (used
2786 <BR> l/L: long argument (used
2788 <BR> type: d decimal number
2789 <BR> u unsigned decimal
2791 <BR> o unsigned octal number
2793 <BR> x unsigned hexadecimal
2795 <BR> X unsigned hexadecimal
2797 <BR> c character
2798 <BR> s string (generic pointer)
2800 <BR> p generic pointer (I:data/idata,
2801 C:code, X:xdata, P:paged)
2802 <BR> f float (still to be
2806 Also contains a very simple version of printf (printf_small). This
2807 simplified version of printf supports only the following formats.
2810 format output type argument-type
2811 <BR>%d decimal short/int
2812 <BR>%ld decimal long
2813 <BR>%hd decimal char
2814 <BR>%x hexadecimal short/int
2815 <BR>%lx hexadecimal long
2816 <BR>%hx hexadecimal char
2817 <BR>%o octal short/int
2818 <BR>%lo octal long
2819 <BR>%ho octal char
2820 <BR>%c character char
2821 <BR>%s character _generic pointer
2824 The routine is very stack intesive, -stack-after-data parameter should
2825 be used when using this routine, the routine also takes about 1K of
2826 code space. It also expects an external function named putchar(char)
2827 to be present (this can be changed). When using the %s format the
2828 string / pointer should be cast to a generic pointer. eg.
2831 printf_small(``my str %s, my int %d\n'',(char
2832 _generic *)mystr,myint);
2837 <LI>stdarg.h - contains definition for the following macros to be used
2838 for variable parameter list, note that a function can have a variable
2839 parameter list if and only if it is 'reentrant'
2842 va_list, va_start, va_arg, va_end.
2846 <LI>setjmp.h - contains defintion for ANSI setjmp & longjmp routines.
2847 Note in this case setjmp & longjmp can be used between functions
2848 executing within the same register bank, if long jmp is executed from
2849 a function that is using a different register bank from the function
2850 issuing the setjmp function, the results may be unpredictable. The
2851 jump buffer requires 3 bytes of data (the stack pointer & a 16 byte
2852 return address), and can be placed in any address space.
2854 <LI>stdlib.h - contains the following functions.
2861 <LI>string.h - contains the following functions.
2864 strcpy, strncpy, strcat, strncat, strcmp, strncmp, strchr, strrchr,
2865 strspn, strcspn, strpbrk, strstr, strlen, strtok, memcpy, memcmp,
2870 <LI>ctype.h - contains the following routines.
2873 iscntrl, isdigit, isgraph, islower, isupper, isprint, ispunct, isspace,
2874 isxdigit, isalnum, isalpha.
2878 <LI>malloc.h - The malloc routines are developed by Dmitry S. Obukhov
2879 (dso@usa.net). These routines will allocate memory from the external
2880 ram. Here is a description on how to use them (as described by the
2885 <BR> // #define DYNAMIC_MEMORY_SIZE 0x2000
2886 <BR> // .....
2887 <BR> // unsigned char xdata dynamic_memory_pool[DYNAMIC_MEMORY_SIZE];
2889 <BR> // unsigned char xdata * current_buffer;
2890 <BR> // .....
2891 <BR> // void main(void)
2892 <BR> // {
2893 <BR> // ...
2894 <BR> // init_dynamic_memory(dynamic_memory_pool,DYNAMIC_MEMORY_SIZE);
2896 <BR> // //Now it's possible to use malloc.
2897 <BR> // ...
2898 <BR> // current_buffer = malloc(0x100);
2899 <BR> //
2903 <LI>serial.h - Serial IO routines are also developed by Dmitry S. Obukhov
2904 (dso@usa.net). These routines are interrupt driven with a 256 byte
2905 circular buffer, they also expect external ram to be present. Please
2906 see documentation in file SDCCDIR/sdcc51lib/serial.c. Note the header
2907 file ``serial.h'' MUST be included in the file containing the
2910 <LI>ser.h - Alternate serial routine provided by Wolfgang Esslinger <wolfgang@WiredMinds.com>
2911 these routines are more compact and faster. Please see documentation
2912 in file SDCCDIR/sdcc51lib/ser.c
2914 <LI>ser_ir.h - Another alternate set of serial routines provided by Josef
2915 Wolf <jw@raven.inka.de>, these routines do not use the external ram.
2917 <LI>reg51.h - contains register definitions for a standard 8051
2919 <LI>float.h - contains min, max and other floating point related stuff.
2922 All library routines are compiled as -model-small, they are all non-reentrant,
2923 if you plan to use the large model or want to make these routines
2924 reentrant, then they will have to be recompiled with the appropriate
2928 Have not had time to do the more involved routines like printf, will
2929 get to them shortly.
2933 <H2><A NAME="SECTION00054000000000000000">
2934 4.4 Interfacing with Assembly Routines</A>
2939 <H2><A NAME="SECTION00055000000000000000">
2940 4.5 Global Registers used for Parameter Passing</A>
2944 By default the compiler uses the global registers ``DPL,DPH,B,ACC''
2945 to pass the first parameter to a routine, the second parameter onwards
2946 is either allocated on the stack (for reentrant routines or -stack-auto
2947 is used) or in the internal / external ram (depending on the memory
2952 <H3><A NAME="SECTION00055100000000000000">
2953 4.5.1 Assembler Routine(non-reentrant)</A>
2957 In the following example the function cfunc calls an assembler routine
2958 asm_func, which takes two parameters.
2961 extern int asm_func(unsigned char, unsigned char);
2966 int c_func (unsigned char i, unsigned char j)
2968 <BR> return asm_func(i,j);
2973 <BR> return c_func(10,9);
2977 The corresponding assembler function is:-
2980 .globl _asm_func_PARM_2
2981 <BR> .globl _asm_func
2982 <BR> .area OSEG
2984 _asm_func_PARM_2: .ds 1
2985 <BR> .area CSEG
2988 <BR> mov a,dpl
2989 <BR> add a,_asm_func_PARM_2
2990 <BR> mov dpl,a
2991 <BR> mov dpl,#0x00
2992 <BR> ret
2995 Note here that the return values are placed in 'dpl' - One byte return
2996 value, 'dpl' LSB & 'dph' MSB for two byte values. 'dpl', 'dph' and
2997 'b' for three byte values (generic pointers) and 'dpl','dph','b' &
2998 'acc' for four byte values.
3001 The parameter naming convention is _<function_name>_PARM_<n>,
3002 where n is the parameter number starting from 1, and counting from
3003 the left. The first parameter is passed in ``dpl'' for One bye
3004 parameter, ``dptr'' if two bytes, ``b,dptr'' for three bytes
3005 and ``acc,b,dptr'' for four bytes, the varaible name for the second
3006 parameter will be _<function_name>_PARM_2.
3009 Assemble the assembler routine with the following command.
3012 asx8051 -losg asmfunc.asm
3015 Then compile and link the assembler routine to the C source file with
3016 the following command,
3019 sdcc cfunc.c asmfunc.rel
3023 <H3><A NAME="SECTION00055200000000000000">
3024 4.5.2 Assembler Routine(reentrant)</A>
3028 In this case the second parameter onwards will be passed on the stack,
3029 the parameters are pushed from right to left i.e. after the call the
3030 left most parameter will be on the top of the stack. Here is an example.
3033 extern int asm_func(unsigned char, unsigned char);
3039 int c_func (unsigned char i, unsigned char j) reentrant
3041 <BR> return asm_func(i,j);
3046 <BR> return c_func(10,9);
3050 The corresponding assembler routine is.
3053 .globl _asm_func
3056 <BR> push _bp
3057 <BR> mov _bp,sp
3058 <BR> mov r2,dpl
3059 <BR> mov a,_bp
3060 <BR> clr c
3061 <BR> add a,#0xfd
3062 <BR> mov r0,a
3063 <BR> add a,#0xfc
3064 <BR> mov r1,a
3065 <BR> mov a,@r0
3066 <BR> add a,r2
3067 <BR> mov dpl,a
3068 <BR> mov dph,#0x00
3069 <BR> mov sp,_bp
3070 <BR> pop _bp
3071 <BR> ret
3074 The compiling and linking procedure remains the same, however note
3075 the extra entry & exit linkage required for the assembler code, _bp
3076 is the stack frame pointer and is used to compute the offset into
3077 the stack for parameters and local variables.
3081 <H2><A NAME="SECTION00056000000000000000">
3082 4.6 External Stack</A>
3086 The external stack is located at the start of the external ram segment,
3087 and is 256 bytes in size. When -xstack option is used to compile
3088 the program, the parameters and local variables of all reentrant functions
3089 are allocated in this area. This option is provided for programs with
3090 large stack space requirements. When used with the -stack-auto option,
3091 all parameters and local variables are allocated on the external stack
3092 (note support libraries will need to be recompiled with the same options).
3095 The compiler outputs the higher order address byte of the external
3096 ram segment into PORT P2, therefore when using the External Stack
3097 option, this port MAY NOT be used by the application program.
3101 <H2><A NAME="SECTION00057000000000000000">
3102 4.7 ANSI-Compliance</A>
3106 Deviations from the compliancy.
3111 <LI>functions are not always reentrant.
3113 <LI>structures cannot be assigned values directly, cannot be passed as
3114 function parameters or assigned to each other and cannot be a return
3115 value from a function.
3131 s1 = s2 ; /* is invalid in SDCC although allowed in ANSI */
3136 struct s foo1 (struct s parms) /* is invalid in SDCC although allowed
3143 return rets;/* is invalid in SDCC although allowed in ANSI */
3150 <LI>'long long' (64 bit integers) not supported.
3152 <LI>'double' precision floating point not supported.
3154 <LI>integral promotions are suppressed. What does this mean ? The compiler
3155 will not implicitly promote an integer expression to a higher order
3156 integer, exception is an assignment or parameter passing.
3158 <LI>No support for setjmp and longjmp (for now).
3160 <LI>Old K&R style function declarations are NOT allowed.
3163 foo(i,j) /* this old style of function declarations */
3165 int i,j; /* are valid in ANSI .. not valid in SDCC */
3173 <LI>functions declared as pointers must be dereferenced during the call.
3182 <BR> /* has to be called like this */
3183 <BR> (*foo)();/* ansi standard allows calls to be made like 'foo()'
3188 <H2><A NAME="SECTION00058000000000000000">
3189 4.8 Cyclomatic Complexity</A>
3193 Cyclomatic complexity of a function is defined as the number of independent
3194 paths the program can take during execution of the function. This
3195 is an important number since it defines the number test cases you
3196 have to generate to validate the function. The accepted industry standard
3197 for complexity number is 10, if the cyclomatic complexity reported
3198 by SDCC exceeds 10 you should think about simplification of the function
3202 Note that the complexity level is not related to the number of lines
3203 of code in a function. Large functions can have low complexity, and
3204 small functions can have large complexity levels. SDCC uses the following
3205 formula to compute the complexity.
3208 complexity = (number of edges in control flow graph) -
3209 <BR> (number of nodes in control flow graph) + 2;
3212 Having said that the industry standard is 10, you should be aware
3213 that in some cases it may unavoidable to have a complexity level of
3214 less than 10. For example if you have switch statement with more than
3215 10 case labels, each case label adds one to the complexity level.
3216 The complexity level is by no means an absolute measure of the algorithmic
3217 complexity of the function, it does however provide a good starting
3218 point for which functions you might look at for further optimization.
3222 <H1><A NAME="SECTION00060000000000000000">
3227 Here are a few guide-lines that will help the compiler generate more
3228 efficient code, some of the tips are specific to this compiler others
3229 are generally good programming practice.
3234 <LI>Use the smallest data type to represent your data-value. If it is
3235 known in advance that the value is going to be less than 256 then
3236 use a 'char' instead of a 'short' or 'int'.
3238 <LI>Use unsigned when it is known in advance that the value is not going
3239 to be negative. This helps especially if you are doing division or
3242 <LI>NEVER jump into a LOOP.
3244 <LI>Declare the variables to be local whenever possible, especially loop
3245 control variables (induction).
3247 <LI>Since the compiler does not do implicit integral promotion, the programmer
3248 should do an explicit cast when integral promotion is required.
3250 <LI>Reducing the size of division, multiplication & modulus operations
3251 can reduce code size substantially. Take the following code for example.
3254 foobar(unsigned int p1, unsigned char ch)
3256 <BR> unsigned char ch1 = p1 % ch ;
3257 <BR> ....
3261 For the modulus operation the variable ch will be promoted to unsigned
3262 int first then the modulus operation will be performed (this will
3263 lead to a call to a support routine). If the code is changed to
3266 foobar(unsigned int p1, unsigned char ch)
3268 <BR> unsigned char ch1 = (unsigned char)p1 % ch ;
3269 <BR> ....
3273 It would substantially reduce the code generated (future versions
3274 of the compiler will be smart enough to detect such optimization oppurtunities).
3279 Notes on MCS51 memory layout(Trefor@magera.freeserve.co.uk)
3282 The 8051 family of micro controller have a minimum of 128 bytes of
3283 internal memory which is structured as follows
3286 - Bytes 00-1F - 32 bytes to hold up to 4 banks of the registers R7
3290 - Bytes 20-2F - 16 bytes to hold 128 bit variables and
3293 - Bytes 30-7F - 60 bytes for general purpose use.
3296 Normally the SDCC compiler will only utilise the first bank of registers,
3297 but it is possible to specify that other banks of registers should
3298 be used in interrupt routines. By default, the compiler will place
3299 the stack after the last bank of used registers, i.e. if the first
3300 2 banks of registers are used, it will position the base of the internal
3301 stack at address 16 (0X10). This implies that as the stack grows,
3302 it will use up the remaining register banks, and the 16 bytes used
3303 by the 128 bit variables, and 60 bytes for general purpose use.
3306 By default, the compiler uses the 60 general purpose bytes to hold
3307 "near data". The compiler/optimiser may also declare
3308 some Local Variables in this area to hold local data.
3311 If any of the 128 bit variables are used, or near data is being used
3312 then care needs to be taken to ensure that the stack does not grow
3313 so much that it starts to over write either your bit variables or
3314 "near data". There is no runtime checking to prevent
3315 this from happening.
3318 The amount of stack being used is affected by the use of the "internal
3319 stack" to save registers before a subroutine call is made,
3320 - -stack-auto will declare parameters and local variables on the
3321 stack - the number of nested subroutines.
3324 If you detect that the stack is over writing you data, then the following
3325 can be done. -xstack will cause an external stack to be used for
3326 saving registers and (if -stack-auto is being used) storing parameters
3327 and local variables. However this will produce more and code which
3328 will be slower to execute.
3331 -stack-loc will allow you specify the start of the stack, i.e. you
3332 could start it after any data in the general purpose area. However
3333 this may waste the memory not used by the register banks and if the
3334 size of the "near data" increases, it may creep
3335 into the bottom of the stack.
3338 -stack-after-data, similar to the -stack-loc, but it automatically
3339 places the stack after the end of the "near data".
3340 Again this could waste any spare register space.
3343 -data-loc allows you to specify the start address of the near data.
3344 This could be used to move the "near data" further
3345 away from the stack giving it more room to grow. This will only work
3346 if no bit variables are being used and the stack can grow to use the
3353 If you find that the stack is over writing your bit variables or "near
3354 data" then the approach which best utilised the internal
3355 memory is to position the "near data" after the
3356 last bank of used registers or, if you use bit variables, after the
3357 last bit variable by using the -data-loc, e.g. if two register banks
3358 are being used and no data variables, -data-loc 16, and - use the
3359 -stack-after-data option.
3362 If bit variables are being used, another method would be to try and
3363 squeeze the data area in the unused register banks if it will fit,
3364 and start the stack after the last bit variable.
3368 <H1><A NAME="SECTION00070000000000000000">
3369 6 Retargetting for other MCUs.</A>
3373 The issues for retargetting the compiler are far too numerous to be
3374 covered by this document. What follows is a brief description of each
3375 of the seven phases of the compiler and its MCU dependency.
3380 <LI>Parsing the source and building the annotated parse tree. This phase
3381 is largely MCU independent (except for the language extensions). Syntax
3382 & semantic checks are also done in this phase, along with some initial
3383 optimizations like back patching labels and the pattern matching optimizations
3384 like bit-rotation etc.
3386 <LI>The second phase involves generating an intermediate code which can
3387 be easy manipulated during the later phases. This phase is entirely
3388 MCU independent. The intermediate code generation assumes the target
3389 machine has unlimited number of registers, and designates them with
3390 the name iTemp. The compiler can be made to dump a human readable
3391 form of the code generated by using the -dumpraw option.
3393 <LI>This phase does the bulk of the standard optimizations and is also
3394 MCU independent. This phase can be broken down into several sub-phases.
3399 <LI>Break down intermediate code (iCode) into basic blocks.
3401 <LI>Do control flow & data flow analysis on the basic blocks.
3403 <LI>Do local common subexpression elimination, then global subexpression
3406 <LI>dead code elimination
3408 <LI>loop optimizations
3410 <LI>if loop optimizations caused any changes then do 'global subexpression
3411 elimination' and 'dead code elimination' again.
3415 <LI>This phase determines the live-ranges; by live range I mean those
3416 iTemp variables defined by the compiler that still survive after all
3417 the optimizations. Live range analysis is essential for register allocation,
3418 since these computation determines which of these iTemps will be assigned
3419 to registers, and for how long.
3421 <LI>Phase five is register allocation. There are two parts to this process.
3426 <LI>The first part I call 'register packing' (for lack of a better term).
3427 In this case several MCU specific expression folding is done to reduce
3430 <LI>The second part is more MCU independent and deals with allocating
3431 registers to the remaining live ranges. A lot of MCU specific code
3432 does creep into this phase because of the limited number of index
3433 registers available in the 8051.
3437 <LI>The Code generation phase is (unhappily), entirely MCU dependent and
3438 very little (if any at all) of this code can be reused for other MCU.
3439 However the scheme for allocating a homogenized assembler operand
3440 for each iCode operand may be reused.
3442 <LI>As mentioned in the optimization section the peep-hole optimizer is
3443 rule based system, which can reprogrammed for other MCUs.
3449 <H1><A NAME="SECTION00080000000000000000">
3450 7 SDCDB - Source Level Debugger</A>
3454 SDCC is distributed with a source level debugger. The debugger uses
3455 a command line interface, the command repertoire of the debugger has
3456 been kept as close to gdb (the GNU debugger) as possible. The configuration
3457 and build process is part of the standard compiler installation, which
3458 also builds and installs the debugger in the target directory specified
3459 during configuration. The debugger allows you debug BOTH at the C
3460 source and at the ASM source level.
3464 <H2><A NAME="SECTION00081000000000000000">
3465 7.1 Compiling for Debugging</A>
3469 The -debug option must be specified for all files for which debug
3470 information is to be generated. The complier generates a .cdb file
3471 for each of these files. The linker updates the .cdb file with the
3472 address information. This .cdb is used by the debugger.
3476 <H2><A NAME="SECTION00082000000000000000">
3477 7.2 How the Debugger Works</A>
3481 When the -debug option is specified the compiler generates extra
3482 symbol information some of which are put into the the assembler source
3483 and some are put into the .cdb file, the linker updates the .cdb file
3484 with the address information for the symbols. The debugger reads the
3485 symbolic information generated by the compiler & the address information
3486 generated by the linker. It uses the SIMULATOR (Daniel's S51) to execute
3487 the program, the program execution is controlled by the debugger.
3488 When a command is issued for the debugger, it translates it into appropriate
3489 commands for the simulator.
3493 <H2><A NAME="SECTION00083000000000000000">
3494 7.3 Starting the Debugger</A>
3498 The debugger can be started using the following command line. (Assume
3499 the file you are debugging has
3508 The debugger will look for the following files.
3513 <LI>foo.c - the source file.
3515 <LI>foo.cdb - the debugger symbol information file.
3517 <LI>foo.ihx - the intel hex format object file.
3523 <H2><A NAME="SECTION00084000000000000000">
3524 7.4 Command Line Options.</A>
3530 <LI>-directory=<source file directory> this option can used to specify
3531 the directory search list. The debugger will look into the directory
3532 list specified for source, cdb & ihx files. The items in the directory
3533 list must be separated by ':', e.g. if the source files can be in
3534 the directories /home/src1 and /home/src2, the -directory option
3535 should be -directory=/home/src1:/home/src2. Note there can be no
3536 spaces in the option.
3538 <LI>-cd <directory> - change to the <directory>.
3540 <LI>-fullname - used by GUI front ends.
3542 <LI>-cpu <cpu-type> - this argument is passed to the simulator please
3543 see the simulator docs for details.
3545 <LI>-X <Clock frequency > this options is passed to the simulator please
3546 see simulator docs for details.
3548 <LI>-s <serial port file> passed to simulator see simulator docs for details.
3550 <LI>-S <serial in,out> passed to simulator see simulator docs for details.
3556 <H2><A NAME="SECTION00085000000000000000">
3557 7.5 Debugger Commands.</A>
3561 As mention earlier the command interface for the debugger has been
3562 deliberately kept as close the GNU debugger gdb, as possible, this
3563 will help int integration with existing graphical user interfaces
3564 (like ddd, xxgdb or xemacs) existing for the GNU debugger.
3568 <H3><A NAME="SECTION00085100000000000000">
3569 7.5.1 break [line | file:line | function | file:function]</A>
3573 Set breakpoint at specified line or function.
3578 sdcdb>break foo.c:100
3580 sdcdb>break funcfoo
3582 sdcdb>break foo.c:funcfoo
3586 <H3><A NAME="SECTION00085200000000000000">
3587 7.5.2 clear [line | file:line | function | file:function ]</A>
3591 Clear breakpoint at specified line or function.
3596 sdcdb>clear foo.c:100
3598 sdcdb>clear funcfoo
3600 sdcdb>clear foo.c:funcfoo
3604 <H3><A NAME="SECTION00085300000000000000">
3609 Continue program being debugged, after breakpoint.
3613 <H3><A NAME="SECTION00085400000000000000">
3618 Execute till the end of the current function.
3622 <H3><A NAME="SECTION00085500000000000000">
3623 7.5.5 delete [n]</A>
3627 Delete breakpoint number 'n'. If used without any option clear ALL
3628 user defined break points.
3632 <H3><A NAME="SECTION00085600000000000000">
3633 7.5.6 info [break | stack | frame | registers ]</A>
3639 <LI>info break - list all breakpoints
3641 <LI>info stack - show the function call stack.
3643 <LI>info frame - show information about the current execution frame.
3645 <LI>info registers - show content of all registers.
3651 <H3><A NAME="SECTION00085700000000000000">
3656 Step program until it reaches a different source line.
3660 <H3><A NAME="SECTION00085800000000000000">
3665 Step program, proceeding through subroutine calls.
3669 <H3><A NAME="SECTION00085900000000000000">
3674 Start debugged program.
3678 <H3><A NAME="SECTION000851000000000000000">
3679 7.5.10 ptype variable </A>
3683 Print type information of the variable.
3687 <H3><A NAME="SECTION000851100000000000000">
3688 7.5.11 print variable</A>
3692 print value of variable.
3696 <H3><A NAME="SECTION000851200000000000000">
3697 7.5.12 file filename</A>
3701 load the given file name. Note this is an alternate method of loading
3706 <H3><A NAME="SECTION000851300000000000000">
3711 print information about current frame.
3715 <H3><A NAME="SECTION000851400000000000000">
3716 7.5.14 set srcmode</A>
3720 Toggle between C source & assembly source.
3724 <H3><A NAME="SECTION000851500000000000000">
3725 7.5.15 ! simulator command</A>
3729 Send the string following '!' to the simulator, the simulator response
3730 is displayed. Note the debugger does not interpret the command being
3731 sent to the simulator, so if a command like 'go' is sent the debugger
3732 can loose its execution context and may display incorrect values.
3736 <H3><A NAME="SECTION000851600000000000000">
3741 "Watch me now. Iam going Down. My name is Bobby Brown"
3745 <H2><A NAME="SECTION00086000000000000000">
3746 7.6 Interfacing with XEmacs.</A>
3750 Two files are (in emacs lisp) are provided for the interfacing with
3751 XEmacs, sdcdb.el and sdcdbsrc.el. These two files can be found in
3752 the $(prefix)/bin directory after the installation is complete. These
3753 files need to be loaded into XEmacs for the interface to work, this
3754 can be done at XEmacs startup time by inserting the following into
3755 your '.xemacs' file (which can be found in your HOME directory) (load-file
3756 sdcdbsrc.el) [ .xemacs is a lisp file so the () around the command
3757 is REQUIRED), the files can also be loaded dynamically while XEmacs
3758 is running, set the environment variable 'EMACSLOADPATH' to the installation
3759 bin directory [$(prefix)/bin], then enter the following command
3760 ESC-x load-file sdcdbsrc. To start the interface enter the following
3761 command ESC-x sdcdbsrc, you will prompted to enter the file name to
3765 The command line options that are passed to the simulator directly
3766 are bound to default values in the file sdcdbsrc.el the variables
3767 are listed below these values maybe changed as required.
3772 <LI>sdcdbsrc-cpu-type '51
3774 <LI>sdcdbsrc-frequency '11059200
3776 <LI>sdcdbsrc-serial nil
3779 The following is a list of key mapping for the debugger interface.
3783 <BR>;; Current Listing ::
3784 <BR>;;key binding Comment
3786 <BR>;;-- ---- ----
3789 <BR>;; n sdcdb-next-from-src SDCDB
3791 <BR>;; b sdcdb-back-from-src SDCDB
3793 <BR>;; c sdcdb-cont-from-src SDCDB
3795 <BR>;; s sdcdb-step-from-src SDCDB
3797 <BR>;; ? sdcdb-whatis-c-sexp SDCDB
3798 ptypecommand for data at
3799 <BR>;;
3801 <BR>;; x sdcdbsrc-delete SDCDB
3802 Delete all breakpoints if no arg
3803 <BR>;; given
3804 or delete arg (C-u arg x)
3805 <BR>;; m sdcdbsrc-frame SDCDB
3806 Display current frame if no arg,
3807 <BR>;; given
3808 or display frame arg
3809 <BR>;; buffer
3811 <BR>;; ! sdcdbsrc-goto-sdcdb Goto
3812 the SDCDB output buffer
3813 <BR>;; p sdcdb-print-c-sexp SDCDB
3814 print command for data at
3815 <BR>;;
3817 <BR>;; g sdcdbsrc-goto-sdcdb Goto
3818 the SDCDB output buffer
3819 <BR>;; t sdcdbsrc-mode Toggles
3820 Sdcdbsrc mode (turns it off)
3822 <BR>;; C-c C-f sdcdb-finish-from-src SDCDB
3825 <BR>;; C-x SPC sdcdb-break Set
3826 break for line with point
3827 <BR>;; ESC t sdcdbsrc-mode Toggle
3829 <BR>;; ESC m sdcdbsrc-srcmode
3835 <H1><A NAME="SECTION00090000000000000000">
3836 8 Other Processors</A>
3841 <H2><A NAME="SECTION00091000000000000000">
3842 8.1 The Z80 and gbz80 port</A>
3846 SDCC can target both the Zilog Z80 and the Nintendo Gameboy's Z80-like
3847 gbz80. The port is incomplete - long support is incomplete (mul, div
3848 and mod are unimplimented), and both float and bitfield support is
3849 missing, but apart from that the code generated is correct.
3852 As always, the code is the authoritave reference - see z80/ralloc.c
3853 and z80/gen.c. The stack frame is similar to that generated by the
3854 IAR Z80 compiler. IX is used as the base pointer, HL is used as a
3855 temporary register, and BC and DE are available for holding varibles.
3856 IY is currently unusued. Return values are stored in HL. One bad side
3857 effect of using IX as the base pointer is that a functions stack frame
3858 is limited to 127 bytes - this will be fixed in a later version.
3862 <H1><A NAME="SECTION000100000000000000000">
3867 SDCC has grown to be large project, the compiler alone (without the
3868 Assembler Package, Preprocessor) is about 40,000 lines of code (blank
3869 stripped). The open source nature of this project is a key to its
3870 continued growth and support. You gain the benefit and support of
3871 many active software developers and end users. Is SDCC perfect? No,
3872 that's why we need your help. The developers take pride in fixing
3873 reported bugs. You can help by reporting the bugs and helping other
3874 SDCC users. There are lots of ways to contribute, and we encourage
3875 you to take part in making SDCC a great software package.
3879 <H2><A NAME="SECTION000101000000000000000">
3880 9.1 Reporting Bugs</A>
3884 Send an email to the mailing list at 'user-sdcc@sdcc.sourceforge.net'
3885 or 'devel-sdcc@sdcc.sourceforge.net'. Bugs will be fixed ASAP. When
3886 reporting a bug, it is very useful to include a small test program
3887 which reproduces the problem. If you can isolate the problem by looking
3888 at the generated assembly code, this can be very helpful. Compiling
3889 your program with the -dumpall option can sometimes be useful in
3890 locating optimization problems.
3894 <H2><A NAME="SECTION000102000000000000000">
3895 9.2 Acknowledgments</A>
3899 Sandeep Dutta(sandeep.dutta@usa.net) - SDCC, the compiler, MCS51 code
3900 generator, Debugger, AVR port
3902 Alan Baldwin (baldwin@shop-pdp.kent.edu) - Initial version of ASXXXX
3905 John Hartman (jhartman@compuserve.com) - Porting ASXXX & ASLINK for
3908 Dmitry S. Obukhov (dso@usa.net) - malloc & serial i/o routines.
3910 Daniel Drotos <drdani@mazsola.iit.uni-miskolc.hu> - for his Freeware
3913 Malini Dutta(malini_dutta@hotmail.com) - my wife for her patience
3916 Unknown - for the GNU C - preprocessor.
3918 Michael Hope - The Z80 and Z80GB port, 186 development
3920 Kevin Vigor - The DS390 port.
3922 Johan Knol - DS390/TINI libs, lots of fixes and enhancements.
3924 Scott Datallo - PIC port.
3925 <BR>(Thanks to all the other volunteer developers who have helped with
3926 coding, testing, web-page creation, distribution sets, etc. You know
3930 This document initially written by Sandeep Dutta
3933 All product names mentioned herein may be trademarks of their respective
3939 <H1><A NAME="SECTION000110000000000000000">
3940 About this document ...</A>
3942 <STRONG>lSDCC Compiler User Guide</STRONG><P>
3943 This document was generated using the
3944 <A HREF="http://www-dsed.llnl.gov/files/programs/unix/latex2html/manual/"><STRONG>LaTeX</STRONG>2<tt>HTML</tt></A> translator Version 2K.1beta (1.47)
3946 Copyright © 1993, 1994, 1995, 1996,
3947 <A HREF="http://cbl.leeds.ac.uk/nikos/personal.html">Nikos Drakos</A>,
3948 Computer Based Learning Unit, University of Leeds.
3950 Copyright © 1997, 1998, 1999,
3951 <A HREF="http://www.maths.mq.edu.au/~ross/">Ross Moore</A>,
3952 Mathematics Department, Macquarie University, Sydney.
3954 The command line arguments were: <BR>
3955 <STRONG>latex2html</STRONG> <TT>-no_subdir -split 0 -show_section_numbers /tmp/lyx_tmpdir1913F54AWM/lyx_tmpbuf1913544rwj/SDCCUdoc.tex</TT>
3957 The translation was initiated by Karl Bongers on 2001-07-05
3958 <BR><HR><H4>Footnotes</H4>
3960 <DT><A NAME="foot513">...
3961 anyway</A><A NAME="foot513"
3962 HREF="SDCCUdoc.html#tex2html1"><SUP>1</SUP></A>
3963 <DD>possible exception: if a function is called ONLY from 'interrupt'
3964 functions using a particular bank, it can be declared with the same
3965 'using' attribute as the calling 'interrupt' functions. For instance,
3966 if you have several ISRs using bank one, and all of them call memcpy(),
3967 it might make sense to create a specialized version of memcpy() 'using
3968 1', since this would prevent the ISR from having to save bank zero
3969 to the stack on entry and switch to bank zero before calling the function
3973 <!--Navigation Panel-->
3974 <IMG WIDTH="81" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next_inactive"
3975 SRC="file:/usr/share/latex2html/icons/nx_grp_g.png">
3976 <IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up"
3977 SRC="file:/usr/share/latex2html/icons/up_g.png">
3978 <IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous"
3979 SRC="file:/usr/share/latex2html/icons/prev_g.png">
3981 <!--End of Navigation Panel-->
projects / fw / sdcc / blob