-SDCC Compiler User Guide
+lSDCC Compiler User Guide
Table of Contents
1 Introduction
1.1 About SDCC
1.2 Open Source
- 1.3 System Requirements
- 1.4 Other Resources
+ 1.3 Typographic conventions
+ 1.4 Pending: compatibilaty with previous versions
+ 1.5 System Requirements
+ 1.6 Other Resources
2 Installation
2.1 Linux/Unix Installation
2.2 Windows Installation
2.6 SDCC on Other Platforms
2.7 Advanced Install Options
2.8 Components of SDCC
- 2.8.1 cpp ( C-Preprocessor)
- 2.8.2 asxxxx & aslink ( The assembler and Linkage Editor)
- 2.8.3 SDCC - The compiler
- 2.8.4 S51 - Simulator
- 2.8.5 SDCDB - Source Level Debugger
+ 2.8.1 sdcc - The Compiler
+ 2.8.2 sdcpp (C-Preprocessor)
+ 2.8.3 asx8051, as-z80, as-gbz80, aslink, link-z80, link-gbz80 (The Assemblers and Linkage Editors)
+ 2.8.4 s51 - Simulator
+ 2.8.5 sdcdb - Source Level Debugger
3 Using SDCC
3.1 Compiling
3.1.1 Single Source File Projects
3.2.2 Preprocessor Options
3.2.3 Linker Options
3.2.4 MCS51 Options
- 3.2.5 Optimization Options
- 3.2.6 DS390 Options
+ 3.2.5 DS390 Options
+ 3.2.6 Optimization Options
3.2.7 Other Options
3.2.8 Intermediate Dump Options
3.3 MCS51/DS390 Storage Class Language Extensions
3.11 Absolute Addressing
3.12 Startup Code
3.13 Inline Assembler Code
- 3.14 int(16 bit) and long (32 bit ) Support
+ 3.14 int(16 bit) and long (32 bit) Support
3.15 Floating Point Support
3.16 MCS51 Memory Models
- 3.17 Flat 24 bit Addressing Model
+ 3.17 DS390 Memory Models
3.18 Defines Created by the Compiler
4 SDCC Technical Data
4.1 Optimizations
4.1.2 Dead-Code Elimination
4.1.3 Copy-Propagation
4.1.4 Loop Optimizations
- 4.1.5 Loop Reversing:
+ 4.1.5 Loop Reversing
4.1.6 Algebraic Simplifications
4.1.7 'switch' Statements
4.1.8 Bit-shifting Operations.
1.1 About SDCC
+<pending: tabularise these features, this is unreadeble>
+
SDCC is a Free ware, retargettable, optimizing ANSI-C compiler
by Sandeep Dutta designed for 8 bit Microprocessors. The
current version targets Intel MCS51 based Microprocessors(8051,8052,
which should be well suited for other 8 bit MCUs. The peep
hole optimizer uses a rule based substitution mechanism
which is MCU dependent. Supported data-types are char (8
-bits, 1 byte), short and int (16 bits, 2 bytes ), long (32
+bits, 1 byte), short and int (16 bits, 2 bytes), long (32
bit, 4 bytes) and float (4 byte IEEE). The compiler also
allows inline assembler code to be embedded anywhere in
a function. In addition routines developed in assembly can
SDCC also comes with a companion source level debugger SDCDB,
the debugger currently uses ucSim a freeware simulator for
8051 and other micro-controllers. The latest version can
-be downloaded from [http://sdcc.sourceforge.net/].
+be downloaded from [http://sdcc.sourceforge.net/] .
1.2 Open Source
-All packages used in this compiler system are opensource(freeware);
-source code for all the sub-packages (asxxxx assembler/linker,
-pre-processor) are distributed with the package. This documentation
-is maintained using a freeware word processor (LyX).
+All packages used in this compiler system are opensource
+and freeware; source code for all the sub-packages (asxxxx
+assembler/linker, pre-processor) is distributed with the
+package. This documentation is maintained using a freeware
+word processor (LyX).
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
use, share and improve what you give them. Help stamp out
software-hoarding!
-1.3 System Requirements
+<pending: add a link to gnu>
+
+1.3 Typographic conventions
+
+Throughout this manual, we will use the following convention.
+Commands you have to type in are printed in "sans serif".
+Code samples are printed in typewriter font. Interesting
+items and new terms are printed in italicised type.
+
+1.4 Pending: compatibilaty with previous versions
+
+This version has numerous bug fixes comperated with the previous
+version. But we also introduced some incompatibilaties with
+older versions. Not just for the fun of it, but to make
+the compiler more stable, efficient and ANSI compliant.
+
+
+short char
+directory structure (2.7)
+vararg pars expl int unless casted
+never had a regextend
+no --noreparms anymore
+
+more?
+
+1.5 System Requirements
What do you need before you start installation of SDCC? A
computer, and a desire to compute. The preferred method
are available for your convenience. You should have some
experience with command line tools and compiler use.
-1.4 Other Resources
+1.6 Other Resources
The SDCC home page at [http://sdcc.sourceforge.net/]
is a great place to find distribution sets. You can also
assembler) included with SDCC contain their own documentation
and can be found in the source distribution. If you want
the latest unreleased software, the complete source package
-is available directly by anonymous CVS on www.sourceforge.net.
+is available directly by anonymous CVS on cvs.sdcc.sourceforge.net.
2 Installation
2. Bring up a command line terminal, such as xterm.
-3. Unpack the file using a command like: tar -xzf sdcc-2.x.x.tgz,
+3. Unpack the file using a command like: "tar -xzf sdcc-2.x.x.tgz",
this will create a sub-directory called sdcc with all
of the sources.
4. Change directory into the main SDCC directory, for example
type: "cd sdcc".
-5. Type "./configure". This configures
- the package for compilation on your system.
+5. Type "./configure". This configures the package for compilation
+ on your system.
-6. Type "make". All of the source packages
- will compile, this can take a while.
+6. Type "make". All of the source packages will compile, this
+ can take a while.
-7. Type "make install" as root.
- This copies the binary executables to the install directories.
+7. Type "make install" as root. This copies the binary executables
+ to the install directories.
2.2 Windows Installation
+<pending: is this complete? where is borland, mingw>
+
For installation under Windows you first need to pick between
a pre-compiled binary package, or installing the source
package along with the Cygwin package. The binary package
2.2.1 Windows Install Using a Binary Package
1. Download the binary package and unpack it using your favorite
- unpacking tool(gunzip, WinZip, etc). This should unpack
+ unpacking tool (gunzip, WinZip, etc). This should unpack
to a group of sub-directories. An example directory structure
after unpacking is: c:\usr\local\bin for the executables,
c:\usr\local\share\sdcc\include and c:\usr\local\share\sdcc\lib
site[http://sources.redhat.com/cygwin/]. Currently,
this involved downloading a small install program which
then automates downloading and installing selected parts
- of the package(a large 80M byte sized dowload for the
+ of the package (a large 80M byte sized dowload for the
whole thing).
2. Bring up a Unix/Bash command line terminal from the Cygwin
2.3 Testing out the SDCC Compiler
The first thing you should do after installing your SDCC
-compiler is to see if it runs. Type "sdcc
---version" at the prompt, and the program should
-run and tell you the version. If it doesn't run, or gives
-a message about not finding sdcc program, then you need
-to check over your installation. Make sure that the sdcc
-bin directory is in your executable search path defined
-by the PATH environment setting (see the Trouble-shooting
-section for suggestions). Make sure that the sdcc program
-is in the bin folder, if not perhaps something did not install
-correctly.
+compiler is to see if it runs. Type "sdcc --version" at
+the prompt, and the program should run and tell you the
+version. If it doesn't run, or gives a message about not
+finding sdcc program, then you need to check over your installation.
+Make sure that the sdcc bin directory is in your executable
+search path defined by the PATH environment setting (see
+the Trouble-shooting section for suggestions). Make sure
+that the sdcc program is in the bin folder, if not perhaps
+something did not install correctly.
SDCC binaries are commonly installed in a directory arrangement
like this:
Make sure the compiler works on a very simple example. Type
in the following test.c program using your favorite editor:
-main()
-{
-
-int i;
-
-i = 0;
-
-i += 10;
-}
-
-
-Compile this using the following command: "sdcc
--c test.c". If all goes well, the compiler will
-generate a test.asm and test.rel file. Congratulations,
-you've just compiled your first program with SDCC. We used
-the -c option to tell SDCC not to link the generated code,
-just to keep things simple for this step.
+Compile this using the following command: "sdcc -c test.c"
+If all goes well, the compiler will generate a test.asm
+and test.rel file. Congratulations, you've just compiled
+your first program with SDCC. We used the -c option to tell
+SDCC not to link the generated code, just to keep things
+simple for this step.
The next step is to try it with the linker. Type in "sdcc
-test.c". If all goes well the compiler will link with
-the libraries and produce a test.ihx output file. If this
-step fails (no test.ihx, and the linker generates warnings),
+test.c". If all goes well the compiler will link with the
+libraries and produce a test.ihx output file. If this step
+fails (no test.ihx, and the linker generates warnings),
then the problem is most likely that sdcc cannot find the
/usr/local/share/sdcc/lib directory (see the Install trouble-shooting
section for suggestions).
files and libraries. Edit test.c and change it to the following:
#include <string.h>
-main()
-{
-
+main() {
char str1[10];
-
-strcpy(str1, "testing");
-
+ strcpy(str1, "testing");
}
-
-Compile this by typing: "sdcc test.c".
-This should generate a test.ihx output file, and it should
-give no warnings such as not finding the string.h file.
-If it cannot find the string.h file, then the problem is
-that sdcc cannot find the /usr/local/share/sdcc/include
-directory (see the Install trouble-shooting section for
-suggestions).
+Compile this by typing "sdcc test.c". This should generate
+a test.ihx output file, and it should give no warnings such
+as not finding the string.h file. If it cannot find the
+string.h file, then the problem is that sdcc cannot find
+the /usr/local/share/sdcc/include directory (see the Install
+trouble-shooting section for suggestions).
2.4 Install Trouble-shooting
files are located at "/usr/local/share/sdcc/lib"
and "/usr/local/share/sdcc/include".
An alternative is to specify these locations as compiler
-options like this: sdcc -L /usr/local/sdcc/lib/small -I
-/usr/local/sdcc/include test.c
+options like this: "sdcc -L /usr/local/sdcc/lib/small -I /usr/local/sdcc/include test.c".
2.4.2 SDCC does not compile correctly.
.tgz source package again in an empty directory. Confure
it again and build like:
-"make 2&>1 | tee make.log"
+make 2&>1 | tee make.log
After this you can review the make.log file to locate the
problem. Or a relevant part of this be attached to an email
2.5 Additional Information for Windows Users
+<pending: is this up to date?>
+
The standard method of installing on a Unix system involves
compiling the source package. This is easily done under
Unix, but under Windows it can be a more difficult process.
each of these methods.
The Cygwin package allows a Windows user to run a Unix command
-line interface(bash shell) and also implements a Unix like
+line interface (bash shell) and also implements a Unix like
file system on top of Windows. Included are many of the
famous GNU software development tools which can augment
the SDCC compiler.This is great if you have some experience
2.5.1 Getting started with Cygwin
-SDCC is typically distributed as a tarred/gzipped file(.tgz).
+SDCC is typically distributed as a tarred/gzipped file (.tgz).
This is a packed file similar to a .zip file. Cygwin includes
-the tools you will need to unpack the SDCC distribution(tar
-and gzip). To unpack it, simply follow the instructions
+the tools you will need to unpack the SDCC distribution
+(tar and gzip). To unpack it, simply follow the instructions
under the Linux/Unix install section. Before you do this
you need to learn how to start a cygwin shell and some of
the basic commands used to move files, change directory,
If you use the pre-compiled binaries, the install directories
for the libraries and header files may need to be specified
-on the sdcc command line like this: sdcc -L c:\usr\local\sdcc\lib\small
--I c:\usr\local\sdcc\include test.c if you are running outside
+on the sdcc command line like this: "sdcc -L c:\usr\local\sdcc\lib\small
+-I c:\usr\local\sdcc\include test.c" if you are running outside
of a Unix bash shell.
If you have successfully installed and compiled SDCC with
the Cygwin package, it is possible to compile into native
.exe files by using the additional makefiles included for
this purpose. For example, with the Borland 32-bit compiler
-you would run make -f Makefile.bcc. A command line version
+you would run "make -f Makefile.bcc". A command line version
of the Borland 32-bit compiler can be downloaded from the
Inprise web site.
where <directory name> is the final location for the sdcc
executables and libraries, (default location is /usr/local).
The installation process will create the following directory
-structure under the <directory name> specified.
+structure under the <directory name> specified (if they
+do not already exist).
bin/ - binary exectables (add to PATH environment variable)
-
- share/
- sdcc/include/ - include
-header files
- sdcc/lib/ -
- small/
-- Object & library files for small model library
- large/
-- Object & library files for large model library
- ds390/
-- Object & library files forDS80C390 library
-
-The command
-
-'./configure --prefix=/usr/local"
-
+bin/share/
+bin/share/sdcc/include/ - include header files
+bin/share/sdcc/lib/
+bin/share/sdcc/lib/small/ - Object & library files for small
+model library
+bin/share/sdcc/lib/large/ - Object & library files for large
+model library
+bin/share/sdcc/lib/ds390/ - Object & library files forDS80C390
+library
+
+The command "./configure --prefix=/usr/local"
will configure the compiler to be installed in directory
/usr/local/bin.
installed in the bin directory. At the time of this writing,
we find the following programs:
-sdcc - The compiler.
-
-aslink -The linker for 8051 type processors.
-
-asx8051 - The assembler for 8051 type processors.
+<pending: tabularize this>
+sdcc - The compiler.
sdcpp - The C preprocessor.
-
-sdcpd - The source debugger.
-
-s51 - The ucSim 8051 simulator.
-
-linkz80, linkgbz80 - The Z80 and GameBoy Z80 linkers.
-
+asx8051 - The assembler for 8051 type processors.
as-z80, as-gbz80 - The Z80 and GameBoy Z80 assemblers.
-
+aslink -The linker for 8051 type processors.
+link-z80, link-gbz80 - The Z80 and GameBoy Z80 linkers.
+s51 - The ucSim 8051 simulator.
+sdcdb - The source debugger.
packihx - A tool to pack Intel hex files.
As development for other processors proceeds, this list will
expand to include executables to support processors like
AVR, PIC, etc.
-2.8.1 cpp ( C-Preprocessor)
+2.8.1 sdcc - The Compiler
-The preprocessor is extracted into the directory SDCCDIR/cpp,
-it is a modified version of the GNU preprocessor. The C
-preprocessor is used to pull in #include sources, process
-#ifdef statements, #defines and so on.
+This is the actual compiler, it in turn uses the c-preprocessor
+and invokes the assembler and linkage editor.
-2.8.2 asxxxx & aslink ( The assembler and Linkage Editor)
+2.8.2 sdcpp (C-Preprocessor)
-This is retargettable assembler & linkage editor, it was
-developed by Alan Baldwin, John Hartman created the version
-for 8051, and I (Sandeep) have some enhancements and bug
-fixes for it to work properly with the SDCC. This component
-is extracted into the directory SDCCDIR/asxxxx.
+The preprocessor is a modified version of the GNU preprocessor.
+The C preprocessor is used to pull in #include sources,
+process #ifdef statements, #defines and so on.
-2.8.3 SDCC - The compiler
+2.8.3 asx8051, as-z80, as-gbz80, aslink, link-z80, link-gbz80
+ (The Assemblers and Linkage Editors)
-This is the actual compiler, it in turn uses the c-preprocessor
-and invokes the assembler and linkage editors. All files
-with the prefix SDCC are part of the compiler and are extracted
-into the the directory SDCCDIR.
+This is retargettable assembler & linkage editor, it was
+developed by Alan Baldwin. John Hartman created the version
+for 8051, and I (Sandeep) have made some enhancements and
+bug fixes for it to work properly with the SDCC.
-2.8.4 S51 - Simulator
+2.8.4 s51 - Simulator
-s51 is a freeware, opensource simulator developed by Daniel
-Drotos <drdani@mazsola.iit.uni-miskolc.hu>. The executable
-is built as part of the build process, for more information
-visit Daniel's website at <http://mazsola.iit.uni-miskolc.hu/~drdani/embedded/s51/>.
+S51 is a freeware, opensource simulator developed by Daniel
+Drotos ([mailto:drdani@mazsola.iit.uni-miskolc.hu]).
+The simulator is built as part of the build process. For
+more information visit Daniel's website at: [http://mazsola.iit.uni-miskolc.hu/~drdani/embedded/s51] .
-2.8.5 SDCDB - Source Level Debugger
+2.8.5 sdcdb - Source Level Debugger
-SDCDB is the companion source level debugger. The current
+Sdcdb is the companion source level debugger. The current
version of the debugger uses Daniel's Simulator S51, but
can be easily changed to use other simulators.
For single source file 8051 projects the process is very
simple. Compile your programs with the following command
+"sdcc sourcefile.c". This will compile, assemble and link
+your source file. Output files are as follows
+
+sourcefile.asm - Assembler source file created by the compiler
+sourcefile.lst - Assembler listing file created by the Assembler
+sourcefile.rst - Assembler listing file updated with linkedit
+information, created by linkage editor
+sourcefile.sym - symbol listing for the sourcefile, created
+by the assembler
+sourcefile.rel - Object file created by the assembler, input
+to Linkage editor
+sourcefile.map - The memory map for the load module, created
+by the Linker
+sourcefile.ihx - The load module in Intel hex format (you
+can select the Motorola S19 format with --out-fmt-s19)
+sourcefile.cdb - An optional file (with --debug) containing
+debug information
-sdcc sourcefile.c
-
-The above command will compile ,assemble and link your source
-file. Output files are as follows.
-
-* sourcefile.asm - Assembler source file created by the compiler
-
-* sourcefile.lst - Assembler listing file created by the
- Assembler
-
-* sourcefile.rst - Assembler listing file updated with linkedit
- information , created by linkage editor
-
-* sourcefile.sym - symbol listing for the sourcefile, created
- by the assembler.
-
-* sourcefile.rel - Object file created by the assembler,
- input to Linkage editor.
-
-* sourcefile.map - The memory map for the load module, created
- by the Linker.
-
-* sourcefile.ihx - The load module in Intel hex format (you
- can select the Motorola S19 format with --out-fmt-s19)
-
-* sourcefile.cdb - An optional file (with --debug) containing
- debug information.
3.1.2 Projects with Multiple Source Files
SDCC can compile only ONE file at a time. Let us for example
assume that you have a project containing the following
-files.
-
-foo1.c ( contains some functions )
+files:
+foo1.c (contains some functions)
foo2.c (contains some more functions)
-
foomain.c (contains more functions and the function main)
The first two files will need to be compiled separately with
-the commands
+the commands:
sdcc -c foo1.c
-
sdcc -c foo2.c
-Then compile the source file containing main and link the
-other files together with the following command.
+Then compile the source file containing the main() function
+and link the files together with the following command:
+
sdcc foomain.c foo1.rel foo2.rel
-Alternatively foomain.c can be separately compiled as well
+Alternatively, foomain.c can be separately compiled as well:
-sdcc -c foomain.c
+sdcc -c foomain.c
sdcc foomain.rel foo1.rel foo2.rel
-The file containing the main function MUST be the FIRST file
-specified in the command line , since the linkage editor
+The file containing the main() function must be the first
+file specified in the command line, since the linkage editor
processes file in the order they are presented to it.
3.1.3 Projects with Additional Libraries
Some reusable routines may be compiled into a library, see
-the documentation for the assembler and linkage editor in
-the directory SDCCDIR/asxxxx/asxhtm.htm this describes how
-to create a .lib library file, the libraries created in
-this manner may be included using the command line, make
-sure you include the -L <library-path> option to tell the
-linker where to look for these files. Here is an example,
-assuming you have the source file 'foomain.c' and a library
-'foolib.lib' in the directory 'mylib' (if that is not the
-same as your current project).
+the documentation for the assembler and linkage editor (which
+are in <installdir>/share/sdcc/doc) for how to create a
+.lib library file. Libraries created in this manner can
+be included in the command line. Make sure you include the
+-L <library-path> option to tell the linker where to look
+for these files if they are not in the current directory.
+Here is an example, assuming you have the source file foomain.c
+and a library foolib.lib in the directory mylib (if that
+is not the same as your current project):
sdcc foomain.c foolib.lib -L mylib
-Note here that 'mylib' must be an absolute path name.
+Note here that mylib must be an absolute path name.
-The view of the way the linkage editor processes the library
-files, it is recommended that you put each source routine
-in a separate file and combine them using the .lib file.
-For an example see the standard library file 'libsdcc.lib'
-in the directory SDCCDIR/sdcc51lib.
+The most efficient way to use libraries is to keep seperate
+modules in seperate source files. The lib file now should
+name all the modules.rel files. For an example see the standard
+library file libsdcc.lib in the directory <installdir>/share/lib/small.
3.2 Command Line Options
-D<macro[=value]> Command line definition of macros. Passed
to the pre processor.
---compile-only(-c) will compile and assemble the source,
-but will not call the linkage editor.
+-M Tell the preprocessor to output a rule suitable for make
+describing the dependencies of each object file. For each
+source file, the preprocessor outputs one make-rule whose
+target is the object file name for that source file and
+whose dependencies are all the files `#include'd in it.
+This rule may be a single line or may be continued with
+`\'-newline if it is long. The list of rules is printed on
+standard output instead of the preprocessed C program. `-M'
+implies `-E'.
+
+-C Tell the preprocessor not to discard comments. Used with
+the `-E' option.
+
+-MM Like `-M' but the output mentions only the user header
+files included with `#include "file"'.
+System header files included with `#include <file>' are
+omitted.
+
+-Aquestion(answer) Assert the answer answer for question,
+in case it is tested with a preprocessor conditional such
+as `#if #question(answer)'. `-A-' disables the standard
+assertions that normally describe the target machine.
+
+-Aquestion (answer) Assert the answer answer for question,
+in case it is tested with a preprocessor conditional such
+as `#if #question(answer)'. `-A-' disables the standard
+assertions that normally describe the target machine.
+
+-Umacro Undefine macro macro. `-U' options are evaluated
+after all `-D' options, but before any `-include' and `-imacros'
+options.
+
+-dM Tell the preprocessor to output only a list of the macro
+definitions that are in effect at the end of preprocessing.
+Used with the `-E' option.
+
+-dD Tell the preprocessor to pass all macro definitions into
+the output, in their proper sequence in the rest of the
+output.
+
+-dN Like `-dD' except that the macro arguments and contents
+are omitted. Only `#define name' is included in the output.
3.2.3 Linker Options
--
-lib-path(-L) <absolute path to additional libraries> This
+-
L --lib-path <absolute path to additional libraries> This
option is passed to the linkage editor's additional libraries
search path. The path name must be absolute. Additional
library files may be specified in the command line. See
or Decimal format, e.g.: --xram-loc 0x8000 or --xram-loc
32768.
---code-loc<Value> The start location of the code segment
-, default value 0. Note when this option is used the interrupt
+--code-loc<Value> The start location of the code segment,
+default value 0. Note when this option is used the interrupt
vector table is also relocated to the given address. The
value entered can be in Hexadecimal or Decimal format, e.g.:
--code-loc 0x8000 or --code-loc 32768.
be in Hexadecimal or Decimal format, eg. --idata-loc 0x88
or --idata-loc 136.
+--out-fmt-ihx The linker output (final object code) is in
+Intel Hex format. (This is the default option).
+
+--out-fmt-s19 The linker output (final object code) is in
+Motorola S19 format.
+
3.2.4 MCS51 Options
--model-large Generate code for Large model programs see
section Memory Models for more details. If this option is
used all source files in the project should be compiled
with this option. In addition the standard library routines
-are compiled with small model , they will need to be recompiled.
+are compiled with small model, they will need to be recompiled.
--model-small Generate code for Small Model programs see
section Memory Models for more details. This is the default
model.
---stack-auto All functions in the source file will be compiled
-as reentrant, i.e. the parameters and local variables will
-be allocated on the stack. see section Parameters and Local
-Variables for more details. If this option is used all source
-files in the project should be compiled with this option.
+3.2.5 DS390 Options
---xstack Uses a pseudo stack in the first 256 bytes in the
-external ram for allocating variables and passing parameters.
-See section on external stack for more details.
+--model-flat24 Generate 24-bit flat mode code. This is the
+one and only that the ds390 code generator supports right
+now and is default when using -mds390. See section Memory
+Models for more details.
-3.2.5 Optimization Options
+--stack-10bit Generate code for the 10 bit stack mode of
+the Dallas DS80C390 part. This is the one and only that
+the ds390 code generator supports right now and is default
+when using -mds390. In this mode, the stack is located in
+the lower 1K of the internal RAM, which is mapped to 0x400000.
+Note that the support is incomplete, since it still uses
+a single byte as the stack pointer. This means that only
+the lower 256 bytes of the potential 1K stack space will
+actually be used. However, this does allow you to reclaim
+the precious 256 bytes of low RAM for use for the DATA and
+IDATA segments. The compiler will not generate any code
+to put the processor into 10 bit stack mode. It is important
+to ensure that the processor is in this mode before calling
+any re-entrant functions compiled with this option. In principle,
+this should work with the --stack-auto option, but that
+has not been tested. It is incompatible with the --xstack
+option. It also only makes sense if the processor is in
+24 bit contiguous addressing mode (see the --model-flat24
+option).
+
+3.2.6 Optimization Options
--nogcse Will not do global subexpression elimination, this
option may be used when the compiler creates undesirably
large stack/data spaces to store compiler temporaries. A
warning message will be generated when this happens and
the compiler will indicate the number of extra bytes it
-allocated. It recommended that this option NOT be used ,
+allocated. It recommended that this option NOT be used,
#pragma NOGCSE can be used to turn off global subexpression
elimination for a given function only.
may be turned off for reasons explained for the previous
option. For more details of loop optimizations performed
see section Loop Invariants.It recommended that this option
-NOT be used , #pragma NOINVARIANT can be used to turn off
-invariant optimizations for a given function only.
+NOT be used, #pragma NOINVARIANT can
+be used to turn off invariant optimizations for a given
+function only.
--noinduction Will not do loop induction optimizations, see
-section Strength reduction for more details.It recommended
-that this option NOT be used , #pragma NOINDUCTION can be
-used to turn off induction optimizations for given function
-only.
+section strength reduction for more details.It is recommended
+that this option is NOT used, #pragma NOINDUCTION
+can be used to turn off induction optimizations for a given
+function only.
--nojtbound Will not generate boundary condition check when
switch statements are implemented using jump-tables. See
-section Switch Statements for more details.It recommended
-that this option NOT be used , #pragma NOJTBOUND can be
-used to turn off boundary checking for jump tables for a
-given function only.
+section Switch Statements for more details. It is recommended
+that this option is NOT used, #pragma NOJTBOUND
+can be used to turn off boundary checking for jump tables
+for a given function only.
---noloopreverse Will not do loop reversal optimization
+--noloopreverse Will not do loop reversal optimization.
-3.2.6 DS390 Options
+3.2.7 Other Options
---stack-auto See MCS51 section for description.
+-c --compile-only will compile and assemble the source,
+but will not call the linkage editor.
---model-flat24 Generate 24-bit flat mode code. This is the
-one and only that the ds390 code generator supports right
-now and is default when using -mds390. See section Memory
-Models for more details.
+-E Run only the C preprocessor. Preprocess all the C source
+files specified and output the results to standard output.
---stack-10bit This option generates code for the 10 bit stack
-mode of the Dallas DS80C390 part. This is the one and only
-that the ds390 code generator supports right now and is
-default when using -mds390. In this mode, the stack is located
-in the lower 1K of the internal RAM, which is mapped to
-0x400000. Note that the support is incomplete, since it
-still uses a single byte as the stack pointer. This means
-that only the lower 256 bytes of the potential 1K stack
-space will actually be used. However, this does allow you
-to reclaim the precious 256 bytes of low RAM for use for
-the DATA and IDATA segments. The compiler will not generate
-any code to put the processor into 10 bit stack mode. It
-is important to ensure that the processor is in this mode
-before calling any re-entrant functions compiled with this
-option. In principle, this should work with the --stack-auto
-option, but that has not been tested. It is incompatible
-with the --xstack option. It also only makes sense if the
-processor is in 24 bit contiguous addressing mode (see the
---model-flat24 option).
+--stack-auto All functions in the source file will be compiled
+as reentrant, i.e. the parameters and local variables will
+be allocated on the stack. see section Parameters and Local
+Variables for more details. If this option is used all source
+files in the project should be compiled with this option.
-3.2.7 Other Options
+--xstack Uses a pseudo stack in the first 256 bytes in the
+external ram for allocating variables and passing parameters.
+See section on external stack for more details.
--callee-saves function1[,function2][,function3].... The
compiler by default uses a caller saves convention for register
to be recompiled with the same option. If the project consists
of multiple source files then all the source file should
be compiled with the same --callee-saves option string.
-Also see Pragma Directive CALLEE-SAVES.
+Also see #pragma CALLEE-SAVES.
--debug When this option is used the compiler will generate
-debug information , that can be used with the SDCDB. The
+debug information, that can be used with the SDCDB. The
debug information is collected in a file with .cdb extension.
For more information see documentation for SDCDB.
---regextend This option will cause the compiler to define
-pseudo registers , if this option is used, all source files
-in the project should be compiled with this option. See
-section Register Extension for more details.
+--regextend This option is obsolete and isn't supported
+anymore.
+
+--noregparms This option is obsolete and isn't supported
+anymore.
--peep-file<filename> This option can be used to use additional
rules to be used by the peep hole optimizer. See section
Peep Hole optimizations for details on how to write these
rules.
--E Run only the C preprocessor. Preprocess all the C source
-files specified and output the results to standard output.
-
--M Tell the preprocessor to output a rule suitable for make
-describing the dependencies of each object file. For each
-source file, the preprocessor outputs one make-rule whose
-target is the object file name for that source file and
-whose dependencies are all the files `#include'd in it.
-This rule may be a single line or may be continued with
-`\'-newline if it is long. The list of rules is printed on
-standard output instead of the preprocessed C program. `-M'
-implies `-E'.
-
--C Tell the preprocessor not to discard comments. Used with
-the `-E' option.
-
--MM Like `-M' but the output mentions only the user header
-files included with `#include "file"'.
-System header files included with `#include <file>' are
-omitted.
-
--Aquestion(answer) Assert the answer answer for question,
-in case it is tested with a preprocessor conditional such
-as `#if #question(answer)'. `-A-' disables the standard
-assertions that normally describe the target machine.
-
--Aquestion (answer) Assert the answer answer for question,
-in case it is tested with a preprocessor conditional such
-as `#if #question(answer)'. `-A-' disables the standard
-assertions that normally describe the target machine.
-
--Umacro Undefine macro macro. `-U' options are evaluated
-after all `-D' options, but before any `-include' and `-imacros'
-options.
-
--dM Tell the preprocessor to output only a list of the macro
-definitions that are in effect at the end of preprocessing.
-Used with the `-E' option.
-
--dD Tell the preprocessor to pass all macro definitions into
-the output, in their proper sequence in the rest of the
-output.
-
--dN Like `-dD' except that the macro arguments and contents
-are omitted. Only `#define name' is included in the output.
-
-S Stop after the stage of compilation proper; do not assemble.
The output is an assembler code file for the input file
specified.
--float-reent Floating point library is compiled as reentrant.See
section Installation for more details.
---out-fmt-ihx The linker output (final object code) is in
-Intel Hex format. (This is the default option).
-
---out-fmt-s19 The linker output (final object code) is in
-Motorola S19 format.
-
--nooverlay The compiler will not overlay parameters and
local variables of any function, see section Parameters
and local variables for more details.
--iram-size<Value> Causes the linker to check if the interal
ram usage is within limits of the given value.
+--nostdincl This will prevent the compiler from passing on
+the default include path to the preprocessor.
+
+--nostdlib This will prevent the compiler from passing on
+the default library path to the linker.
+
+--verbose Shows the various actions the compiler is performing.
+
+-V Shows the actual commands the compiler is executing.
+
3.2.8 Intermediate Dump Options
The following options are provided for the purpose of retargetting
--dumprange Will create a dump of iCode's, after live range
analysis, into a file named <source filename>.dumprange.
---dumlrange Will dump the life ranges for all symbols
+--dumlrange Will dump the life ranges for all symbols.
--dumpregassign Will create a dump of iCode's, after register
-assignment , into a file named <source filename>.dumprassgn.
+assignment, into a file named <source filename>.dumprassgn.
--dumplrange Will create a dump of the live ranges of iTemp's
3.3.4 bit
This is a data-type and a storage class specifier. When a
-variable is declared as a bit , it is allocated into the
+variable is declared as a bit, it is allocated into the
bit addressable memory of 8051, e.g.:
bit iFlag;
class of pointers which can be used to point to any of the
memory spaces.
-Pointer declaration examples.
+Pointer declaration examples:
/* pointer physically in xternal ram pointing to object in
internal ram */
xdata space */
char * xdata p;
-Well you get the idea. For compatibility with the previous
-version of the compiler, the following syntax for pointer
-declaration is still supported but will disappear int the
-near future.
+Well you get the idea.
+
+For compatibility with the previous version of the compiler,
+the following syntax for pointer declaration is still supported
+but will disappear int the near future.
unsigned char _xdata *ucxdp; /* pointer to data in external
ram */
pointer to upper 128 bytes of ram */
All unqualified pointers are treated as 3-byte (4-byte for
-the ds390) '_generic' pointers. These type of pointers can
+the ds390) generic pointers. These type of pointers can
also to be explicitly declared.
unsigned char _generic *ucgp;
The highest order byte of the generic pointers contains the
data space information. Assembler support routines are called
-whenever data is stored or retrieved using _generic pointers.
+whenever data is stored or retrieved using generic pointers.
These are useful for developing reusable library routines.
Explicitly specifying the pointer type will generate the
most efficient code. Pointers declared using a mixture of
-OLD/NEW style could have unpredictable results.
+OLD and NEW style could have unpredictable results.
3.5 Parameters & Local Variables
Automatic (local) variables and parameters to functions can
either be placed on the stack or in data-space. The default
action of the compiler is to place these variables in the
-internal RAM ( for small model) or external RAM (for Large
-model). They can be placed on the stack either by using
-the --stack-auto compiler option or by using the 'reentrant'
-keyword in the function declaration, e.g.:
+internal RAM (for small model) or external RAM (for Large
+model). This in fact makes them static so by default functions
+are non-reentrant.
-unsigned char foo( char i) reentrant
+They can be placed on the stack either by using the --stack-auto
+compiler option or by using the reentrant keyword in the
+function declaration, e.g.:
+
+unsigned char foo(char i) reentrant
{
...
}
-Note that when the parameters & local variables are declared
-in the internal/external ram the functions are non-reentrant.
-Since stack space on 8051 is limited the 'reentrant' keyword
+Since stack space on 8051 is limited, the reentrant keyword
or the --stack-auto option should be used sparingly. Note
-the reentrant keyword just means that the parameters & local
-variables will be allocated to the stack, it DOES NOT mean
-that the function is register bank independent.
+that the reentrant keyword just means that the parameters
+& local variables will be allocated to the stack, it does
+not mean that the function is register bank independent.
-When compiled with the default option (i.e. non-reentrant
-), local variables can be assigned storage classes and absolute
-addresses, e.g.: (jwk: pending: this is obsolete and need
-a rewrite)
+Local variables can be assigned storage classes and absolute
+addresses, e.g.:
unsigned char foo() {
-
-xdata unsigned char i;
-
-bit bvar;
-
-data at 0x31 unsiged char j;
-
-...
+ xdata unsigned char i;
+ bit bvar;
+ data at 0x31 unsiged char j;
+ ...
}
In the above example the variable i will be allocated in
the external ram, bvar in bit addressable space and j in
-internal ram. When compiled with the --stack-auto or when
-a function is declared as 'reentrant' local variables cannot
-be assigned storage classes or absolute addresses.
+internal ram. When compiled with --stack-auto or when a
+function is declared as reentrant this can only be done
+for static variables.
Parameters however are not allowed any storage class, (storage
classes for parameters will be ignored), their allocation
-is governed by the memory model in use , and the reentrancy
+is governed by the memory model in use, and the reentrancy
options.
3.6 Overlaying
of a function will be allocated to an overlayable segment
if the function has no other function calls and the function
is non-reentrant and the memory model is small. If an explicit
-storage class is specified for a local variable , it will
-NOT be overplayed.
+storage class is specified for a local variable, it will
+NOT be overlayed.
Note that the compiler (not the linkage editor) makes the
decision for overlaying the data items. Functions that are
called from an interrupt service routine should be preceded
-by a #pragma NOOVERLAY if they are not reentrant Along the
-same lines the compiler does not do any processing with
-the inline assembler code so the compiler might incorrectly
+by a #pragma NOOVERLAY if they are not reentrant.
+
+Also note that the compiler does not do any processing of
+inline assembler code, so the compiler might incorrectly
assign local variables and parameters of a function into
-the overlay segment if the only function call from a function
-is from inline assembler code, it is safe to use the #pragma
-NOOVERLAY for functions which call other functions using
-inline assembler code.
+the overlay segment if the inline assembler code calls other
+c-functions that might use the overlay. In that case the
+#pragma NOOVERLAY should be used.
Parameters and Local variables of functions that contain
16 or 32 bit multiplication or division will NOT be overlayed
#pragma SAVE
#pragma NOOVERLAY
-void set_error( unsigned char errcd)
+void set_error(unsigned char errcd)
{
-
-P3 = errcd;
+ P3 = errcd;
}
#pragma RESTORE
+
void some_isr () interrupt 2 using 1
{
-
-...
-
-set_error(10);
-
-...
+ ...
+ set_error(10);
+ ...
}
In the above example the parameter errcd for the function
-set_error would be assigned to the overlayable segment (if
-the #pragma NOOVERLAY was not present) , this could cause
-unpredictable runtime behavior when called from an ISR.
-The pragma NOOVERLAY ensures that the parameters and local
-variables for the function are NOT overlayed.
+set_error would be assigned to the overlayable segment if
+the #pragma NOOVERLAY was not present, this could
+cause unpredictable runtime behavior when called from an
+ISR. The #pragma NOOVERLAY ensures that
+the parameters and local variables for the function are
+NOT overlayed.
3.7 Interrupt Service Routines
..
}
-The number following the 'interrupt' keyword is the interrupt
+The number following the interrupt keyword is the interrupt
number this routine will service. The compiler will insert
a call to this routine in the interrupt vector table for
-the interrupt number specified. The 'using' keyword is used
+the interrupt number specified. The using keyword is used
to tell the compiler to use the specified register bank
(8051 specific) when generating code for this function.
Note that when some function is called from an interrupt
service routine it should be preceded by a #pragma NOOVERLAY
-(if it is not reentrant). A special note here, int (16 bit)
+if it is not reentrant. A special note here, int (16 bit)
and long (32 bit) integer division, multiplication & modulus
operations are implemented using external support routines
developed in ANSI-C, if an interrupt service routine needs
to do any of these operations then the support routines
-(as mentioned in a following section) will have to recompiled
+(as mentioned in a following section) will have to be recompiled
using the --stack-auto option and the source file will need
to be compiled using the --int-long-rent compiler option.
If you have multiple source files in your project, interrupt
service routines can be present in any of them, but a prototype
-of the isr MUST be present in the file that contains the
-function 'main'.
+of the isr MUST be present or included in the file that
+contains the function main.
Interrupt Numbers and the corresponding address & descriptions
for the Standard 8051 are listed below. SDCC will automatically
+--------------+--------------+----------------+
-
-If the interrupt service routine is defined without 'using'
+If the interrupt service routine is defined without using
a register bank or with register bank 0 (using 0), the compiler
-will save the registers used by itself on the stack (upon
-entry and restore them at exit), however if such an interrupt
+will save the registers used by itself on the stack upon
+entry and restore them at exit, however if such an interrupt
service routine calls another function then the entire register
bank will be saved on the stack. This scheme may be advantageous
for small interrupt service routines which have low register
usage.
If the interrupt service routine is defined to be using a
-specific register bank then only "a","b"
-& "dptr" are save and restored, if such an interrupt
-service routine calls another function (using another register
-bank) then the entire register bank of the called function
-will be saved on the stack. This scheme is recommended for
-larger interrupt service routines.
+specific register bank then only a, b & dptr are save and
+restored, if such an interrupt service routine calls another
+function (using another register bank) then the entire register
+bank of the called function will be saved on the stack.
+This scheme is recommended for larger interrupt service
+routines.
Calling other functions from an interrupt service routine
-is not recommended avoid it if possible.
+is not recommended, avoid it if possible.
+
+Also see the _naked modifier.
3.8 Critical Functions
A special keyword may be associated with a function declaring
-it as 'critical'. SDCC will generate code to disable all
-interrupts upon entry to a critical function and enable
-them back before returning. Note that nesting critical functions
-may cause unpredictable results.
-
-eg:
+it as critical. SDCC will generate code to disable all interrupts
+upon entry to a critical function and enable them back before
+returning. Note that nesting critical functions may cause
+unpredictable results.
int foo () critical
{
3.9 Naked Functions
A special keyword may be associated with a function declaring
-it as '_naked'. The '_naked' function modifier attribute
-prevents the compiler from generating prologue and epilogue
-code for that function. This means that the user is entirely
+it as _naked. The _naked function modifier attribute prevents
+the compiler from generating prologue and epilogue code
+for that function. This means that the user is entirely
responsible for such things as saving any registers that
may need to be preserved, selecting the proper register
-bank, generating the 'return' instruction at the end, etc.
+bank, generating the return instruction at the end, etc.
Practically, this means that the contents of the function
must be written in inline assembler. This is particularly
useful for interrupt functions, which can have a large (and
the code generated by these two functions:
data unsigned char counter;
-void simpleIterrupt(void) interrupt 1
+void simpleInterrupt(void) interrupt 1
{
-
-counter++;
+ counter++;
}
void nakedInterrupt(void) interrupt 2 _naked
{
-
-_asm
-
- inc _counter
-
- reti
-; MUST explicitly include ret in _naked function.
-
-_endasm;
+ _asm
+ inc _counter
+ reti ;
+MUST explicitly include ret in _naked function.
+ _endasm;
}
For an 8051 target, the generated simpleInterrupt looks like:
_simpleIterrupt:
-
-push acc
-
-push b
-
-push dpl
-
-push dph
-
-push psw
-
-mov psw,#0x00
-
-inc _counter
-
-pop psw
-
-pop dph
-
-pop dpl
-
-pop b
-
-pop acc
-
-reti
+ push acc
+ push b
+ push dpl
+ push dph
+ push psw
+ mov psw,#0x00
+ inc _counter
+ pop psw
+ pop dph
+ pop dpl
+ pop b
+ pop acc
+ reti
whereas nakedInterrupt looks like:
_nakedInterrupt:
-
-inc _counter
-
-reti
-; MUST explicitly include ret(i) in _naked function.
+ inc _counter
+ reti ; MUST explicitly
+include ret(i) in _naked function.
While there is nothing preventing you from writing C code
inside a _naked function, there are many ways to shoot yourself
3.10 Functions using private banks
-The 'using' attribute (which tells the compiler to use a
-register bank other than the default bank zero) should only
-be applied to 'interrupt' functions (see note A below).
-This will in most circumstances make the generated ISR code
-more efficient since it will not have to save registers
-on the stack.
+The using attribute (which tells the compiler to use a register
+bank other than the default bank zero) should only be applied
+to interrupt functions (see note 1 below). This will in
+most circumstances make the generated ISR code more efficient
+since it will not have to save registers on the stack.
-The 'using' attribute will have no effect on the generated
-code for a non-'interrupt' function (but may occasionally
+The using attribute will have no effect on the generated
+code for a non-interrupt function (but may occasionally
be useful anyway([footnote] possible exception: if a function is called ONLY
from 'interrupt' functions using a particular bank, it can
be declared with the same 'using' attribute as the calling
1', since this would prevent the ISR from having to save
bank zero to the stack on entry and switch to bank zero
before calling the function) ).
-(jwk: todo: I don't think this has been done yet)
-
-An 'interrupt' function using a non-zero bank will assume
-that it can trash that register bank, and will not save
-it. Since high-priority interrupts can interrupt low-priority
-ones on the 8051 and friends, this means that if a high-priority
-ISR 'using' a particular bank occurs while processing a
-low-priority ISR 'using' the same bank, terrible and bad
-things can happen. To prevent this, no single register bank
-should be 'used' by both a high priority and a low priority
-ISR. This is probably most easily done by having all high
-priority ISRs use one bank and all low priority ISRs use
-another. If you have an ISR which can change priority at
-runtime, you're on your own: I suggest using the default
-bank zero and taking the small performance hit.
+(pending: I don't think this has been done yet)
+
+An interrupt function using a non-zero bank will assume that
+it can trash that register bank, and will not save it. Since
+high-priority interrupts can interrupt low-priority ones
+on the 8051 and friends, this means that if a high-priority
+ISR using a particular bank occurs while processing a low-priority
+ISR using the same bank, terrible and bad things can happen.
+To prevent this, no single register bank should be used
+by both a high priority and a low priority ISR. This is
+probably most easily done by having all high priority ISRs
+use one bank and all low priority ISRs use another. If you
+have an ISR which can change priority at runtime, you're
+on your own: I suggest using the default bank zero and taking
+the small performance hit.
It is most efficient if your ISR calls no other functions.
If your ISR must call other functions, it is most efficient
if those functions use the same bank as the ISR (see note
-A below); the next best is if the called functions use bank
+1 below); the next best is if the called functions use bank
zero. It is very inefficient to call a function using a
different, non-zero bank from an ISR.
3.11 Absolute Addressing
Data items can be assigned an absolute address with the at
-<address> keyword, in addition to a storage class.
-
-eg.
+<address> keyword, in addition to a storage class, e.g.:
xdata at 0x8000 unsigned char PORTA_8255 ;
In the above example the PORTA_8255 will be allocated to
-the location 0x8000 of the external ram.
-
-Note that is this feature is provided to give the programmer
-access to memory mapped devices attached to the controller.
-The compiler does not actually reserve any space for variables
-declared in this way (they are implemented with an equate
-in the assembler), thus it is left to the programmer to
-make sure there are no overlaps with other variables that
-are declared without the absolute address, the assembler
-listing file (.lst) and the linker output files (<filename>.rst)
-and (<filename>.map) are a good places to look for such
-overlaps.
+the location 0x8000 of the external ram. Note that this
+feature is provided to give the programmer access to memory
+mapped devices attached to the controller. The compiler
+does not actually reserve any space for variables declared
+in this way (they are implemented with an equate in the
+assembler). Thus it is left to the programmer to make sure
+there are no overlaps with other variables that are declared
+without the absolute address. The assembler listing file
+(.lst) and the linker output files (.rst) and (.map) are
+a good places to look for such overlaps.
Absolute address can be specified for variables in all storage
-classes.
-
-eg.
+classes, e.g.:
bit at 0x02 bvar;
The above example will allocate the variable at offset 0x02
in the bit-addressable space. There is no real advantage
-to assigning absolute addresses to variables in this manner
-, unless you want strict control over all the variables
-allocated.
+to assigning absolute addresses to variables in this manner,
+unless you want strict control over all the variables allocated.
3.12 Startup Code
-The compiler inserts a jump to the C routine _sdcc__external__startup()
-at the start of the CODE area. This routine can be found
-in the file SDCCDIR/sdcc51lib/_startup.c, by default this
-routine returns 0, if this routine returns a non-zero value
-, the static & global variable initialization will be skipped
-and the function main will be invoked, other wise static
-& global variables will be initialized before the function
-main is invoked. You could add a _sdcc__external__startup()
-routine to your program to override the default if you needed
+The compiler inserts a call to the C routine _sdcc__external__startup()
+at the start of the CODE area. This routine is in the runtime
+library. By default this routine returns 0, if this routine
+returns a non-zero value, the static & global variable initialization
+will be skipped and the function main will be invoked Other
+wise static & global variables will be initialized before
+the function main is invoked. You could add a _sdcc__external__startup()
+routine to your program to override the default if you need
to setup hardware or perform some other critical operation
prior to static & global variable initialization.
SDCC allows the use of in-line assembler with a few restriction
as regards labels. All labels defined within inline assembler
-code HAS TO BE of the form nnnnn$ where nnnn is a number
+code has to be of the form nnnnn$ where nnnn is a number
less than 100 (which implies a limit of utmost 100 inline
assembler labels per function). It is strongly recommended
that each assembly instruction (including labels) be placed
-in a separate line ( as the example shows). When the --peep-asm
+in a separate line (as the example shows). When the --peep-asm
command line option is used, the inline assembler code will
-be passed through the peephole optimizer, this might cause
-some unexpected changes in the inline assembler code, please
+be passed through the peephole optimizer. This might cause
+some unexpected changes in the inline assembler code. Please
go throught the peephole optimizer rules defined in file
-'SDCCpeeph.def' carefully before using this option.
-
-eg
+SDCCpeeph.def carefully before using this option.
_asm
- mov b,#10
+ mov b,#10
+
00001$:
- djnz b,00001$
+ djnz b,00001$
+
_endasm ;
The inline assembler code can contain any valid code understood
-by the assembler (this includes any assembler directives
-and comment lines). The compiler does not do any validation
+by the assembler, this includes any assembler directives
+and comment lines. The compiler does not do any validation
of the code within the _asm ... _endasm; keyword pair.
-Inline assembler code cannot reference any C-Labels however
-it can reference labels defined by the inline assembler.
-
-eg
+Inline assembler code cannot reference any C-Labels, however
+it can reference labels defined by the inline assembler,
+e.g.:
foo() {
-... /* some c code */
-_asm
- ; some assembler code
- ljmp $0003
-_endasm ;
-... /* some more c code */
-clabel: /* inline assembler cannot reference this
-label */
-_asm
- $0003: ;label (can be reference by inline assembler
+ /* some c code */
+ _asm
+ ; some assembler code
+ ljmp $0003
+ _endasm;
+ /* some more c code */
+clabel: /* inline assembler cannot reference
+this label */
+ _asm
+ $0003: ;label (can be reference by inline assembler
only)
-_endasm ;
-...
+ _endasm ;
+ /* some more c code */
}
In other words inline assembly code can access labels defined
-in inline assembly. The same goes the other way, ie. labels
-defines in inline assembly CANNOT be accessed by C statements.
+in inline assembly within the scope of the funtion.
-3.14 int(16 bit) and long (32 bit ) Support
+The same goes the other way, ie. labels defines in inline
+assembly CANNOT be accessed by C statements.
+
+3.14 int(16 bit) and long (32 bit) Support
For signed & unsigned int (16 bit) and long (32 bit) variables,
division, multiplication and modulus operations are implemented
by support routines. These support routines are all developed
-in ANSI-C to facilitate porting to other MCUs. The following
-files contain the described routine, all of them can be
-found in the directory SDCCDIR/sdcc51lib
-
-* _mulsint.c - signed 16 bit multiplication (calls _muluint)
-
-* _muluint.c - unsigned 16 bit multiplication
-
-* _divsint.c - signed 16 bit division (calls _divuint)
-
-* _divuint.c - unsigned 16 bit division.
-
-* _modsint.c - signed 16 bit modulus (call _moduint)
-
-* _moduint.c - unsigned 16 bit modulus.
-
-* _mulslong.c - signed 32 bit multiplication (calls _mululong)
-
-* _mululong.c - unsigned32 bit multiplication.
-
-* _divslong.c - signed 32 division (calls _divulong)
-
-* _divulong.c - unsigned 32 division.
-
-* _modslong.c - signed 32 bit modulus (calls _modulong).
-
-* _modulong.c - unsigned 32 bit modulus.
-
-All these routines are compiled as non-reentrant and small
-model. Since they are compiled as non-reentrant, interrupt
-service routines should not do any of the above operations,
-if this unavoidable then the above routines will need to
-ne compiled with the --stack-auto option, after which the
-source program will have to be compiled with --int-long-rent
-option.
+in ANSI-C to facilitate porting to other MCUs, although
+some model specific assembler optimations are used. The
+following files contain the described routine, all of them
+can be found in <installdir>/share/sdcc/lib.
+
+<pending: tabularise this>
+
+_mulsint.c - signed 16 bit multiplication (calls _muluint)
+_muluint.c - unsigned 16 bit multiplication
+_divsint.c - signed 16 bit division (calls _divuint)
+_divuint.c - unsigned 16 bit division
+_modsint.c - signed 16 bit modulus (call _moduint)
+_moduint.c - unsigned 16 bit modulus
+_mulslong.c - signed 32 bit multiplication (calls _mululong)
+_mululong.c - unsigned32 bit multiplication
+_divslong.c - signed 32 division (calls _divulong)
+_divulong.c - unsigned 32 division
+_modslong.c - signed 32 bit modulus (calls _modulong)
+_modulong.c - unsigned 32 bit modulus
+
+Since they are compiled as non-reentrant, interrupt service
+routines should not do any of the above operations. If this
+is unavoidable then the above routines will need to be compiled
+with the --stack-auto option, after which the source program
+will have to be compiled with --int-long-rent option.
3.15 Floating Point Support
SDCC supports IEEE (single precision 4bytes) floating point
numbers.The floating point support routines are derived
-from gcc's floatlib.c and consists of the following routines.
-
-* _fsadd.c - add floating point numbers.
-
-* _fssub.c - subtract floating point numbers
-
-* _fsdiv.c - divide floating point numbers
-
-* _fsmul.c - multiply floating point numbers
-
-* _fs2uchar.c - convert floating point to unsigned char
-
-* _fs2char.c - convert floating point to signed char.
-
-* _fs2uint.c - convert floating point to unsigned int.
-
-* _fs2int.c - convert floating point to signed int.
-
-* _fs2ulong.c - convert floating point to unsigned long.
-
-* _fs2long.c - convert floating point to signed long.
-
-* _uchar2fs.c - convert unsigned char to floating point
-
-* _char2fs.c - convert char to floating point number
-
-* _uint2fs.c - convert unsigned int to floating point
-
-* _int2fs.c - convert int to floating point numbers
-
-* _ulong2fs.c - convert unsigned long to floating point number
-
-* _long2fs.c - convert long to floating point number.
+from gcc's floatlib.c and consists of the following routines:
+
+<pending: tabularise this>
+
+_fsadd.c - add floating point numbers
+_fssub.c - subtract floating point numbers
+_fsdiv.c - divide floating point numbers
+_fsmul.c - multiply floating point numbers
+_fs2uchar.c - convert floating point to unsigned char
+_fs2char.c - convert floating point to signed char
+_fs2uint.c - convert floating point to unsigned int
+_fs2int.c - convert floating point to signed int
+_fs2ulong.c - convert floating point to unsigned long
+_fs2long.c - convert floating point to signed long
+_uchar2fs.c - convert unsigned char to floating point
+_char2fs.c - convert char to floating point number
+_uint2fs.c - convert unsigned int to floating point
+_int2fs.c - convert int to floating point numbers
+_ulong2fs.c - convert unsigned long to floating point number
+_long2fs.c - convert long to floating point number
Note if all these routines are used simultaneously the data
space might overflow. For serious floating point usage it
-is strongly recommended that the Large model be used (in
-which case the floating point routines mentioned above will
-need to recompiled with the --model-Large option)
+is strongly recommended that the large model be used.
3.16 MCS51 Memory Models
The library routines supplied with the compiler are compiled
as both small and large. The compiled library modules are
contained in seperate directories as small and large so
-that you can link to either set. In general the use of the
-large model is discouraged.
+that you can link to either set.
When the large model is used all variables declared without
a storage class will be allocated into the external ram,
Judicious usage of the processor specific storage classes
and the 'reentrant' function type will yield much more efficient
-code, than using the large-model. Several optimizations
+code, than using the large model. Several optimizations
are disabled when the program is compiled using the large
model, it is therefore strongly recommdended that the small
model be used unless absolutely required.
-3.17 Flat 24 bit Addressing Model
+3.17 DS390 Memory Models
-This option generates code for the 24 bit contiguous addressing
-mode of the Dallas DS80C390 part. In this mode, up to four
-meg of external RAM or code space can be directly addressed.
-See the data sheets at www.dalsemi.com for further information
-on this part.
+The only model supported is Flat 24. This generates code
+for the 24 bit contiguous addressing mode of the Dallas
+DS80C390 part. In this mode, up to four meg of external
+RAM or code space can be directly addressed. See the data
+sheets at www.dalsemi.com for further information on this
+part.
In older versions of the compiler, this option was used with
the MCS51 code generator (-mmcs51). Now, however, the '390
has it's own code generator, selected by the -mds390 switch.
-This code generator currently supports only the flat24 model,
-but the --model-flat24 switch is still required, in case
-later versions of the code generator support other models
-(such as the paged mode of the '390). The combination of
--mmcs51 and --model-flat24 is now depracated.
+
Note that the compiler does not generate any code to place
-the processor into24 bitmode (it defaults to 8051 compatible
-mode). Boot loader or similar code must ensure that the
-processor is in 24 bit contiguous addressing mode before
+the processor into 24 bitmode (although tinibios in the
+ds390 libraries will do that for you). If you don't use
+tinibios, the boot loader or similar code must ensure that
+the processor is in 24 bit contiguous addressing mode before
calling the SDCC startup code.
Like the --model-large option, variables will by default
linker to generate the proper segment relocations, and the
Intel HEX output format must be used. The -r flag can be
passed to the linker by using the option -Wl-r on the sdcc
-command line.
+command line. However, currently the linker can not handle
+code segments > 64k.
3.18 Defines Created by the Compiler
* SDCC - this Symbol is always defined.
+* SDCC_mcs51 or SDCC_ds390 or SDCC_z80, etc - depending on
+ the model used (e.g.: -mds390)
+
+* __mcs51 or __ds390 or __z80, etc - depending on the model
+ used (e.g. -mz80)
+
* SDCC_STACK_AUTO - this symbol is defined when --stack-auto
option is used.
-* SDCC_MODEL_SMALL - when small model is used.
+* SDCC_MODEL_SMALL - when --model-small is used.
* SDCC_MODEL_LARGE - when --model-large is used.
* SDCC_USE_XSTACK - when --xstack option is used.
+* SDCC_STACK_TENBIT - when -mds390 is used
+
+* SDCC_MODEL_FLAT24 - when -mds390 is used
+
4 SDCC Technical Data
4.1 Optimizations
-SDCC performs a a host of standard optimizations in addition
+SDCC performs a host of standard optimizations in addition
to some MCU specific optimizations.
4.1.1 Sub-expression Elimination
-The compiler does local and global common subexpression elimination.
-
-eg.
+The compiler does local and global common subexpression elimination,
+e.g.:
i = x + y + 1;
j = x + y;
i = iTemp + 1
j = iTemp
-Some subexpressions are not as obvious as the above example.
-
-eg.
+Some subexpressions are not as obvious as the above example,
+e.g.:
a->b[i].c = 10;
a->b[i].d = 11;
4.1.2 Dead-Code Elimination
-eg.
-
int global;
void f () {
int i;
- i = 1; /* dead store
-*/
+ i = 1; /* dead store */
global = 1; /* dead store */
global = 2;
return;
will be changed to
int global; void f ()
-{
- global = 2;
- return;
+{
+ global = 2;
+ return;
}
4.1.3 Copy-Propagation
-eg.
-
int f() {
- int i, j;
- i = 10;
- j = i;
- return j;
+ int i, j;
+ i = 10;
+ j = i;
+ return j;
}
will be changed to
4.1.4 Loop Optimizations
Two types of loop optimizations are done by SDCC loop invariant
-lifting and strength reduction of loop induction variables.In
-addition to the strength reduction the optimizer marks the
-induction variables and the register allocator tries to
-keep the induction variables in registers for the duration
+lifting and strength reduction of loop induction variables.
+In addition to the strength reduction the optimizer marks
+the induction variables and the register allocator tries
+to keep the induction variables in registers for the duration
of the loop. Because of this preference of the register
-allocator , loop induction optimization causes an increase
+allocator, loop induction optimization causes an increase
in register pressure, which may cause unwanted spilling
of other temporary variables into the stack / data space.
The compiler will generate a warning message when it is
forced to allocate extra space either on the stack or data
space. If this extra space allocation is undesirable then
induction optimization can be eliminated either for the
-entire source file ( with --noinduction option) or for a
-given function only (#pragma NOINDUCTION).
+entire source file (with --noinduction option) or for a
+given function only using #pragma NOINDUCTION.
-* Loop Invariant:
-
-eg
+Loop Invariant:
for (i = 0 ; i < 100 ; i ++)
- f += k + l;
+ f += k + l;
changed to
itemp = k + l;
-for ( i = 0; i < 100; i++ ) f += itemp;
+for (i = 0; i < 100; i++)
+ f += itemp;
As mentioned previously some loop invariants are not as apparent,
all static address computations are also moved out of the
loop.
-* Strength Reduction :
+Strength Reduction, this optimization substitutes an expression
+by a cheaper expression:
-This optimization substitutes an expression by a cheaper
-expression.
-
-eg.
-
-for (i=0;i < 100; i++) ar[i*5] = i*3;
+for (i=0;i < 100; i++)
+ ar[i*5] = i*3;
changed to
itemp1 = 0;
itemp2 = 0;
for (i=0;i< 100;i++) {
- ar[itemp1] = itemp2;
- itemp1 += 5;
- itemp2 += 3;
+ ar[itemp1] = itemp2;
+ itemp1 += 5;
+ itemp2 += 3;
}
The more expensive multiplication is changed to a less expensive
addition.
-4.1.5 Loop Reversing:
+4.1.5 Loop Reversing
This optimization is done to reduce the overhead of checking
loop boundaries for every iteration. Some simple loops can
be reversed and implemented using a "decrement
and jump if not zero" instruction. SDCC
checks for the following criterion to determine if a loop
-is reversible (note: more sophisticated compiers use data-dependency
+is reversible (note: more sophisticated compilers use data-dependency
analysis to make this determination, SDCC uses a more simple
minded analysis).
* The 'for' loop is of the form
- "for ( <symbol> = <expression> ; <sym> [< | <=] <expression>
+
+ for (<symbol> = <expression> ; <sym> [< | <=] <expression>
; [<sym>++ | <sym> += 1])
- <for body>"
+ <for body>
* The <for body> does not contain "continue"
or 'break".
* There are NO switch statements in the loop.
-Note djnz instruction can be used for 8-bit values ONLY,
+Note djnz instruction can be used for 8-bit values only,
therefore it is advantageous to declare loop control symbols
-as either 'char', ofcourse this may not be possible on all
-situations.
+as char. Ofcourse this may not be possible on all situations.
4.1.6 Algebraic Simplifications
SDCC does numerous algebraic simplifications, the following
is a small sub-set of these optimizations.
-eg
i = j + 0 ; /* changed to */ i = j;
i /= 2; /* changed to */ i >>= 1;
i = j - j ; /* changed to */ i = 0;
SDCC changes switch statements to jump tables when the following
conditions are true.
-* The case labels are in numerical sequence , the labels
- need not be in order, and the starting number need not
- be one or zero.
-
-eg
+* The case labels are in numerical sequence, the labels need
+ not be in order, and the starting number need not be one
+ or zero.
switch(i) {
Switch statements which have gaps in the numeric sequence
or those that have more that 84 case labels can be split
-into more than one switch statement for efficient code generation.
-
-eg
+into more than one switch statement for efficient code generation,
+e.g.:
switch (i) {
case 1: ...
case 4: ...
}
+and
+
switch (i) {
-case 9: ...
+case 9: ...
case 10: ...
case 11: ...
-case 12:...
+case 12: ...
}
then both the switch statements will be implemented using
Bit shifting is one of the most frequently used operation
in embedded programming. SDCC tries to implement bit-shift
-operations in the most efficient way possible.
-
-eg.
+operations in the most efficient way possible, e.g.:
unsigned char i;
-
...
i>>= 4;
-..
+...
-generates the following code.
+generates the following code:
mov a,_i
swap a
mov _i,a
In general SDCC will never setup a loop if the shift count
-is known. Another example
+is known. Another example:
unsigned int i;
...
i >>= 9;
...
-will generate
+will generate:
mov a,(_i + 1)
mov (_i + 1),#0x00
mov _i,a
Note that SDCC stores numbers in little-endian format (i.e.
-lowest order first)
+lowest order first).
4.1.9 Bit-rotation
A special case of the bit-shift operation is bit rotation,
-SDCC recognizes the following expression to be a left bit-rotation.
+SDCC recognizes the following expression to be a left bit-rotation:
unsigned char i;
...
-i = ( ( i << 1) | ( i >> 7));
+i = ((i << 1) | (i >> 7));
...
-will generate the following code.
+will generate the following code:
mov a,_i
rl a
SDCC uses pattern matching on the parse tree to determine
this operation.Variations of this case will also be recognized
-as bit-rotation i.e i = ((i >> 7) | (i << 1)); /* left-bit
-rotation */
+as bit-rotation, i.e.:
+
+i = ((i >> 7) | (i << 1)); /* left-bit rotation */
4.1.10 Highest Order Bit
It is frequently required to obtain the highest order bit
of an integral type (long, int, short or char types). SDCC
recognizes the following expression to yield the highest
-order bit and generates optimized code for it.
+order bit and generates optimized code for it, e.g.:
+
+ unsigned int gint;
-eg
-unsigned int gint;
foo () {
unsigned char hob;
- ...
- hob = (gint >> 15) & 1;
- ..
+ ...
+ hob = (gint >> 15) & 1;
+ ..
}
-Will generate the following code.
+will generate the following code:
61 ; hob.c 7
66 mov
_foo_hob_1_1,a
-Variations of this case however will NOT be recognized. It
-is a standard C expression , so I heartily recommend this
+Variations of this case however will not be recognized. It
+is a standard C expression, so I heartily recommend this
be the only way to get the highest order bit, (it is portable).
Of course it will be recognized even if it is embedded in
-other expressions.
-
-eg.
+other expressions, e.g.:
xyz = gint + ((gint >> 15) & 1);
4.1.11 Peep-hole Optimizer
-The compiler uses a rule based , pattern matching and re-writing
+The compiler uses a rule based, pattern matching and re-writing
mechanism for peep-hole optimization. It is inspired by
-'copt' a peep-hole optimizer by Christopher W. Fraser (cwfraser@microsoft.com).
+copt a peep-hole optimizer by Christopher W. Fraser (cwfraser@microsoft.com).
A default set of rules are compiled into the compiler, additional
rules may be added with the --peep-file <filename> option.
The rule language is best illustrated with examples.
replace {
-mov %1,a
-mov a,%1 } by { mov %1,a }
+ mov %1,a
+ mov a,%1
+} by {
+ mov %1,a
+}
-The above rule will the following assembly sequence
+The above rule will change the following assembly sequence:
-mov r1,a
-mov a,r1
+ mov r1,a
+ mov a,r1
to
mov r1,a
-Note: All occurrences of a '%n' ( pattern variable ) must
-denote the same string. With the above rule, the assembly
-sequence
+Note: All occurrences of a %n (pattern variable) must denote
+the same string. With the above rule, the assembly sequence:
-mov r1,a
-mov a,r2
+ mov r1,a
+ mov a,r2
-will remain unmodified. Other special case optimizations
-may be added by the user (via --peep-file option), eg. some
-variants of the 8051 MCU allow only 'AJMP' and 'ACALL' ,
-the following two rules will change all 'LJMP' & 'LCALL'
-to 'AJMP' & 'ACALL'.
+will remain unmodified.
+
+Other special case optimizations may be added by the user
+(via --peep-file option). E.g. some variants of the 8051
+MCU allow only ajmp and acall. The following two rules will
+change all ljmp and lcall to ajmp and acall
replace { lcall %1 } by { acall %1 }
replace { ljmp %1 } by { ajmp %1 }
-The inline-assembler' code is also passed through the peep
+The inline-assembler code is also passed through the peep
hole optimizer, thus the peephole optimizer can also be
used as an assembly level macro expander. The rules themselves
are MCU dependent whereas the rule language infra-structure
is MCU independent. Peephole optimization rules for other
MCU can be easily programmed using the rule language.
-The syntax for a rule is as follows ,
+The syntax for a rule is as follows:
rule := replace [ restart ] '{' <assembly sequence> '\n'
'}' [if <functionName>
] '\n'
+
<assembly sequence> := assembly instruction (each instruction
-including labels must be on a separate line).
+including labels must be on a separate line).
The optimizer will apply to the rules one by one from the
top in the sequence of their appearance, it will terminate
again from the top, this option for a rule is expensive
(performance), it is intended to be used in situations where
a transformation will trigger the same rule again. A good
-example of this the following rule.
+example of this the following rule:
replace restart {
-pop %1
-push %1 } by {
-; nop
+ pop %1
+ push %1 } by {
+ ; nop
}
Note that the replace pattern cannot be a blank, but can
be a comment line. Without the 'restart' option only the
-inner most 'pop' 'push' pair would be eliminated. i.e.
+inner most 'pop' 'push' pair would be eliminated, i.e.:
-pop ar1
-pop ar2
-push ar2
-push ar1
+ pop ar1
+ pop ar2
+ push ar2
+ push ar1
-would result in
+would result in:
pop ar1
; nop
push ar1
-with the 'restart' option the rule will be applied again
-to the resulting code and the all the 'pop' 'push' pairs
-will be eliminated to yield
+with the restart option the rule will be applied again to
+the resulting code and then all the pop-push pairs will
+be eliminated to yield:
; nop
; nop
%2:} if labelInRange
The optimizer does a look-up of a function name table defined
-in function 'callFuncByName' in the source file SDCCpeeph.c
-, with the name 'labelInRange', if it finds a corresponding
+in function callFuncByName in the source file SDCCpeeph.c,
+with the name labelInRange. If it finds a corresponding
entry the function is called. Note there can be no parameters
-specified for these functions, in this case the use of '%5'
+specified for these functions, in this case the use of %5
is crucial, since the function labelInRange expects to find
the label in that particular variable (the hash table containing
the variable bindings is passed as a parameter). If you
-want to code more such functions , take a close look at
-the function labelInRange and the calling mechanism in source
-file SDCCpeeph.c. I know this whole thing is a little kludgey
-, may be some day we will have some better means. If you
+want to code more such functions, take a close look at the
+function labelInRange and the calling mechanism in source
+file SDCCpeeph.c. I know this whole thing is a little kludgey,
+but maybe some day we will have some better means. If you
are looking at this file, you will also see the default
-rules that are compiled into the compiler, you can your
+rules that are compiled into the compiler, you can add your
own rules in the default set there if you get tired of specifying
the --peep-file option.
+<pending: this is as far as I got>
+
4.2 Pragmas
SDCC supports the following #pragma directives. This directives
* NOINDUCTION - will stop loop induction optimizations.
-* NOJTBOUND - will not generate code for boundary value checking
- , when switch statements are turned into jump-tables.
+* NOJTBOUND - will not generate code for boundary value checking,
+ when switch statements are turned into jump-tables.
* NOOVERLAY - the compiler will not overlay the parameters
and local variables of a function.
ISR function (using interrupt keyword). The directive
should be placed immediately before the ISR function definition
and it affects ALL ISR functions following it. To enable
- the normal register saving for ISR functions use "#pragma
- EXCLUDE none"
+ the normal register saving for ISR functions use #pragma EXCLUDE none.
* CALLEE-SAVES function1[,function2[,function3...]] - The
compiler by default uses a caller saves convention for
code. In future the compiler (with interprocedural analysis)
will be able to determine the appropriate scheme to use
for each function call. If --callee-saves command line
- option is used, the function names specified in #pragma
- CALLEE-SAVES is appended to the list of functions specified
- inthe command line.
+ option is used, the function names specified in #pragma CALLEE-SAVES
+ is appended to the list of functions specified inthe command
+ line.
The pragma's are intended to be used to turn-off certain
optimizations which might cause the compiler to generate
%s character _generic
pointer
-The routine is very stack intesive , --stack-after-data parameter
+The routine is very stack intesive, --stack-after-data parameter
should be used when using this routine, the routine also
takes about 1K of code space. It also expects an external
-function named putchar(char ) to be present (this can be
+function named putchar(char) to be present (this can be
changed). When using the %s format the string / pointer
should be cast to a generic pointer. eg.
and faster. Please see documentation in file SDCCDIR/sdcc51lib/ser.c
* ser_ir.h - Another alternate set of serial routines provided
- by Josef Wolf <jw@raven.inka.de> , these routines do not
+ by Josef Wolf <jw@raven.inka.de>, these routines do not
use the external ram.
* reg51.h - contains register definitions for a standard
* float.h - contains min, max and other floating point related
stuff.
-All library routines are compiled as --model-small , they
+All library routines are compiled as --model-small, they
are all non-reentrant, if you plan to use the large model
or want to make these routines reentrant, then they will
have to be recompiled with the appropriate compiler option.
In the following example the function cfunc calls an assembler
routine asm_func, which takes two parameters.
-extern int asm_func( unsigned char, unsigned char);
+extern int asm_func(unsigned char, unsigned char);
int c_func (unsigned char i, unsigned char j)
4.5.2 Assembler Routine(reentrant)
In this case the second parameter onwards will be passed
-on the stack , the parameters are pushed from right to left
+on the stack, the parameters are pushed from right to left
i.e. after the call the left most parameter will be on the
top of the stack. Here is an example.
-extern int asm_func( unsigned char, unsigned char);
+extern int asm_func(unsigned char, unsigned char);
4.6 External Stack
The external stack is located at the start of the external
-ram segment , and is 256 bytes in size. When --xstack option
+ram segment, and is 256 bytes in size. When --xstack option
is used to compile the program, the parameters and local
variables of all reentrant functions are allocated in this
area. This option is provided for programs with large stack
5. Old K&R style function declarations are NOT allowed.
-foo( i,j) /* this old style of function declarations */
+foo(i,j) /* this old style of function declarations */
int i,j; /* are valid in ANSI .. not valid in SDCC */
{
...
the programmer should do an explicit cast when integral
promotion is required.
-* Reducing the size of division , multiplication & modulus
+* Reducing the size of division, multiplication & modulus
operations can reduce code size substantially. Take the
following code for example.
- foobar( unsigned int p1, unsigned char ch)
+ foobar(unsigned int p1, unsigned char ch)
{
unsigned char ch1 = p1 % ch ;
....
be performed (this will lead to a call to a support routine).
If the code is changed to
- foobar( unsigned int p1, unsigned char ch)
+ foobar(unsigned int p1, unsigned char ch)
{
unsigned char ch1 = (unsigned char)p1
% ch ;
1. Parsing the source and building the annotated parse tree.
This phase is largely MCU independent (except for the
language extensions). Syntax & semantic checks are also
- done in this phase , along with some initial optimizations
+ done in this phase, along with some initial optimizations
like back patching labels and the pattern matching optimizations
like bit-rotation etc.
SDCC is distributed with a source level debugger. The debugger
uses a command line interface, the command repertoire of
-the debugger has been kept as close to gdb ( the GNU debugger)
+the debugger has been kept as close to gdb (the GNU debugger)
as possible. The configuration and build process is part
of the standard compiler installation, which also builds
and installs the debugger in the target directory specified
* --directory=<source file directory> this option can used
to specify the directory search list. The debugger will
- look into the directory list specified for source , cdb
+ look into the directory list specified for source, cdb
& ihx files. The items in the directory list must be separated
- by ':' , e.g. if the source files can be in the directories
+ by ':', e.g. if the source files can be in the directories
/home/src1 and /home/src2, the --directory option should
be --directory=/home/src1:/home/src2. Note there can be
no spaces in the option.
7.5 Debugger Commands.
As mention earlier the command interface for the debugger
-has been deliberately kept as close the GNU debugger gdb
-, as possible, this will help int integration with existing
+has been deliberately kept as close the GNU debugger gdb,
+as possible, this will help int integration with existing
graphical user interfaces (like ddd, xxgdb or xemacs) existing
for the GNU debugger.
XEmacs is running, set the environment variable 'EMACSLOADPATH'
to the installation bin directory [$(prefix)/bin], then
enter the following command ESC-x load-file sdcdbsrc. To
-start the interface enter the following command ESC-x sdcdbsrc
-, you will prompted to enter the file name to be debugged.
+start the interface enter the following command ESC-x sdcdbsrc,
+you will prompted to enter the file name to be debugged.
The command line options that are passed to the simulator
directly are bound to default values in the file sdcdbsrc.el
projects / fw / sdcc / blobdiff