3 SDCC Compiler User Guide
5 Sandeep Dutta (sandeep.dutta@usa.net)
9 SDCC is a Free ware , retargettable, optimizing ANSI-C compiler. The
10 current version targets Intel 8051 based MCUs, it can be retargetted
11 for other 8 bit MCUs or PICs. The entire source code for the compiler
12 is distributed under GPL. SDCC used ASXXXX & ASLINK a Free ware, retargettable
13 assembler & linker. SDCC has extensive MCU (8051) specific language
14 extensions, which lets it utilize the underlying hardware effectively.
15 The front-end (parser) will be enhanced to handle language extensions
16 for other MCUs as and when they are targetted. In addition to the
17 MCU Specific optimizations SDCC also does a host of standard optimizations
18 like global sub expression elimination, loop optimizations (loop invariant,
19 strength reduction of induction variables and loop reversing), constant
20 folding & propagation, copy propagation, dead code elimination and
21 jumptables for 'switch' statements. For the back-end SDCC uses a global
22 register allocation scheme which should be well suited for other 8
23 bit MCUs , the peep hole optimizer uses a rule based substitution
24 mechanism which is MCU independent. Supported data-types are short
25 (8 bits, 1 byte), char (8 bits, 1 byte), int (16 bits, 2 bytes ),
26 long (32 bit, 4 bytes) & float (4 byte IEEE). The compiler also allows
27 inline assembler code to be embedded anywhere in a function. In addition
28 routines developed in assembly can also be called. SDCC also provides
29 an option to report the relative complexity of a function, these functions
30 can then be further optimized , or hand coded in assembly if need
31 be. SDCC also comes with a companion source level debugger SDCDB,
32 the debugger currently uses S51 a freeware simulator for 8051, it
33 can be easily modified to use other simulators. The latest version
34 can be downloaded from http://www.geocities.com/ResearchTriangle/Forum/1353
36 All packages used in this compiler system are opensource (freeware);
37 source code for all the sub-packages ( asxxxx assembler/linker , pre-processor
38 and gc a conservative garbage collector) are distributed with the
39 package. Documentation was created using a freeware word processor
42 This program is free software; you can redistribute it and/or modify
43 it under the terms of the GNU General Public License as published
44 by the Free Software Foundation; either version 2, or (at your option)
45 any later version. This program is distributed in the hope that it
46 will be useful, but WITHOUT ANY WARRANTY; without even the implied
47 warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
48 the GNU General Public License for more details. You should have received
49 a copy of the GNU General Public License along with this program;
50 if not, write to the Free Software Foundation, 59 Temple Place - Suite
51 330, Boston, MA 02111-1307, USA. In other words, you are welcome to
52 use, share and improve this program. You are forbidden to forbid anyone
53 else to use, share and improve what you give them. Help stamp out
56 2 Installation \label{Installation}
58 What you need before you start installation of SDCC ? A C Compiler,
59 not just any C Compiler, gcc to be exact, you can get adventurous
60 and try another compiler , I HAVEN'T tried it. GCC is free , and is
61 available for almost all major platforms, if you are using linux you
62 probably already have it, if you are using Windows 95/NT go to www.cygnus.com
63 and download CYGWIN32 you will need the full development version of
64 their tool (full.exe), follow their instructions for installation
65 (this is also free and is very easy to install), Windows 95/NT users
66 be aware that the compiler runs substantially slower on the Windows
67 platform, I am not sure why.
69 After you have installed gcc you are ready to build the compiler (sorry
70 no binary distributions yet). SDCC is native to Linux but can be ported
71 to any platform on which GCC is available . Extract the source file
72 package (.zip or .tar.gz) into some directory , which we shall refer
73 to as SDCCDIR from now on.
75 2.1 Components of SDCC\label{Components}
77 2.1.1 gc ( a conservative garbage collector)
79 SDCC relies on this component to do all the memory management, this
80 excellent package is copyrighted by Jans J Boehm(boehm@sgi.com) and
81 Alan J Demers but can be used with minimum restrictions. The GC source
82 will be extracted into the directory SDCCDIR/gc.
84 2.1.2 cpp ( C-Preprocessor)
86 The preprocessor is extracted into the directory SDCCDIR/cpp, it is
87 a modified version of the GNU preprocessor.
89 2.1.3 asxxxx & aslink ( The assembler and Linkage Editor)
91 This is retargettable assembler & linkage editor, it was developed
92 by Alan Baldwin, John Hartman created the version for 8051, and I
93 (Sandeep) have some enhancements and bug fixes for it to work properly
94 with the SDCC. This component is extracted into the directory SDCCDIR/asxxxx.
96 2.1.4 SDCC - The compiler.
98 This is the actual compiler, it uses gc and invokes the assembler and
99 linkage editor. All files with the prefix SDCC are part of the compiler
100 and is extracted into the the directory SDCCDIR.
102 2.1.5 S51 - Simulator
104 Version 2.1.8 onwards contains s51 a freeware , opensource simulator
105 developed by Daniel Drotos <drdani@mazsola.iit.uni-miskolc.hu>. The
106 executable is built as part of build process, for more information
107 visit Daniel's website at <http://mazsola.iit.uni-miskolc.hu/~drdani/embedded/s51/>.
109 2.1.6 SDCDB - Source level Debugger.
111 SDCDB is the companion source level debugger . The current version
112 of the debugger uses Daniel's Simulator S51, but can be easily changed
113 to use other simulators.
115 2.2 Installation for Version <= 2.1.7
117 After the package is extracted (Windows 95/NT users start CYGWIN shell),
118 change to the directory where you extracted the package and give the
123 This is a bash shell script, it will compile all the above mentioned
124 components and install the executables into the directory SDCCDIR/bin
125 make sure you add this directory to your PATH environment variable.
126 This script will also compile all the support routines ( library routines
127 ) using SDCC. The support routines are all developed in C and need
130 2.3 Installation for Version >= 2.1.8a
132 The distribution method from Version 2.1.8a has been changed to be
133 conforment with the ``autoconf'' utility. The source is now distributed
134 as sdcc-<version number>.tar.gz format , instead of the older .zip
135 format. The steps for installation are as follows.
137 2.3.1 Unpack the sources.
139 This is usually done by the following command ``gunzip -c sdcc-<version
140 number>.tar.gz | tar -xv -``
142 2.3.2 Change to the main source directory (usually sdcc or sdcc-<version
145 2.3.3 Issue command to configure your system
147 The configure command has several options the most commonly used option
148 is --prefix=<directory name>, where <directory name> is the final
149 location for the sdcc executables and libraries, (default location
150 is /usr/local). The installation process will create the following
151 directory structure under the <directory name> specified.
153 bin/ - binary exectables (add to PATH environment variable)
155 sdcc51inc/ - include header files
157 small/ - Object & Library files for small model library
158 large/ - Object & library files for large model library
162 './configure --prefix=/usr/local''
164 will create configure the compiler to be installed in directory /usr/local/bin.
168 After configuration step issue the command
172 This will compile the compiler
174 2.3.5 ``make install''
176 Will install the compiler and libraries in the appropriate directories.
178 2.3.6 Special Notes for Windows Users. Provided by Michael Jamet[ mjamet@computer.org]
182 How to install SDCC from source on a Windows 95 or Windows NT 4 system
186 This document describes how to install SDCC on a Win 95 or Win NT
189 These instructions probably work for Win 98 as well, but have not
192 tested on that platform.
196 There are lots of little differences between UNIX and the Win32 Cygnus
198 environment which make porting more difficult than it should be. If
200 you want the details, please contact me. Otherwise just follow these
206 1. Install the Cygnus Software
208 Go to http://sourceware.cygnus.com/cygwin. Cygnus provides a UNIX
211 environment for Win 32 systems. Download "full.exe" and install. You
213 MUST install it on your C drive. "full.exe" contains a shell AND many
215 common UNIX utilities.
219 2. Download and Extract the Latest SDCC
221 The latest version can be found at
223 www.geocities.com/ResearchTriange/Forum/1353.
225 It can be uncompressed with winzip.
229 3. Start a Cygnus Shell
231 There should be an entry in the Start Menu for Cygnus. Invoke the
234 This gives you a UNIX like environment. FROM THIS POINT ON, DIRECTORIES
236 MUST BE SPECIFIED WITH FORWARD SLASHES (/) NOT THE DOS STYLE BACK
238 SLASHES (\) BECAUSE THIS IS WHAT UNIX EXPECTS. -
240 ex. "\winnt" would be "/winnt" under the shell.
244 4. Change Directory to Where SDCC was extracted (referred to as INSTALLDIR)
248 ex. cd /sdcc218Da. If you extracted to a drive OTHER THAN C, the drive
250 must be specified as part of the path. For example, if you extracted
253 your "g drive", type the following: "cd //g/mydir". You must use "//"
255 to specify the drive.
259 5. Make Dirs Which are Automatically Made During the UNIX Installation
265 mkdir -p bin (not a typo, just "bin")
269 mkdir -p /usr/local/bin
271 mkdir -p /usr/local/share
273 mkdir -p /usr/local/share/sdcc51lib
275 mkdir -p /usr/local/share/sdcc51inc
281 (When a path from the root directory is specified WITHOUT a drive,
284 drive defaults to c. For example /michael/newuser => c:\michael\newuser)
288 6. Add Programs to /bin Expected by the Installation Process
290 - Look at your path: echo $PATH
292 One of the fields is the diretory with the CYGNUS programs.
294 ex. /CYGNUS/CYGWIN~1/H-I586/BIN
298 - cd to the directory found above. You may have to fiddle with the
300 case (upper or lower) here because the PATH is SHOWN as all upper
302 case, but is actually mixed. To help you along, you may type
304 a letter or 2 followed by the escape key. The shell will fill
306 out the remaining letters IF THEY describe a unique directory.
308 If you have problems here, cd one directory and type "ls". "ls"
310 is the equivalent of "dir/w".
314 - Copy the following:
324 7. Go back to the INSTALLDIR
332 8. Run the configure Program
336 The "./" is important because your current directory is NOT in your
339 Under DOS, your current directory was implicitly always the first
352 This process takes quite some time under Win 32.
356 10. Install the Newly Built Software
362 This will partially install the software into the /usr/local directories
364 created in step 5. What it actually doing is copying the .c, .h and
366 library files to directories under /usr/local/share.
370 It will NOT be able to install the actual programs (binaries) because
372 it does not know programs on Win32 systems have ".exe" extensions.
374 For example, it tries to install sdcc instead of sdcc.exe.
378 After the automated part is finished, you must manually copy the binaries:
380 cd bin (This is the bin directory in your INSTALLDIR)
386 11. Make sure /usr/local/bin is in Your PATH
388 You may add c:\usr\local\bin to your path however your Win32 system allows.
391 example you may add it to the PATH statement in autoexec.bat.
395 Good luck. If you have any questions send them to me or post them
399 3 Compiling.\label{Compiling}
401 3.1 Single Source file projects.\label{One Source File}
403 For single source file projects the process is very simple. Compile
404 your programs with the following command
408 The above command will compile ,assemble and link your source file.
409 Output files are as follows.
411 * sourcefile.asm - Assembler source file created by the compiler
413 * sourcefile.lst - Assembler listing file created by the Assembler
415 * sourcefile.rst - Assembler listing file updated with linkedit information
416 , created by linkage editor
418 * sourcefile.sym - symbol listing for the sourcefile, created by the
421 * sourcefile.rel - Object file created by the assembler, input to Linkage
424 * sourcefile.map - The memory map for the load module, created by the
427 * sourcefile.<ihx | s19> - The load module : ihx - Intel hex format
428 (default ), s19 - Motorola S19 format when compiler option --out-fmt-s19
431 3.2 Projects with multiple source files.
433 SDCC can compile only ONE file at a time. Let us for example assume
434 that you have a project containing the following files.
436 foo1.c ( contains some functions )
438 foo2.c (contains some more functions)
440 foomain.c (contains more functions and the function main)
442 The first two files will need to be compiled separately with the commands
448 Then compile the source file containing main and link the other files
449 together with the following command.
451 sdcc foomain.c foo1.rel foo2.rel
453 Alternatively foomain.c can be separately compiled as well
457 sdcc foomain.rel foo1.rel foo2.rel
459 The file containing the main function MUST be the FIRST file specified
460 in the command line , since the linkage editor processes file in the
461 order they are presented to it.
463 3.3 Projects with additional libraries.
465 Some reusable routines may be compiled into a library, see the documentation
466 for the assembler and linkage editor in the directory SDCCDIR/asxxxx/asxhtm.htm
467 this describes how to create a .lib library file, the libraries created
468 in this manner may be included using the command line, make sure you
469 include the -L <library-path> option to tell the linker where to look
470 for these files. Here is an example, assuming you have the source
471 file 'foomain.c' and a library 'foolib.lib' in the directory 'mylib'.
473 sdcc foomain.c foolib.lib -L mylib
475 Note here that 'mylib' must be an absolute path name.
477 The view of the way the linkage editor processes the library files,
478 it is recommended that you put each source routine in a separate file
479 and combine them using the .lib file. For an example see the standard
480 library file 'libsdcc.lib' in the directory SDCCDIR/sdcc51lib.
482 4 Command Line options\label{Command Line Options}
484 * --model-large\label{--model-large} Generate code for Large model
485 programs see section Memory Models for more details. If this option
486 is used all source files in the project should be compiled with
487 this option. In addition the standard library routines are compiled
488 with small model , they will need to be recompiled.
490 * --model-small \label{--model-small}Generate code for Small Model
491 programs see section Memory Models for more details. This is the
494 * --stack-auto \label{--stack-auto}All functions in the source file
495 will be compiled as reentrant, i.e. the parameters and local variables
496 will be allocated on the stack. see section Parameters and Local
497 Variables for more details. If this option is used all source files
498 in the project should be compiled with this option.
500 * --xstack\label{--xstack} Uses a pseudo stack in the first 256 bytes
501 in the external ram for allocating variables and passing parameters.
502 See section on external stack for more details.
504 * --nogcse\label{--nogcse} Will not do global subexpression elimination,
505 this option may be used when the compiler creates undesirably large
506 stack/data spaces to store compiler temporaries. A warning message
507 will be generated when this happens and the compiler will indicate
508 the number of extra bytes it allocated. It recommended that this
509 option NOT be used , #pragma NOGCSE can be used to turn off global
510 subexpression elimination for a given function only.
512 * --noinvariant\label{--noinvariant} Will not do loop invariant optimizations,
513 this may be turned off for reasons explained for the previous option
514 . For more details of loop optimizations performed see section Loop
515 Invariants.It recommended that this option NOT be used , #pragma
516 NOINVARIANT can be used to turn off invariant optimizations for
517 a given function only.
519 * --noinduction\label{--noinduction} Will not do loop induction optimizations,
520 see section Strength reduction for more details.It recommended that
521 this option NOT be used , #pragma NOINDUCTION can be used to turn
522 off induction optimizations for given function only.
524 * --nojtbound \label{--nojtbound} Will not generate boundary condition
525 check when switch statements are implemented using jump-tables.
526 See section Switch Statements for more details.It recommended that
527 this option NOT be used , #pragma NOJTBOUND can be used to turn
528 off boundary checking for jump tables for a given function only.
530 * --noloopreverse \label{--noloopreverse}Will not do loop reversal
533 * --noregparms\label{--noregparms} By default the first parameter is
534 passed using global registers (DPL,DPH,B,ACC). This option will
535 disable parameter passing using registers. NOTE: if your program
536 uses the 16/32 bit support routines (for multiplication/division)
537 these library routines will need to be recompiled with the --noregparms
540 * --callee-saves function1[,function2][,function3].... \label{--callee-saves}The
541 compiler by default uses a caller saves convention for register
542 saving across function calls, however this can cause unneccessary
543 register pushing & popping when calling small functions from larger
544 functions. This option can be used to switch the register saving
545 convention for the function names specified. The compiler will not
546 save registers when calling these functions, extra code will be
547 generated at the entry & exit for these functions to save & restore
548 the registers used by these functions, this can SUBSTANTIALLY reduce
549 code & improve run time performance of the generated code. In future
550 the compiler (with interprocedural analysis) will be able to determine
551 the appropriate scheme to use for each function call. DO NOT use
552 this option for built-in functions such as _muluint..., if this
553 option is used for a library function the appropriate library function
554 needs to be recompiled with the same option. If the project consists
555 of multiple source files then all the source file should be compiled
556 with the same --callee-saves option string. Also see Pragma Directive\ref{Pragmaa}
557 CALLEE-SAVES.\ref{pragma callee-saves} .
559 * --debug \label{--debug}When this option is used the compiler will
560 generate debug information , that can be used with the SDCDB. The
561 debug information is collected in a file with .cdb extension. For
562 more information see documentation for SDCDB.
564 * --regextend \label{--regextend} This option will cause the compiler
565 to define pseudo registers , if this option is used, all source
566 files in the project should be compiled with this option. See section
567 Register Extension for more details.
569 * --compile-only(-c) \label{--compile-only} will compile and assemble
570 the source only, will not call the linkage editor.
572 * --xram-loc \label{--xram-loc}<Value> The start location of the external
573 ram, default value is 0. The value entered can be in Hexadecimal
574 or Decimal format .eg. --xram-loc 0x8000 or --xram-loc 32768.
576 * --code-loc \label{--code-loc}<Value> The start location of the code
577 segment , default value 0. Note when this option is used the interrupt
578 vector table is also relocated to the given address. The value entered
579 can be in Hexadecimal or Decimal format .eg. --code-loc 0x8000 or
582 * --stack-loc\label{--stack-loc}<Value> The initial value of the stack
583 pointer. The default value of the stack pointer is 0x07 if only
584 register bank 0 is used, if other register banks are used then the
585 stack pointer is initialized to the location above the highest register
586 bank used. eg. if register banks 1 & 2 are used the stack pointer
587 will default to location 0x18. The value entered can be in Hexadecimal
588 or Decimal format .eg. --stack-loc 0x20 or --stack-loc 32. If all
589 four register banks are used the stack will be placed after the
590 data segment (equivalent to --stack-after-data)
592 * --stack-after-data\label{--stack-after-data}This option will cause
593 the stack to be located in the internal ram after the data segment.
595 * --data-loc \label{--data-loc}<Value> The start location of the internal
596 ram data segment, the default value is 0x30.The value entered can
597 be in Hexadecimal or Decimal format .eg. --data-loc 0x20 or --data-loc
600 * --idata-loc\label{--idata-loc}<Value> The start location of the indirectly
601 addressable internal ram, default value is 0x80. The value entered
602 can be in Hexadecimal or Decimal format .eg. --idata-loc 0x88 or
605 * --peep-file\label{--peep-file} <filename> This option can be used
606 to use additional rules to be used by the peep hole optimizer. See
607 section Peep Hole optimizations for details on how to write these
610 * --lib-path (-L) \label{--lib-path}<absolute path to additional libraries>
611 This option is passed to the linkage editor, additional libraries
612 search path. The path name must be absolute. Additional library
613 files may be specified in the command line . See section Compiling
614 programs for more details.
616 * -I <path>\label{-I} The additional location where the pre processor
617 will look for <..h> or ``..h'' files.
619 * -D<macro[=value]> \label{-D}Command line definition of macros. Passed
620 to the pre processor.
622 * -E\label{-E} Run only the C preprocessor. Preprocess all the C source
623 files specified and output the results to standard output.
625 * -M\label{-M} Tell the preprocessor to output a rule suitable for
626 make describing the dependencies of each object file. For each source
627 file, the preprocessor outputs one make-rule whose target is the
628 object file name for that source file and whose dependencies are
629 all the files `#include'd in it. This rule may be a single line
630 or may be continued with `\'-newline if it is long. The list of rules
631 is printed on standard output instead of the preprocessed C program.
634 * -C \label{-C}Tell the preprocessor not to discard comments. Used
635 with the `-E' option.
637 * -MM \label{-MM}Like `-M' but the output mentions only the user header
638 files included with `#include file"'. System header files included
639 with `#include <file>' are omitted.
641 * -Aquestion(answer)\label{-Aquestion(answer)} Assert the answer answer
642 for question, in case it is tested with a preprocessor conditional
643 such as `#if #question(answer)'. `-A-' disables the standard asser-
644 tions that normally describe the target machine.
646 * -Aquestion\label{-Aquestion} (answer) Assert the answer answer for
647 question, in case it is tested with a preprocessor conditional such
648 as `#if #question(answer)'. `-A-' disables the standard assertions
649 that normally describe the target machine.
651 * -Umacro\label{-Umacro} Undefine macro macro. `-U' options are evaluated
652 after all `-D' options, but before any `-include' and `-imac- ros'
655 * -dM\label{-dM} Tell the preprocessor to output only a list of the
656 mac- ro definitions that are in effect at the end of prepro- cessing.
657 Used with the `-E' option.
659 * -dD \label{-dD}Tell the preprocessor to pass all macro definitions
660 into the output, in their proper sequence in the rest of the output.
662 * -dN \label{-dN}Like `-dD' except that the macro arguments and contents
663 are omitted. Only `#define name' is included in the output.
665 * -S \label{-S}Stop after the stage of compilation proper; do not as-
666 semble. The output is an assembler code file for the input file
669 * -Wa asmOption[,asmOption]... Pass the asmOption to the assembler
671 * -Wl linkOption[,linkOption] .. Pass the linkOption to the linker.
673 * --int-long-reent \label{--int-long-rent} Integer (16 bit) and long
674 (32 bit) libraries have been compiled as reentrant. Note by default
675 these libraries are compiled as non-reentrant. See section Installation
678 * --cyclomatic \label{--cyclomatic}This option will cause the compiler
679 to generate an information message for each function in the source
680 file. The message contains some important information about the
681 function. The number of edges and nodes the compiler detected in
682 the control flow graph of the function, and most importantly the
683 cyclomatic complexity see section on Cyclomatic Complexity for more
686 * --float-reent \label{--float-reent} Floating point library is compiled
687 as reentrant.See section Installation for more details.
689 * --out-fmt-ihx\label{--out-fmt-ihx} The linker output (final object
690 code) is in Intel Hex format. (This is the default option).
692 * --out-fmt-s19 \label{--out-fmt-s19}The linker output (final object
693 code) is in Motorola S19 format.
695 * --nooverlay \label{--nooverlay} The compiler will not overlay parameters
696 and local variables of any function, see section Parameters and
697 local variables for more details.
699 * --main-return\label{--main-return} This option can be used when the
700 code generated is called by a monitor program. The compiler will
701 generate a 'ret' upon return from the 'main' function. The default
702 option is to lock up i.e. generate a 'ljmp .' .
704 * --no-peep \label{--no-peep} Disable peep-hole optimization.
706 * --peep-asm \label{--peep-asm} Pass the inline assembler code through
707 the peep hole optimizer. Can cause unexpected changes to inline
708 assembler code , please go through the peephole optimizer rules
709 defnied in file 'SDCCpeeph.def' before using this option.
711 * --iram-size\label{--iram-size} <Value> Causes the linker to check
712 if the interal ram usage is within limits of the given value.
714 The following options are provided for the purpose of retargetting
715 and debugging the compiler . These provided a means to dump the intermediate
716 code (iCode) generated by the compiler in human readable form at various
717 stages of the compilation process.
719 * --dumpraw \label{--dumpraw}. This option will cause the compiler
720 to dump the intermediate code into a file of named <source filename>.dumpraw
721 just after the intermediate code has been generated for a function
722 , i.e. before any optimizations are done. The basic blocks at this
723 stage ordered in the depth first number, so they may not be in sequence
726 * --dumpgcse.\label{--dumpgcse} Will create a dump if iCode, after
727 global subexpression elimination, into a file named <source filename>.dumpgcse.
729 * --dumpdeadcode \label{--dumpdeadcode}.Will create a dump if iCode,
730 after deadcode elimination, into a file named <source filename>.dumpdeadcode.
732 * --dumploop. \label{--dumploop}Will create a dump if iCode, after
733 loop optimizations, into a file named <source filename>.dumploop.
735 * --dumprange. \label{--dump-range}Will create a dump if iCode, after
736 live range analysis, into a file named <source filename>.dumprange.
738 * --dumpregassign. \label{--dumpregassign}Will create a dump if iCode,
739 after register assignment , into a file named <source filename>.dumprassgn.
741 * --dumpall. \label{--dumpall}Will cause all the above mentioned dumps
744 Note that the files created for the dump are appended to each time.
745 So the files should be deleted manually , before each dump is created.
747 When reporting bugs, it will be very helpful if you could include these
748 dumps along with the portion of the code that is causing the problem.
750 5 Language Extensions\label{Language Extension}
752 5.1 Storage Classes.\label{Storage Classes}
754 In addition to the ANSI storage classes SDCC allows the following 8051
755 specific storage classes.
757 5.1.1 xdata.\label{xdata}
759 Variables declared with this storage class will be placed in the extern
760 RAM. This is the default storage class for Large Memory model .
762 eg. xdata unsigned char xduc;
764 5.1.2 data\label{data}
766 This is the default storage class for Small Memory model. Variables
767 declared with this storage class will be allocated in the internal
770 eg. data int iramdata;
772 5.1.3 idata\label{idata}
774 Variables declared with this storage class will be allocated into the
775 indirectly addressable portion of the internal ram of a 8051 .
781 This is a data-type and a storage class specifier. When a variable
782 is declared as a bit , it is allocated into the bit addressable memory
787 5.1.5 sfr / sbit\label{sfr / sbit}
789 Like the bit keyword, sfr / sbit signifies both a data-type and storage
790 class, they are used to describe the special function registers and
791 special bit variables of a 8051.
795 sfr at 0x80 P0; /* special function register P0 at location 0x80 */
797 sbit at 0xd7 CY; /* CY (Carry Flag) */
799 6 Optimizations\label{Optimizations}
801 SDCC performs a a host of standard optimizations in addition to some
802 MCU specific optimizations.
804 6.1 Sub-expression elimination\label{Sub-expression Elimination}
806 The compiler does local and global common subexpression elimination.
813 will be translated to
819 Some subexpressions are not as obvious as the above example.
826 In this case the address arithmetic a->b[i] will be computed only once;
827 the equivalent code in C would be.
833 The compiler will try to keep these temporary variables in registers.
835 6.2 Dead-Code elimination.\label{Dead-code elimination}
842 i = 1; /* dead store */
843 global = 1; /* dead store */
846 global = 3; /* unreachable */
851 int global; void f ()
857 6.3 Copy-Propagation:\label{Copy-Propagation}
877 Note: the dead stores created by this copy propagation will be eliminated
878 by dead-code elimination .
880 6.4 Loop optimizations\label{Loop Optimizations}
882 Two types of loop optimizations are done by SDCC loop invariant lifting
883 and strength reduction of loop induction variables.In addition to
884 the strength reduction the optimizer marks the induction variables
885 and the register allocator tries to keep the induction variables in
886 registers for the duration of the loop. Because of this preference
887 of the register allocator , loop induction optimization causes an
888 increase in register pressure, which may cause unwanted spilling of
889 other temporary variables into the stack / data space . The compiler
890 will generate a warning message when it is forced to allocate extra
891 space either on the stack or data space. If this extra space allocation
892 is undesirable then induction optimization can be eliminated either
893 for the entire source file ( with --noinduction option) or for a given
894 function only (#pragma NOINDUCTION).
896 6.4.1 Loop Invariant:\label{Loop Invariant}
900 for (i = 0 ; i < 100 ; i ++)
906 for ( i = 0; i < 100; i++ ) f += itemp;
908 As mentioned previously some loop invariants are not as apparent, all
909 static address computations are also moved out of the loop.
911 6.4.2 Strength reduction :\label{Strength Reduction}
913 This optimization substitutes an expression by a cheaper expression.
917 for (i=0;i < 100; i++) ar[i*5] = i*3;
923 for (i=0;i< 100;i++) {
929 The more expensive multiplication is changed to a less expensive addition.
931 6.4.3 Loop reversing:\label{Loop reversing}
933 This optimization is done to reduce the overhead of checking loop boundaries
934 for every iteration. Some simple loops can be reversed and implemented
935 using a ``decrement and jump if not zero'' instruction. SDCC checks
936 for the following criterion to determine if a loop is reversible (note:
937 more sophisticated compiers use data-dependency analysis to make this
938 determination, SDCC uses a more simple minded analysis).
940 * The 'for' loop is of the form
941 ``for ( <symbol> = <expression> ; <sym> [< | <=] <expression> ; [<sym>++
945 * The <for body> does not contain ``continue'' or 'break''.
947 * All goto's are contained within the loop.
949 * No function calls within the loop.
951 * The loop control variable <sym> is not assigned any value within
954 * The loop control variable does NOT participate in any arithmetic
955 operation within the loop.
957 * There are NO switch statements in the loop.
959 Note djnz instruction can be used for 8-bit values ONLY, therefore
960 it is advantageous to declare loop control symbols as either 'char'
961 or 'short', ofcourse this may not be possible on all situations.
963 6.5 Algebraic simplifications:\label{Algebraic Simplifications}
965 SDCC does numerous algebraic simplifications, the following is a small
966 sub-set of these optimizations.
969 i = j + 0 ; /* changed to */ i = j;
970 i /= 2; /* changed to */ i >>= 1;
971 i = j - j ; /* changed to */ i = 0;
972 i = j / 1 ; /* changed to */ i = j;
974 Note the subexpressions given above are generally introduced by macro
975 expansions or as a result of copy/constant propagation.
977 6.6 'switch' statements.\label{Switch Statement}
979 SDCC changes switch statements to jump tables when the following conditions
982 * The case labels are in numerical sequence , the labels need not be
983 in order, and the starting number need not be one or zero.
987 switch(i) { switch (i) {
988 case 4:... case 1: ...
989 case 5:... case 2: ...
990 case 3:... case 3: ...
991 case 6:... case 4: ...
994 Both the above switch statements will be implemented using a jump-table.
996 * The number of case labels is at least three, since it takes two conditional
997 statements to handle the boundary conditions.
999 * The number of case labels is less than 84, since each label takes
1000 3 bytes and a jump-table can be utmost 256 bytes long.
1002 Switch statements which have gaps in the numeric sequence or those
1003 that have more that 84 case labels can be split into more than one
1004 switch statement for efficient code generation.
1019 If the above switch statement is broken down into two switch statements
1035 then both the switch statements will be implemented using jump-tables
1036 whereas the unmodified switch statement will not be .
1038 6.7 bit-shifting operations.\label{bit shifting}
1040 Bit shifting is one of the most frequently used operation in embedded
1041 programming . SDCC tries to implement bit-shift operations in the
1042 most efficient way possible.
1052 generates the following code.
1059 In general SDCC will never setup a loop if the shift count is known.
1075 Note that SDCC stores numbers in little-endian format (i.e. lowest
1078 6.7.1 Bit-rotation:\label{bit rotation}
1080 A special case of the bit-shift operation is bit rotation, SDCC recognizes
1081 the following expression to be a left bit-rotation.
1085 i = ( ( i << 1) | ( i >> 7));
1088 will generate the following code.
1094 SDCC uses pattern matching on the parse tree to determine this operation
1095 .Variations of this case will also be recognized as bit-rotation i.e
1096 i = ((i >> 7) | (i << 1)); /* left-bit rotation */
1098 6.8 Highest Order Bit.\label{Highest Order Bit}
1100 It is frequently required to obtain the highest order bit of an integral
1101 type (int,long,short or char types). SDCC recognizes the following
1102 expression to yield the highest order bit and generates optimized
1110 hob = (gint >> 15) & 1;
1114 Will generate the following code.
1117 000A E5*01 62 mov a,(_gint + 1)
1121 000F F5*02 66 mov _foo_hob_1_1,a
1123 Variations of this case however will NOT be recognized . It is a standard
1124 C expression , so I heartily recommend this be the only way to get
1125 the highest order bit, (it is portable). Of course it will be recognized
1126 even if it is embedded in other expressions.
1130 xyz = gint + ((gint >> 15) & 1);
1132 will still be recognized.
1134 6.9 Peep-hole optimizer.\label{Peep-Hole}
1136 The compiler uses a rule based , pattern matching and re-writing mechanism
1137 for peep-hole optimization . It is inspired by 'copt' a peep-hole
1138 optimizer by Christopher W. Fraser (cwfraser@microsoft.com). A default
1139 set of rules are compiled into the compiler, additional rules may
1140 be added with the --peep-file <filename> option. The rule language
1141 is best illustrated with examples.
1145 mov a,%1 } by { mov %1,a }
1147 The above rule will the following assembly sequence
1156 Note: All occurrences of a '%n' ( pattern variable ) must denote the
1157 same string. With the above rule, the assembly sequence
1162 will remain unmodified. Other special case optimizations may be added
1163 by the user (via --peep-file option), eg. some variants of the 8051
1164 MCU allow only 'AJMP' and 'ACALL' , the following two rules will change
1165 all 'LJMP' & 'LCALL' to 'AJMP' & 'ACALL'.
1167 replace { lcall %1 } by { acall %1 }
1168 replace { ljmp %1 } by { ajmp %1 }
1170 The inline-assembler' code is also passed through the peep hole optimizer,
1171 thus the peephole optimizer can also be used as an assembly level
1172 macro expander. The rules themselves are MCU dependent whereas the
1173 rule language infra-structure is MCU independent. Peephole optimization
1174 rules for other MCU can be easily programmed using the rule language.
1176 The syntax for a rule is as follows ,
1178 rule := replace [ restart ] '{' <assembly sequence> '\n'
1180 <assembly sequence> '\n'
1181 '}' [if <functionName> ] '\n'
1182 <assembly sequence> := assembly instruction (each instruction including
1183 labels must be on a separate line).
1185 The optimizer will apply to the rules one by one from the top in the
1186 sequence of their appearance, it will terminate when all rules are
1187 exhausted. If the 'restart' option is specified, then the optimizer
1188 will start matching the rules again from the top, this option for
1189 a rule is expensive (performance), it is intended to be used in situations
1190 where a transformation will trigger the same rule again. A good example
1191 of this the following rule.
1199 Note that the replace pattern cannot be a blank, but can be a comment
1200 line. Without the 'restart' option only the inner most 'pop' 'push'
1201 pair would be eliminated. i.e.
1214 with the 'restart' option the rule will be applied again to the resulting
1215 code and the all the 'pop' 'push' pairs will be eliminated to yield
1220 A conditional function can be attached to a rule. Attaching rules are
1221 somewhat more involved, let me illustrate this with an example.
1227 %2:} if labelInRange
1229 The optimizer does a look-up of a function name table defined in function
1230 'callFuncByName' in the source file SDCCpeeph.c , with the name 'labelInRange',
1231 if it finds a corresponding entry the function is called. Note there
1232 can be no parameters specified for these functions, in this case the
1233 use of '%5' is crucial, since the function labelInRange expects to
1234 find the label in that particular variable (the hash table containing
1235 the variable bindings is passed as a parameter). If you want to code
1236 more such functions , take a close look at the function labelInRange
1237 and the calling mechanism in source file SDCCpeeph.c. I know this
1238 whole thing is a little kludgey , may be some day we will have some
1239 better means. If you are looking at this file, you will also see the
1240 default rules that are compiled into the compiler, you can your own
1241 rules in the default set there if you get tired of specifying the
1244 7 Pointers\label{Pointers}
1246 SDCC allows (via language extensions) pointers to explicitly point
1247 to any of the memory spaces of the 8051. In addition to the explicit
1248 pointers, the compiler also allows a _generic class of pointers which
1249 can be used to point to any of the memory spaces.
1251 Pointer declaration examples.
1253 /* pointer physically in xternal ram pointing to object in internal
1255 data unsigned char * xdata p;
1258 /* pointer physically in code rom pointing to data in xdata space */
1260 xdata unsigned char * code p;
1263 /* pointer physically in code space pointing to data in code space
1265 code unsigned char * code p;
1267 /* the folowing is a generic pointer physically located in xdata space
1271 Well you get the idea. For compatibility with the previous version
1272 of the compiler, the following syntax for pointer declaration is also
1273 supported. Note the above examples will be portable to other commercially
1274 available compilers.
1276 unsigned char _xdata *ucxdp; /* pointer to data in external ram */
1278 unsigned char _data *ucdp ; /* pointer to data in internal ram */
1279 unsigned char _code *uccp ; /* pointer to data in R/O code space */
1280 unsigned char _idata *uccp; /* pointer to upper 128 bytes of ram */
1282 All unqualified pointers are treated as 3 - byte '_generic' pointers.
1283 These type of pointers can also to be explicitly declared.
1285 unsigned char _generic *ucgp;
1287 The highest order byte of the generic pointers contains the data space
1288 information. Assembler support routines are called whenever data is
1289 stored or retrieved using _generic pointers. These are useful for
1290 developing reusable library routines. Explicitly specifying the pointer
1291 type will generate the most efficient code. Pointers declared using
1292 a mixture of OLD/NEW style could have unpredictable results.
1294 8 Parameters & Local Variables\label{Auto Variables}
1296 Automatic (local) variables and parameters to functions can either
1297 be placed on the stack or in data-space. The default action of the
1298 compiler is to place these variables in the internal RAM ( for small
1299 model) or external RAM (for Large model). They can be placed on the
1300 stack either by using the --stack-auto compiler option or by using
1301 the 'reentrant' keyword in the function declaration.
1305 unsigned short foo( short i) reentrant {
1309 Note that when the parameters & local variables are declared in the
1310 internal/external ram the functions are non-reentrant. Since stack
1311 space on 8051 is limited the 'reentrant' keyword or the --stack-auto
1312 option should be used sparingly. Note the reentrant keyword just means
1313 that the parameters & local variables will be allocated to the stack,
1314 it DOES NOT mean that the function is register bank independent.
1316 When compiled with the default option (i.e. non-reentrant ), local
1317 variables can be assigned storage classes and absolute addresses.
1321 unsigned short foo() {
1322 xdata unsigned short i;
1324 data at 0x31 unsiged short j;
1328 In the above example the variable i will be allocated in the external
1329 ram, bvar in bit addressable space and j in internal ram. When compiled
1330 with the --stack-auto or when a function is declared as 'reentrant'
1331 local variables cannot be assigned storage classes or absolute addresses.
1333 Parameters however are not allowed any storage class, (storage classes
1334 for parameters will be ignored), their allocation is governed by the
1335 memory model in use , and the reentrancy options.
1337 8.1 Overlaying\label{Overlaying}
1339 For non-reentrant functions SDCC will try to reduce internal ram space
1340 usage by overlaying parameters and local variables of a function (if
1341 possible). Parameters and local variables of a function will be allocated
1342 to an overlayable segment if the function has no other function calls
1343 and the function is non-reentrant and the memory model is small. If
1344 an explicit storage class is specified for a local variable , it will
1347 Note that the compiler (not the linkage editor) makes the decision
1348 for overlaying the data items. Functions that are called from an interrupt
1349 service routine should be preceded by a #pragma NOOVERLAY if they
1350 are not reentrant Along the same lines the compiler does not do any
1351 processing with the inline assembler code so the compiler might incorrectly
1352 assign local variables and parameters of a function into the overlay
1353 segment if the only function call from a function is from inline assembler
1354 code, it is safe to use the #pragma NOOVERLAY for functions which
1355 call other functions using inline assembler code.
1357 Parameters and Local variables of functions that contain 16 or 32 bit
1358 multiplication or division will NOT be overlayed since these are implemented
1359 using external functions.
1365 void set_error( unsigned short errcd)
1370 void some_isr () interrupt 2 using 1
1377 In the above example the parameter errcd for the function set_error
1378 would be assigned to the overlayable segment (if the #pragma NOOVERLAY
1379 was not present) , this could cause unpredictable runtime behavior.
1380 The pragma NOOVERLAY ensures that the parameters and local variables
1381 for the function are NOT overlayed.
1383 9 critical Functions.\label{Critical}
1385 A special keyword may be associated with a function declaring it as
1386 'critical'. SDCC will generate code to disable all interrupts upon
1387 entry to a critical function and enable them back before returning
1388 . Note that nesting critical functions may cause unpredictable results.
1398 The critical attribute maybe used with other attributes like reentrant.
1400 10 Absolute addressing.\label{Absolute Addressing}
1402 Data items can be assigned an absolute address with the at <address>
1403 keyword, in addition to a storage class.
1407 xdata at 0x8000 unsigned char PORTA_8255 ;
1409 In the above example the PORTA_8255 will be allocated to the location
1410 0x8000 of the external ram.
1412 Note that is this feature is provided to give the programmer access
1413 to memory mapped devices attached to the controller. The compiler
1414 does not actually reserve any space for variables declared in this
1415 way (they are implemented with an equate in the assembler), thus it
1416 is left to the programmer to make sure there are no overlaps with
1417 other variables that are declared without the absolute address, the
1418 assembler listing file (.lst) and the linker output files (<filename>.rst)
1419 and (<filename>.map) are a good places to look for such overlaps.
1421 Absolute address can be specified for variables in all storage classes.
1427 The above example will allocate the variable at offset 0x02 in the
1428 bit-addressable space. There is no real advantage to assigning absolute
1429 addresses to variables in this manner , unless you want strict control
1430 over all the variables allocated.
1432 11 Interrupt Service Routines\label{Interrupt Service Rouines}
1434 SDCC allows interrupt service routines to be coded in C, with some
1437 void timer_isr (void) interrupt 2 using 1
1442 The number following the 'interrupt' keyword is the interrupt number
1443 this routine will service. The compiler will insert a call to this
1444 routine in the interrupt vector table for the interrupt number specified.
1445 The 'using' keyword is used to tell the compiler to use the specified
1446 register bank (8051 specific) when generating code for this function.
1447 Note that when some function is called from an interrupt service routine
1448 it should be preceded by a #pragma NOOVERLAY (if it is not reentrant)
1449 . A special note here, int (16 bit) and long (32 bit) integer division,
1450 multiplication & modulus operations are implemented using external
1451 support routines developed in ANSI-C, if an interrupt service routine
1452 needs to do any of these operations then the support routines (as
1453 mentioned in a following section) will have to recompiled using the
1454 --stack-auto option and the source file will need to be compiled using
1455 the --int-long-rent compiler option.
1457 If you have multiple source files in your project, interrupt service
1458 routines can be present in any of them, but a prototype of the isr
1459 MUST be present in the file that contains the function 'main'.
1461 Interrupt Numbers and the corresponding address & descriptions for
1462 the Standard 8051 are listed below. SDCC will automatically adjust
1463 the interrupt vector table to the maximum interrupt number specified.
1465 Interrupt # Description Vector Address
1472 If the interrupt service routine is defined without a register bank
1473 or with register bank 0 (using 0), the compiler will save the registers
1474 used by itself on the stack (upon entry and restore them at exit),
1475 however if such an interrupt service routine calls another function
1476 then the entire register bank will be saved on the stack. This scheme
1477 may be advantageous for small interrupt service routines which have
1480 If the interrupt service routine is defined to be using a specific
1481 register bank then only ``a'',''b'' & ``dptr'' are save and restored,
1482 if such an interrupt service routine calls another function (using
1483 another register bank) then the entire register bank of the called
1484 function will be saved on the stack. This scheme is recommended for
1485 larger interrupt service routines.
1487 Calling other functions from an interrupt service routine is not recommended
1488 avoid it if possible.
1490 12 Startup Code\label{Startup}
1492 The compiler inserts a jump to the C routine _sdcc__external__startup()
1493 at the start of the CODE area. This routine can be found in the file
1494 SDCCDIR/sdcc51lib/_startup.c , by default this routine returns 0,
1495 if this routine returns a non-zero value , the static & global variable
1496 initialization will be skipped and the function main will be invoked,
1497 other wise static & global variables will be initialized before the
1498 function main is invoked.
1500 13 Inline assembler code.\label{Inline}
1502 SDCC allows the use of in-line assembler with a few restriction as
1503 regards labels. All labels defined within inline assembler code HAS
1504 TO BE of the form nnnnn$ where nnnn is a number less than 100 (which
1505 implies a limit of utmost 100 inline assembler labels per function).
1506 It is strongly recommended that each assembly instruction (including
1507 labels) be placed in a separate line ( as the example shows). When
1508 the --peep-asm command line option is used, the inline assembler code
1509 will be passed through the peephole optimizer, this might cause some
1510 unexpected changes in the inline assembler code, please go throught
1511 the peephole optimizer rules defined in file 'SDCCpeeph.def' carefully
1512 before using this option.
1522 The inline assembler code can contain any valid code understood by
1523 the assembler (this includes any assembler directives and comment
1524 lines ) . The compiler does not do any validation of the code within
1525 the _asm ... _endasm; keyword pair.
1527 Inline assembler code cannot reference any C-Labels however it can
1528 reference labels defined by the inline assembler.
1533 ... /* some c code */
1535 ; some assembler code
1538 ... /* some more c code */
1539 clabel: /* inline assembler cannot reference this label */
1541 $0003: ;label (can be reference by inline assembler only)
1546 In other words inline assembly code can access labels defined in inline
1547 assembly. The same goes the other way, ie. labels defines in inline
1548 assembly CANNOT be accessed by C statements.
1550 14 int (16 bit) and long (32 bit ) support.\label{int and long}
1552 For signed & unsigned int (16 bit) and long (32 bit) variables, division,
1553 multiplication and modulus operations are implemented by support routines.
1554 These support routines are all developed in ANSI-C to facilitate porting
1555 to other MCUs. The following files contain the described routine,
1556 all of them can be found in the directory SDCCDIR/sdcc51lib
1558 * _mulsint.c - signed 16 bit multiplication (calls _muluint)
1560 * _muluint.c - unsigned 16 bit multiplication
1562 * _divsint.c - signed 16 bit division (calls _divuint)
1564 * _divuint.c - unsigned 16 bit division.
1566 * _modsint.c - signed 16 bit modulus (call _moduint)
1568 * _moduint.c - unsigned 16 bit modulus.
1570 * _mulslong.c - signed 32 bit multiplication (calls _mululong)
1572 * _mululong.c - unsigned32 bit multiplication.
1574 * _divslong.c - signed 32 division (calls _divulong)
1576 * _divulong.c - unsigned 32 division.
1578 * _modslong.c - signed 32 bit modulus (calls _modulong).
1580 * _modulong.c - unsigned 32 bit modulus.
1582 All these routines are compiled as non-reentrant and small model. Since
1583 they are compiled as non-reentrant, interrupt service routines should
1584 not do any of the above operations, if this unavoidable then the above
1585 routines will need to ne compiled with the --stack-auto option, after
1586 which the source program will have to be compiled with --int-long-rent
1589 15 Floating point support\label{Float}
1591 SDCC supports IEEE (single precision 4bytes) floating point numbers.The
1592 floating point support routines are derived from gcc's floatlib.c
1593 and consists of the following routines.
1595 * _fsadd.c - add floating point numbers.
1597 * _fssub.c - subtract floating point numbers
1599 * _fsdiv.c - divide floating point numbers
1601 * _fsmul.c - multiply floating point numbers
1603 * _fs2uchar.c - convert floating point to unsigned char
1605 * _fs2char.c - convert floating point to signed char.
1607 * _fs2uint.c - convert floating point to unsigned int.
1609 * _fs2int.c - convert floating point to signed int.
1611 * _fs2ulong.c - convert floating point to unsigned long.
1613 * _fs2long.c - convert floating point to signed long.
1615 * _uchar2fs.c - convert unsigned char to floating point
1617 * _char2fs.c - convert char to floating point number
1619 * _uint2fs.c - convert unsigned int to floating point
1621 * _int2fs.c - convert int to floating point numbers
1623 * _ulong2fs.c - convert unsigned long to floating point number
1625 * _long2fs.c - convert long to floating point number.
1627 Note if all these routines are used simultaneously the data space might
1628 overflow. For serious floating point usage it is strongly recommended
1629 that the Large model be used (in which case the floating point routines
1630 mentioned above will need to recompiled with the --model-Large option).
1632 16 Memory Models\label{Memory Models}
1634 SDCC allows two memory models, modules compiled with different memory
1635 models should be combined together, the results would be unpredictable.
1636 The support routines supplied with the compiler are compiled in small-model
1637 by default, and will need to be recompiled using the large model if
1638 the large model is used. In general the use of the large model is
1641 When the large model is used all variables declared without a storage
1642 class will be allocated into the external ram, this includes all parameters
1643 and local variables (for non-reentrant functions). When the small
1644 model is used variables without storage class are allocated in the
1647 Judicious usage of the processor specific storage classes and the 'reentrant'
1648 function type will yield much more efficient code, than using the
1651 17 Defines created by the compiler.\label{Defines.}
1653 The compiler creates the following #defines .
1655 * SDCC - this Symbol is always defined.
1657 * SDCC_STACK_AUTO - this symbol is defined when --stack-auto option
1660 * SDCC_MODEL_SMALL - when small model is used.
1662 * SDCC_MODEL_LARGE - when --model-large is used.
1664 * SDCC_USE_XSTACK - when --xstack option is used.
1666 18 Pragmas\label{Pragmaa}
1668 SDCC supports the following #pragma directives. This directives are
1669 applicable only at a function level.
1671 * SAVE\label{pragma save} - this will save all the current options .
1673 * RESTORE \label{pragma restore}- will restore the saved options from
1674 the last save. Note that SAVES & RESTOREs cannot be nested. SDCC
1675 uses the same buffer to save the options each time a SAVE is called.
1677 * NOGCSE\label{pragma nogcse} - will stop global subexpression elimination.
1679 * NOINDUCTION \label{pragma noinduction}- will stop loop induction
1682 * NOJTBOUND \label{pragma nojtbound}- will not generate code for boundary
1683 value checking , when switch statements are turned into jump-tables.
1685 * NOOVERLAY \label{pragma nooverlay}- the compiler will not overlay
1686 the parameters and local variables of a function.
1688 * NOLOOPREVERSE \label{pragma noloopreverse}- Will not do loop reversal
1691 * EXCLUDE NONE | {acc[,b[,dpl[,dph]]]\label{pragma exclude} - The exclude
1692 pragma disables generation of pair of push/pop instruction in ISR
1693 function (using interrupt keyword). The directive should be placed
1694 immediately before the ISR function definition and it affects ALL
1695 ISR functions following it. To enable the normal register saving
1696 for ISR functions use ``#pragma EXCLUDE none''
1698 * CALLEE-SAVES function1[,function2[,function3...]]\label{pragma callee-saves}
1699 - The compiler by default uses a caller saves convention for register
1700 saving across function calls, however this can cause unneccessary
1701 register pushing & popping when calling small functions from larger
1702 functions. This option can be used to switch the register saving
1703 convention for the function names specified. The compiler will not
1704 save registers when calling these functions, extra code will be
1705 generated at the entry & exit for these functions to save & restore
1706 the registers used by these functions, this can SUBSTANTIALLY reduce
1707 code & improve run time performance of the generated code. In future
1708 the compiler (with interprocedural analysis) will be able to determine
1709 the appropriate scheme to use for each function call. If --callee-saves\ref{--callee-saves}
1710 command line option is used, the function names specified in #pragma
1711 CALLEE-SAVES is appended to the list of functions specified inthe
1714 The pragma's are intended to be used to turn-off certain optimizations
1715 which might cause the compiler to generate extra stack / data space
1716 to store compiler generated temporary variables. This usually happens
1717 in large functions. Pragma directives should be used as shown in the
1718 following example, they are used to control options & optimizations
1719 for a given function; pragmas should be placed before and/or after
1720 a function, placing pragma's inside a function body could have unpredictable
1725 #pragma SAVE /* save the current settings */
1726 #pragma NOGCSE /* turnoff global subexpression elimination */
1727 #pragma NOINDUCTION /* turn off induction optimizations */
1734 #pragma RESTORE /* turn the optimizations back on */
1736 The compiler will generate a warning message when extra space is allocated.
1737 It is strongly recommended that the SAVE and RESTORE pragma's be used
1738 when changing options for a function.
1740 19 Library routines.\label{Library}
1742 The following library routines are provided for your convenience.
1744 stdio.h - Contains the following functions printf & sprintf these routines
1745 are developed by Martijn van Balen <balen@natlab.research.philips.com>.
1747 %[flags][width][b|B|l|L]type
1749 flags: - left justify output in specified field width
1750 + prefix output with +/- sign if output is signed type
1751 space prefix output with a blank if it's a signed positive value
1752 width: specifies minimum number of characters outputted for numbers
1755 - For numbers, spaces are added on the left when needed.
1756 If width starts with a zero character, zeroes and used
1758 - For strings, spaces are are added on the left or right (when
1759 flag '-' is used) when needed.
1761 b/B: byte argument (used by d, u, o, x, X)
1762 l/L: long argument (used by d, u, o, x, X)
1763 type: d decimal number
1764 u unsigned decimal number
1765 o unsigned octal number
1766 x unsigned hexadecimal number (0-9, a-f)
1767 X unsigned hexadecimal number (0-9, A-F)
1769 s string (generic pointer)
1770 p generic pointer (I:data/idata, C:code, X:xdata, P:paged)
1771 f float (still to be implemented)
1773 Also contains a very simple version of printf (printf_small). This
1774 simplified version of printf supports only the following formats.
1776 format output type argument-type
1779 %hd decimal short/char
1781 %lx hexadecimal long
1782 %hx hexadecimal short/char
1785 %ho octal short/char
1786 %c character char/short
1787 %s character _generic pointer
1789 The routine is very stack intesive , --stack-after-data parameter
1790 should be used when using this routine, the routine also takes about
1791 1K of code space .It also expects an external function named putchar(char
1792 ) to be present (this can be changed). When using the %s format
1793 the string / pointer should be cast to a generic pointer. eg.
1795 printf_small(``my str %s, my int %d\n'',(char _generic *)mystr,myint);
1797 * stdarg.h - contains definition for the following macros to be used
1798 for variable parameter list, note that a function can have a variable
1799 parameter list if and only if it is 'reentrant'
1801 va_list, va_start, va_arg, va_end.
1803 * setjmp.h - contains defintion for ANSI setjmp & longjmp routines.
1804 Note in this case setjmp & longjmp can be used between functions
1805 executing within the same register bank, if long jmp is executed
1806 from a function that is using a different register bank from the
1807 function issuing the setjmp function, the results may be unpredictable.
1808 The jump buffer requires 3 bytes of data (the stack pointer & a
1809 16 byte return address), and can be placed in any address space.
1811 * stdlib.h - contains the following functions.
1815 * string.h - contains the following functions.
1817 strcpy, strncpy, strcat, strncat, strcmp, strncmp, strchr, strrchr,
1818 strspn, strcspn, strpbrk, strstr, strlen, strtok, memcpy, memcmp,
1821 * ctype.h - contains the following routines.
1823 iscntrl, isdigit, isgraph, islower, isupper, isprint, ispunct, isspace,
1824 isxdigit, isalnum, isalpha.
1826 * malloc.h - The malloc routines are developed by Dmitry S. Obukhov
1827 (dso@usa.net). These routines will allocate memory from the external
1828 ram. Here is a description on how to use them (as described by the
1832 // #define DYNAMIC_MEMORY_SIZE 0x2000
1834 // unsigned char xdata dynamic_memory_pool[DYNAMIC_MEMORY_SIZE];
1836 // unsigned char xdata * current_buffer;
1841 // init_dynamic_memory(dynamic_memory_pool,DYNAMIC_MEMORY_SIZE);
1843 // //Now it's possible to use malloc.
1845 // current_buffer = malloc(0x100);
1848 * serial.h - Serial IO routines are also developed by Dmitry S. Obukhov
1849 (dso@usa.net). These routines are interrupt driven with a 256 byte
1850 circular buffer, they also expect external ram to be present. Please
1851 see documentation in file SDCCDIR/sdcc51lib/serial.c . Note the
1852 header file ``serial.h'' MUST be included in the file containing
1853 the 'main' function.
1855 * ser.h - Alternate serial routine provided by Wolfgang Esslinger <wolfgang@WiredMinds.com>
1856 these routines are more compact and faster. Please see documentation
1857 in file SDCCDIR/sdcc51lib/ser.c
1859 * ser_ir.h - Another alternate set of serial routines provided by Josef
1860 Wolf <jw@raven.inka.de> , these routines do not use the external
1863 * reg51.h - contains register definitions for a standard 8051
1865 * reg552.h - contains register definitions for 80C552.
1867 * float.h - contains min, max and other floating point related stuff.
1869 All library routines are compiled as --model-small , they are all non-reentrant,
1870 if you plan to use the large model or want to make these routines
1871 reentrant, then they will have to be recompiled with the appropriate
1874 Have not had time to do the more involved routines like printf, will
1875 get to them shortly.
1877 20 Interfacing with assembly routines.\label{Interface_asm}
1879 20.1 Global registers used for parameter passing.
1881 By default the compiler uses the global registers ``DPL,DPH,B,ACC''
1882 to pass the first parameter to a routine, the second parameter onwards
1883 is either allocated on the stack (for reentrant routines or --stack-auto
1884 is used) or in the internal / external ram (depending on the memory
1887 20.1.1 Assembler routine non-reentrant
1889 In the following example the function cfunc calls an assembler routine
1890 asm_func, which takes two parameters.
1892 extern int asm_func( unsigned short, unsigned short);
1895 int c_func (unsigned short i, unsigned short j)
1897 return asm_func(i,j);
1901 return c_func(10,9);
1904 The corresponding assembler function is:-
1906 .globl _asm_func_PARM_2
1909 _asm_func_PARM_2: .ds 1
1913 add a,_asm_func_PARM_2
1918 Note here that the return values are placed in 'dpl' - One byte return
1919 value, 'dpl' LSB & 'dph' MSB for two byte values. 'dpl', 'dph' and
1920 'b' for three byte values (generic pointers) and 'dpl','dph','b' &
1921 'acc' for four byte values.
1923 The parameter naming convention is _<function_name>_PARM_<n>, where
1924 n is the parameter number starting from 1, and counting from the left.
1925 The first parameter is passed in ``dpl'' for One bye parameter, ``dptr''
1926 if two bytes, ``b,dptr'' for three bytes and ``acc,b,dptr'' for four
1927 bytes, the varaible name for the second parameter will be _<function_name>_PARM_2.
1929 Assemble the assembler routine with the following command.
1931 asx8051 -losg asmfunc.asm
1933 Then compile and link the assembler routine to the C source file with
1934 the following command,
1936 sdcc cfunc.c asmfunc.rel
1938 20.1.2 Assembler routine is reentrant
1940 In this case the second parameter onwards will be passed on the stack
1941 , the parameters are pushed from right to left i.e. after the call
1942 the left most parameter will be on the top of the stack. Here is an
1945 extern int asm_func( unsigned short, unsigned short);
1949 int c_func (unsigned short i, unsigned short j) reentrant
1951 return asm_func(i,j);
1955 return c_func(10,9);
1958 The corresponding assembler routine is.
1979 The compiling and linking procedure remains the same, however note
1980 the extra entry & exit linkage required for the assembler code, _bp
1981 is the stack frame pointer and is used to compute the offset into
1982 the stack for parameters and local variables.
1984 20.2 With --noregparms option.
1986 When the source is compiled with --noregparms option , space is allocated
1987 for each of the parameters passed to a routine.
1989 20.2.1 Assembler routine non-reentrant.
1991 In the following example the function cfunc calls an assembler routine
1992 asm_func, which takes two parameters.
1994 extern int asm_func( unsigned short, unsigned short);
1997 int c_func (unsigned short i, unsigned short j)
1999 return asm_func(i,j);
2003 return c_func(10,9);
2006 The corresponding assembler function is:-
2008 .globl _asm_func_PARM_1
2009 .globl _asm_func_PARM_2
2012 _asm_func_PARM_1: .ds 1
2013 _asm_func_PARM_2: .ds 1
2016 mov a,_asm_func_PARM_1
2017 add a,_asm_func_PARM_2
2022 Note here that the return values are placed in 'dpl' - One byte return
2023 value, 'dpl' LSB & 'dph' MSB for two byte values. 'dpl', 'dph' and
2024 'b' for three byte values (generic pointers) and 'dpl','dph','b' &
2025 'acc' for four byte values.
2027 The parameter naming convention is _<function_name>_PARM_<n>, where
2028 n is the parameter number starting from 1, and counting from the left.
2029 i.e. the left-most parameter name will be _<function_name>_PARM_1.
2031 Assemble the assembler routine with the following command.
2033 asx8051 -losg asmfunc.asm
2035 Then compile and link the assembler routine to the C source file with
2036 the following command,
2038 sdcc cfunc.c asmfunc.rel
2040 20.2.2 Assembler routine is reentrant.
2042 In this case the parameters will be passed on the stack , the parameters
2043 are pushed from right to left i.e. after the call the left most parameter
2044 will be on the top of the stack. Here is an example.
2046 extern int asm_func( unsigned short, unsigned short);
2050 int c_func (unsigned short i, unsigned short j) reentrant
2052 return asm_func(i,j);
2056 return c_func(10,9);
2059 The corresponding assembler routine is.
2081 The compiling and linking procedure remains the same, however note
2082 the extra entry & exit linkage required for the assembler code, _bp
2083 is the stack frame pointer and is used to compute the offset into
2084 the stack for parameters and local variables.
2086 21 External Stack.\label{xstack}
2088 The external stack is located at the start of the external ram segment
2089 , and is 256 bytes in size. When --xstack option is used to compile
2090 the program , the parameters and local variables of all reentrant
2091 functions are allocated in this area. This option is provided for
2092 programs with large stack space requirements. When used with the --stack-auto
2093 option, all parameters and local variables are allocated on the external
2094 stack (note support libraries will need to be recompiled with the
2097 The compiler outputs the higher order address byte of the external
2098 ram segment into PORT P2, therefore when using the External Stack
2099 option, this port MAY NOT be used by the application program.
2101 22 ANSI-Compliance.\label{ANSI_Compliance}
2103 Deviations from the compliancy.
2105 1. functions are not always reentrant.
2107 2. structures cannot be assigned values directly, cannot be passed as
2108 function parameters or assigned to each other and cannot be a return
2109 value from a function.
2118 s1 = s2 ; /* is invalid in SDCC although allowed in ANSI */
2122 struct s foo1 (struct s parms) /* is invalid in SDCC although allowed
2127 return rets;/* is invalid in SDCC although allowed in ANSI */
2130 1. 'long long' (64 bit integers) not supported.
2132 2. 'double' precision floating point not supported.
2134 3. integral promotions are suppressed. What does this mean ? The compiler
2135 will not implicitly promote an integer expression to a higher order
2136 integer, exception is an assignment or parameter passing.
2138 4. No support for setjmp and longjmp (for now).
2140 5. Old K&R style function declarations are NOT allowed.
2142 foo( i,j) /* this old style of function declarations */
2143 int i,j; /* are valid in ANSI .. not valid in SDCC */
2148 1. functions declared as pointers must be dereferenced during the call.
2153 /* has to be called like this */
2154 (*foo)();/* ansi standard allows calls to be made like 'foo()' */
2156 23 Cyclomatic Complexity\label{Cyclomatic}
2158 Cyclomatic complexity of a function is defined as the number of independent
2159 paths the program can take during execution of the function. This
2160 is an important number since it defines the number test cases you
2161 have to generate to validate the function . The accepted industry
2162 standard for complexity number is 10, if the cyclomatic complexity
2163 reported by SDCC exceeds 10 you should think about simplification
2164 of the function logic.
2166 Note that the complexity level is not related to the number of lines
2167 of code in a function. Large functions can have low complexity, and
2168 small functions can have large complexity levels. SDCC uses the following
2169 formula to compute the complexity.
2171 complexity = (number of edges in control flow graph) -
2172 (number of nodes in control flow graph) + 2;
2174 Having said that the industry standard is 10, you should be aware that
2175 in some cases it may unavoidable to have a complexity level of less
2176 than 10. For example if you have switch statement with more than 10
2177 case labels, each case label adds one to the complexity level. The
2178 complexity level is by no means an absolute measure of the algorithmic
2179 complexity of the function, it does however provide a good starting
2180 point for which functions you might look at for further optimization.
2184 Here are a few guide-lines that will help the compiler generate more
2185 efficient code, some of the tips are specific to this compiler others
2186 are generally good programming practice.
2188 * Use the smallest data type to represent your data-value. If it is
2189 known in advance that the value is going to be less than 256 then
2190 use a 'short' or 'char' instead of an 'int'.
2192 * Use unsigned when it is known in advance that the value is not going
2193 to be negative. This helps especially if you are doing division
2196 * NEVER jump into a LOOP.
2198 * Declare the variables to be local whenever possible, especially loop
2199 control variables (induction).
2201 * Since the compiler does not do implicit integral promotion, the programmer
2202 should do an explicit cast when integral promotion is required.
2204 * Reducing the size of division , multiplication & modulus operations
2205 can reduce code size substantially. Take the following code for
2208 foobar( unsigned int p1, unsigned char ch)
2210 unsigned char ch1 = p1 % ch ;
2214 For the modulus operation the variable ch will be promoted to unsigned
2215 int first then the modulus operation will be performed (this will
2216 lead to a call to a support routine). If the code is changed to
2218 foobar( unsigned int p1, unsigned char ch)
2220 unsigned char ch1 = (unsigned char)p1 % ch ;
2224 It would substantially reduce the code generated (future versions
2225 of the compiler will be smart enough to detect such optimization
2228 Notes from an USER ( Trefor@magera.freeserve.co.uk )
2230 The 8051 family of micro controller have a minimum of 128 bytes of
2231 internal memory which is structured as follows
2233 - Bytes 00-1F - 32 bytes to hold up to 4 banks of the registers R7
2236 - Bytes 20-2F - 16 bytes to hold 128 bit variables and
2238 - Bytes 30-7F - 60 bytes for general purpose use.
2240 Normally the SDCC compiler will only utilise the first bank of registers,
2241 but it is possible to specify that other banks of registers should
2242 be used in interrupt routines. By default, the compiler will place
2243 the stack after the last bank of used registers, i.e. if the first
2244 2 banks of registers are used, it will position the base of the internal
2245 stack at address 16 (0X10). This implies that as the stack grows,
2246 it will use up the remaining register banks, and the 16 bytes used
2247 by the 128 bit variables, and 60 bytes for general purpose use.
2249 By default, the compiler uses the 60 general purpose bytes to hold
2250 "near data". The compiler/optimiser may also declare some Local Variables
2251 in this area to hold local data.
2253 If any of the 128 bit variables are used, or near data is being used
2254 then care needs to be taken to ensure that the stack does not grow
2255 so much that it starts to over write either your bit variables or
2256 "near data". There is no runtime checking to prevent this from happening.
2258 The amount of stack being used is affected by the use of the "internal
2259 stack" to save registers before a subroutine call is made, - --stack-auto
2260 will declare parameters and local variables on the stack - the number
2261 of nested subroutines.
2263 If you detect that the stack is over writing you data, then the following
2264 can be done. --xstack will cause an external stack to be used for
2265 saving registers and (if --stack-auto is being used) storing parameters
2266 and local variables. However this will produce more and code which
2267 will be slower to execute.
2269 --stack-loc will allow you specify the start of the stack, i.e. you
2270 could start it after any data in the general purpose area. However
2271 this may waste the memory not used by the register banks and if the
2272 size of the "near data" increases, it may creep into the bottom of
2275 --stack-after-data, similar to the --stack-loc, but it automatically
2276 places the stack after the end of the "near data". Again this could
2277 waste any spare register space.
2279 --data-loc allows you to specify the start address of the near data.
2280 This could be used to move the "near data" further away from the stack
2281 giving it more room to grow. This will only work if no bit variables
2282 are being used and the stack can grow to use the bit variable space.
2286 If you find that the stack is over writing your bit variables or "near
2287 data" then the approach which best utilised the internal memory is
2288 to position the "near data" after the last bank of used registers
2289 or, if you use bit variables, after the last bit variable by using
2290 the --data-loc, e.g. if two register banks are being used and no data
2291 variables, --data-loc 16, and - use the --stack-after-data option.
2293 If bit variables are being used, another method would be to try and
2294 squeeze the data area in the unused register banks if it will fit,
2295 and start the stack after the last bit variable.
2297 25 Retargetting for other MCUs.\label{Retargetting}
2299 The issues for retargetting the compiler are far too numerous to be
2300 covered by this document. What follows is a brief description of each
2301 of the seven phases of the compiler and its MCU dependency.
2303 1. Parsing the source and building the annotated parse tree. This phase
2304 is largely MCU independent (except for the language extensions).
2305 Syntax & semantic checks are also done in this phase , along with
2306 some initial optimizations like back patching labels and the pattern
2307 matching optimizations like bit-rotation etc.
2309 2. The second phase involves generating an intermediate code which can
2310 be easy manipulated during the later phases. This phase is entirely
2311 MCU independent. The intermediate code generation assumes the target
2312 machine has unlimited number of registers, and designates them with
2313 the name iTemp. The compiler can be made to dump a human readable
2314 form of the code generated by using the --dumpraw option.
2316 3. This phase does the bulk of the standard optimizations and is also
2317 MCU independent. This phase can be broken down into several sub-phases.
2319 * Break down intermediate code (iCode) into basic blocks.
2321 * Do control flow & data flow analysis on the basic blocks.
2323 * Do local common subexpression elimination, then global subexpression
2326 * dead code elimination
2328 * loop optimizations
2330 * if loop optimizations caused any changes then do 'global subexpression
2331 elimination' and 'dead code elimination' again.
2333 4. This phase determines the live-ranges; by live range I mean those
2334 iTemp variables defined by the compiler that still survive after
2335 all the optimizations. Live range analysis is essential for register
2336 allocation, since these computation determines which of these iTemps
2337 will be assigned to registers, and for how long.
2339 5. Phase five is register allocation. There are two parts to this process .
2341 (a) The first part I call 'register packing' (for lack of a better
2342 term) . In this case several MCU specific expression folding is
2343 done to reduce register pressure.
2345 (b) The second part is more MCU independent and deals with allocating
2346 registers to the remaining live ranges. A lot of MCU specific
2347 code does creep into this phase because of the limited number
2348 of index registers available in the 8051.
2350 6. The Code generation phase is (unhappily), entirely MCU dependent
2351 and very little (if any at all) of this code can be reused for other
2352 MCU. However the scheme for allocating a homogenized assembler operand
2353 for each iCode operand may be reused.
2355 7. As mentioned in the optimization section the peep-hole optimizer
2356 is rule based system, which can reprogrammed for other MCUs.
2358 26 Reporting Bugs\label{Bugs}
2360 Shoot of an email to 'sandeep.dutta@usa.net', as a matter of principle
2361 I always reply to all email's sent to me. Bugs will be fixed ASAP.
2362 When reporting a bug , it is useful to include a small snippet of
2363 code that is causing the problem, if possible compile your program
2364 with the --dumpall option and send the dump files along with the bug
2367 27 SDCDB - Source level debugger.
2369 SDCC is distributed with a source level debugger. The debugger uses
2370 a command line interface, the command repertoire of the debugger has
2371 been kept as close to gdb ( the GNU debugger) as possible. The configuration
2372 and build process of the compiler see Installation \ref{Installation}
2373 also builds and installs the debugger in the target directory specified
2374 during configuration. The debugger allows you debug BOTH at the C
2375 source and at the ASM source level.
2377 27.1 Compiling for debugging.
2379 The --debug option must be specified for all files for which debug
2380 information is to be generated. The complier generates a .cdb file
2381 for each of these files. The linker updates the .cdb file with the
2382 address information. This .cdb is used by the debugger .
2384 27.2 How the debugger works.
2386 When the --debug option is specified the compiler generates extra symbol
2387 information some of which are put into the the assembler source and
2388 some are put into the .cdb file, the linker updates the .cdb file
2389 with the address information for the symbols. The debugger reads the
2390 symbolic information generated by the compiler & the address information
2391 generated by the linker. It uses the SIMULATOR (Daniel's S51) to execute
2392 the program, the program execution is controlled by the debugger.
2393 When a command is issued for the debugger, it translates it into appropriate
2394 commands for the simulator .
2396 27.3 Starting the debugger.
2398 The debugger can be started using the following command line. (Assume
2399 the file you are debugging has
2405 The debugger will look for the following files.
2407 1. foo.c - the source file.
2409 2. foo.cdb - the debugger symbol information file.
2411 3. foo.ihx - the intel hex format object file.
2413 27.4 Command line options.
2415 * --directory=<source file directory> this option can used to specify
2416 the directory search list. The debugger will look into the directory
2417 list specified for source , cdb & ihx files. The items in the directory
2418 list must be separated by ':' , e.g. if the source files can be
2419 in the directories /home/src1 and /home/src2, the --directory option
2420 should be --directory=/home/src1:/home/src2 . Note there can be
2421 no spaces in the option.
2423 * -cd <directory> - change to the <directory>.
2425 * -fullname - used by GUI front ends.
2427 * -cpu <cpu-type> - this argument is passed to the simulator please
2428 see the simulator docs for details.
2430 * -X <Clock frequency > this options is passed to the simulator please
2431 see simulator docs for details.
2433 * -s <serial port file> passed to simulator see simulator docs for
2436 * -S <serial in,out> passed to simulator see simulator docs for details.
2438 27.5 Debugger Commands.
2440 As mention earlier the command interface for the debugger has been
2441 deliberately kept as close the GNU debugger gdb , as possible, this
2442 will help int integration with existing graphical user interfaces
2443 (like ddd, xxgdb or xemacs) existing for the GNU debugger.
2445 27.5.1 break [line | file:line | function | file:function]
2447 Set breakpoint at specified line or function.
2450 sdcdb>break foo.c:100
2452 sdcdb>break foo.c:funcfoo
2454 27.5.2 clear [line | file:line | function | file:function ]
2456 Clear breakpoint at specified line or function.
2459 sdcdb>clear foo.c:100
2461 sdcdb>clear foo.c:funcfoo
2465 Continue program being debugged, after breakpoint.
2469 Execute till the end of the current function.
2473 Delete breakpoint number 'n'. If used without any option clear ALL
2474 user defined break points.
2476 27.5.6 info [break | stack | frame | registers ]
2478 * info break - list all breakpoints
2480 * info stack - show the function call stack.
2482 * info frame - show information about the current execution frame.
2484 * info registers - show content of all registers.
2488 Step program until it reaches a different source line.
2492 Step program, proceeding through subroutine calls.
2496 Start debugged program.
2498 27.5.10 ptype variable
2500 Print type information of the variable.
2502 27.5.11 print variable
2504 print value of variable.
2506 27.5.12 file filename
2508 load the given file name. Note this is an alternate method of loading
2513 print information about current frame.
2517 Toggle between C source & assembly source.
2519 27.5.15 ! simulator command
2521 Send the string following '!' to the simulator, the simulator response
2522 is displayed. Note the debugger does not interpret the command being
2523 sent to the simulator, so if a command like 'go' is sent the debugger
2524 can loose its execution context and may display incorrect values.
2528 "Watch me now. Iam going Down. My name is Bobby Brown"
2530 27.6 Interfacing with XEmacs.
2532 Two files are (in emacs lisp) are provided for the interfacing with
2533 XEmacs, sdcdb.el and sdcdbsrc.el. These two files can be found in
2534 the $(prefix)/bin directory after the installation is complete. These
2535 files need to be loaded into XEmacs for the interface to work, this
2536 can be done at XEmacs startup time by inserting the following into
2537 your '.xemacs' file (which can be found in your HOME directory) (load-file
2538 sdcdbsrc.el) [ .xemacs is a lisp file so the () around the command
2539 is REQUIRED), the files can also be loaded dynamically while XEmacs
2540 is running, set the environment variable 'EMACSLOADPATH' to the installation
2541 bin directory [$(prefix)/bin], then enter the following command ESC-x
2542 load-file sdcdbsrc . To start the interface enter the following command
2543 ESC-x sdcdbsrc , you will prompted to enter the file name to be debugged.
2545 The command line options that are passed to the simulator directly
2546 are bound to default values in the file sdcdbsrc.el the variables
2547 are listed below these values maybe changed as required.
2549 * sdcdbsrc-cpu-type '51
2551 * sdcdbsrc-frequency '11059200
2553 * sdcdbsrc-serial nil
2555 The following is a list of key mapping for the debugger interface.
2558 ;; Current Listing ::
2559 ;;key binding Comment
2560 ;;--- ------- -------
2562 ;; n sdcdb-next-from-src SDCDB next command
2563 ;; b sdcdb-back-from-src SDCDB back command
2564 ;; c sdcdb-cont-from-src SDCDB continue command
2565 ;; s sdcdb-step-from-src SDCDB step command
2566 ;; ? sdcdb-whatis-c-sexp SDCDB ptypecommand for data at
2568 ;; x sdcdbsrc-delete SDCDB Delete all breakpoints if no arg
2569 ;; given or delete arg (C-u arg x)
2570 ;; m sdcdbsrc-frame SDCDB Display current frame if no arg,
2571 ;; given or display frame arg
2573 ;; ! sdcdbsrc-goto-sdcdb Goto the SDCDB output buffer
2574 ;; p sdcdb-print-c-sexp SDCDB print command for data at
2576 ;; g sdcdbsrc-goto-sdcdb Goto the SDCDB output buffer
2577 ;; t sdcdbsrc-mode Toggles Sdcdbsrc mode (turns it off)
2579 ;; C-c C-f sdcdb-finish-from-src SDCDB finish command
2581 ;; C-x SPC sdcdb-break Set break for line with point
2582 ;; ESC t sdcdbsrc-mode Toggle Sdcdbsrc mode
2583 ;; ESC m sdcdbsrc-srcmode Toggle list mode
2587 28 Conclusion\label{Conclusion}
2589 SDCC is a large project , the compiler alone (without the Assembler
2590 Package , Preprocessor & garbage collector) is about 40,000 lines
2591 of code (blank stripped). As with any project of this size there are
2592 bound to be bugs, I am more than willing to work to fix these bugs
2593 , of course all the source code is included with the package.
2595 Where does it go from here ? I am planning to target the Atmel AVR
2596 8-bit MCUs which seems to have a lot of users. I am also planning
2597 to include an alias analysis system with this compiler (it does not
2598 currently have one).
2600 29 Acknowledgments\label{Acknowledgements}
2602 Alan Baldwin (baldwin@shop-pdp.kent.edu) - Initial version of ASXXXX
2605 John Hartman (jhartman@compuserve.com) - Porting ASXXX & ASLINK for
2608 Dmitry S. Obukhov (dso@usa.net) - malloc & serial i/o routines.
2610 Daniel Drotos <drdani@mazsola.iit.uni-miskolc.hu> - for his Freeware
2613 Jans J Boehm(boehm@sgi.com) and Alan J Demers - Conservative garbage
2614 collector for C & C++.
2616 Malini Dutta(malini@mediaone.net) - my wife for her patience and support.
2618 Unknown - for the GNU C - preprocessor.