%% LyX 2.5.0~RC2 created this file.  For more info, see https://www.lyx.org/.
%% Do not edit unless you really know what you are doing.
\documentclass[oneside,british,english]{book}
\usepackage{mathptmx}
\usepackage{helvet}
\usepackage{courier}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\setcounter{secnumdepth}{3}
\setcounter{tocdepth}{3}
\usepackage{color}
\usepackage{colortbl}
\usepackage{babel}
\usepackage{array}
\usepackage{longtable}
\usepackage{varioref}
\usepackage{url}
\usepackage{footnotehyper}
\usepackage{amstext}
\usepackage{makeidx}
\makeindex
\usepackage{graphicx}
\usepackage[letterpaper]{geometry}
\geometry{verbose,tmargin=20mm,bmargin=20mm,lmargin=30mm,rmargin=25mm}
\usepackage{fancyhdr}
\pagestyle{fancy}
\usepackage[bookmarks=true,bookmarksnumbered=false,bookmarksopen=false,
 breaklinks=false,pdfborder={0 0 1},backref=false,colorlinks=true]
 {hyperref}
\hypersetup{pdftitle={SDCC Compiler User Guide},
 pdfauthor={SDCC development team},
 pdfsubject={installation, user manual},
 pdfkeywords={68hc08 8032 8051 ansi iso c compiler assembler CPU DS390 embedded development free Floating Point Arithmetic Freescale GPL HC08 S08 inline Intel ISO/IEC 9899:1990 Linux MAC OS X manual Maxim mcs51 Microchip microcontroller open source PIC Unix Windows Z80 Z180 Zilog Rabbit}}

\makeatletter

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% LyX specific LaTeX commands.

\makesavenoteenv{tabular}

\providecommand{\LyX}{\texorpdfstring{\ensureascii{%
  L\kern-.1667em\lower.25em\hbox{Y}\kern-.125emX\@}}{LyX}}
\newcommand{\noun}[1]{\textsc{#1}}
%% Because html converters don't know tabularnewline
\providecommand{\tabularnewline}{\\}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Textclass specific LaTeX commands.
\newenvironment{lyxlist}[1]
	{\begin{list}{}
		{\settowidth{\labelwidth}{#1}
		 \setlength{\leftmargin}{\labelwidth}
		 \addtolength{\leftmargin}{\labelsep}
		 \renewcommand{\makelabel}[1]{##1\hfil}}}
	{\end{list}}
\newenvironment{lyxcode}
	{\par\begin{list}{}{
		\setlength{\rightmargin}{\leftmargin}
		\setlength{\listparindent}{0pt}% needed for AMS classes
		\raggedright
		\setlength{\itemsep}{0pt}
		\setlength{\parsep}{0pt}
		\normalfont\ttfamily}%
	 \item[]}
	{\end{list}}
\providecommand*{\code}[1]{\texttt{#1}}
\providecommand*{\strong}[1]{\textbf{#1}}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% User specified LaTeX commands.
% Added by lyx2lyx
%  for proper underlining
\PassOptionsToPackage{normalem}{ulem}
\usepackage{ulem}
\let\cite@rig\cite
\newcommand{\b@xcite}[2][\%]{\def\def@pt{\%}\def\pas@pt{#1}
  \mbox{\ifx\def@pt\pas@pt\cite@rig{#2}\else\cite@rig[#1]{#2}\fi}}
\renewcommand{\underbar}[1]{{\let\cite\b@xcite\uline{#1}}}
\pdfoptionpdfminorversion=3
%
\sloppy
\tolerance=500
\emergencystretch=30pt
%
\date{}

\makeatother

\begin{document}
\title{SDCC Compiler User Guide}
\date{{\normalsize SDCC \input{sdcc_version}}\\
{\footnotesize\$Date:: 2024-01-29 \#\$ }\\
{\footnotesize\$Revision: 14650 \$}}

\maketitle

\tableofcontents{}

\chapter{Introduction}

\section{About SDCC}

\textbf{SDCC} (\emph{S}mall \emph{D}evice \emph{C} \emph{C}ompiler)
is free open source, retargettable, optimizing standard (ANSI C89
/ ISO C90, ISO C99, ISO C11 / ISO C17) C compiler suite originally
written by \textbf{Sandeep Dutta} designed for 8 bit Microprocessors.
The current version targets Intel MCS-51 based Microprocessors (8031,
8032, 8051, 8052\index{8031, 8032, 8051, 8052, mcs51 CPU}, etc.),
Dallas DS80C390 variants, NXP (formerly Freescale/Motorola) HC08 based
(HC08, S08), Zilog Z80 based MCUs (Z80, Z180, eZ80 in Z80 mode, SM83,
Rabbit 2000/3000, Rabbit 3000A , Toshiba TLCS-90, Zilog eZ80 in Z80
mode, ASCII R800\index{Z80, Z180, SM83, Rabbit 2000/3000, Rabbit 3000A CPU}),
STMicroelectronics STM8 \index{STM8}, Padauk PDK14 and PDK15. It
can be retargeted for other microprocessors; support for Padauk PDK13
and MOS6502 is under development, whereas Microchip PIC is currently
unmaintained. The entire source code for the compiler is distributed
under GPL. SDCC uses a modified version of ASXXXX\index{sdas (sdasgb, sdas6808, sdas8051, sdasz80)}
\& ASLINK\index{sdld}, free open source retargetable assembler \&
linker. SDCC has extensive language extensions suitable for utilizing
various microcontrollers and underlying hardware effectively. \\
You might also want to have a look at the wiki \url{https://sourceforge.net/p/sdcc/wiki/}.\\
\\
In addition to the MCU specific optimizations SDCC also does a host
of standard optimizations like:
\begin{itemize}
\item global sub expression elimination, 
\item loop optimizations (loop invariant, strength reduction of induction
variables and loop reversing), 
\item constant folding \& propagation, 
\item copy propagation, 
\item dead code elimination 
\item jump tables for \emph{switch} statements.
\end{itemize}
For the back-end SDCC uses a global register allocation scheme which
should be well suited for other 8 bit MCUs.\\
\\
The peep hole optimizer uses a rule based substitution mechanism which
is MCU independent.\\
\\
Supported data-types are:\\

\begin{tabular}{|c|c|c|c|>{\centering}p{0.2\textwidth}|}
\hline 
type & width & default & signed range & unsigned range\tabularnewline
\hline 
\hline 
\_Bool / bool & 8 bits, 1 byte & unsigned & - & 0, 1\tabularnewline
\hline 
char & 8 bits, 1 byte & unsigned & -128, +127 & 0, +255\tabularnewline
\hline 
short & 16 bits, 2 bytes & signed & -32.768, +32.767 & 0, +65.535\tabularnewline
\hline 
int & 16 bits, 2 bytes & signed & -32.768, +32.767 & 0, +65.535\tabularnewline
\hline 
long & 32 bits, 4 bytes & signed & -2.147.483.648, +2.147.483.647 & 0, +4.294.967.295\tabularnewline
\hline 
long long\footnote{Incomplete support in the pic14 and pic16 backends.} & 64 bits, 8 bytes & signed &  & \tabularnewline
\hline 
\_BitInt\footnote{Incomplete support in the pic14 and pic16 backends.} & 8 to 64 bits, 1 to 8 bytes &  &  & \tabularnewline
\hline 
\hline 
float & 4 bytes similar to IEEE 754 & signed &  & 1.175494351E-38, 3.402823466E+38\tabularnewline
\hline 
\hline 
pointer & 1, 2, 3 or 4 bytes & generic &  & \tabularnewline
\hline 
\hline 
\_\_bit\footnote{Only supported in the mcs51, ds390, ds400 backends.} & 1 bit & unsigned & - & 0, 1\tabularnewline
\hline 
\end{tabular}\\
The compiler also allows \emph{inline assembler code} to be embedded
anywhere in a function. In addition, routines developed in assembly
can also be called.\\
\\
SDCC also provides an option (-\/-cyclomatic) to report the relative
complexity of a function. These functions can then be further optimized,
or hand coded in assembly if needed.\\
\\
SDCC also comes with a companion source level debugger SDCDB. The
debugger currently uses ucSim, a free open source simulator for 8051
and other micro-controllers.\\
\\
The latest SDCC version can be downloaded from \url{http://sdcc.sourceforge.net/snap.php}.
\emph{Please note: the compiler will probably always be some steps
ahead of this documentation}\textbf{\index{Status of documentation}}{\bfseries\footnote{Obviously this has pros and cons}}\textbf{.}

\section{SDCC Suite Licenses}

SDCC suite is a collection of several components derived from different
sources with different licenses:
\begin{itemize}
\item executables:

\begin{itemize}
\item sdcc compiler:\\
sdcc compiler is licensed under the GPLv2 (GPLv3 might apply depending
on the libraries used when building).\\
The code or object files generated by SDCC suite are not licensed,
so they can be used in FLOSS or proprietary (closed source) applications.
\item sdcpp preprocessor:\\
derived from GCC cpp preprocessor \url{http://gcc.gnu.org/}; GPLv3
license
\item sdas assemblers and sdld linker:\\
derived from ASXXXX \url{https://shop-pdp.net/ashtml/}; GPLv3 license
\item SDCC run-time libraries:\\
The great majority of SDCC run-time libraries are licensed under the
GPLv2+LE\index{GPLv2+LE} which allows linking of SDCC run-time libraries
with proprietary (closed source) applications.\\
A possible exception are pic device libraries and header files which
are generated from Microchip header (.inc) and linker script (.lkr)
files. Microchip requires that \textquotedbl The header files should
state that they are only to be used with authentic Microchip devices\textquotedbl{}
which makes them incompatible with the GPL, if Microchip has any copyright
in them (which might depend on local copyright laws). Pic device libraries
and header files are located at non-free/lib and non-free/include
directories respectively. SDCC should be run with the \textbf{-\/-}use-non-free\textbf{\index{-/-use-non-free@-\/-use-non-free}}
command line option in order to include non-free header files and
libraries. 
\item sdbinutils utilities (sdar, sdranlib, sdnm, sdobjcopy):\\
derived from GNU Binutils \url{http://www.gnu.org/software/binutils/};
GPLv3 license
\item ucsim simulators:\\
GPLv2 license
\item sdcdb debugger:\\
GPLv2 license
\item gcc-test regression tests:\\
derived from gcc-testsuite; no license explicitely specified, but
since it is a part of GCC is probably GPLv3 licensed
\item packihx:\\
public domain
\item makebin:\\
zlib/libpng License
\item pic libraries in device/non-free:\\
Microchip Technology Inc.\ claims to have copyrights on this, and
their term are non-free. However, a more common opinion is that Microchip
Technology Inc.\ is just claiming a copyright on uncopyrightable
facts.
\end{itemize}
\item libraries:

\begin{itemize}
\item dbuf library:\\
zlib/libpng License
\item Boost C++ libraries:\\
\url{http://www.boost.org/}; Boost Software License 1.0 (BSL-1.0)
\end{itemize}
\end{itemize}
Links to licenses:
\begin{itemize}
\item GPLv2 license\index{GPLv2 license}: \url{http://www.gnu.org/licenses/old-licenses/gpl-2.0.html}
\item LGPLv2.1 license\index{LGPLv2.1 license}: \url{http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html}
\item GPLv3 license\index{GPLv3 license}: \url{http://www.gnu.org/licenses/gpl.html}
\item zlib/libpng License\index{zlib/libpng License}: \url{http://www.opensource.org/licenses/Zlib}
\item Boost Software License 1.0 (BSL-1.0)\index{Boost Software License 1.0 (BSL-1.0)}:
\url{http://www.opensource.org/licenses/BSL-1.0}
\end{itemize}

\section{Documentation}

This documentation is maintained using a free open source word processor
(\LyX ) \url{http://www.lyx.org/}.

\section{Typographic conventions\index{Typographic conventions}}

Throughout this manual, we will use the following convention. Commands
you have to type in are printed in \textsf{\textbf{\textquotedbl sans
serif\textquotedbl}}\textsf{.} Code samples are printed in \texttt{typewriter
font.} Interesting items and new terms are printed in \emph{italic.}

\section{Compatibility\label{sec:Compatibility-with-previous} with previous
versions\index{Compatibility with previous versions}}

Newer versions have usually numerous bug fixes compared with the previous
version. But we also sometimes introduce some incompatibilities with
older versions. Not just for the fun of it, but to make the compiler
more stable, efficient and standard compliant\index{Standard-compliance}
(see section \ref{subsec:Standard-Compliance} for Standard-Compliance).
This is a list of such changes .
\begin{itemize}
\item short is now equivalent to int (16 bits), it used to be equivalent
to char (8 bits) which is not ANSI compliant. To maintain compatibility,
old programs could be compiled using the -\/-short-is-8bits command
line option (option removed after the 3.6.0 release).
\item the default directory for gcc-builds where include, library and documentation
files are stored is now in /usr/local/share.
\item char type parameters to vararg\index{vararg, va_arg@vararg, va\_arg}
functions are casted to int unless explicitly casted and neither of
the \textbf{-\/-std-c90\index{-/-std-c90@-\/-std-c90},} \textbf{-\/-std-c99\index{-/-std-c99@-\/-std-c99},
-\/-std-c11\index{-/-std-c11@-\/-std-c11}} or \textbf{-\/-std-c23\index{-/-std-c23@-\/-std-c23}}
command line options is used, e.g.: \\
\texttt{~~char a=3;}~\\
\texttt{~~printf (\textquotedbl\%d \%c\textbackslash n\textquotedbl ,
a, (char)a);}\\
 will push a as an int and as a char resp if none of the above command
line options are not defined,\\
 will push a as two ints if none of the above command line option
is defined.
\item pointer type parameters to vararg\index{vararg, va_arg@vararg, va\_arg}
functions are casted to generic pointers on Harvard architectures
(e.g. mcs51, ds390) unless explicitly casted and neither of the \textbf{-\/-std-c90\index{-/-std-c90@-\/-std-c90},}
\textbf{-\/-std-c99\index{-/-std-c99@-\/-std-c99}, -\/-std-c11\index{-/-std-c11@-\/-std-c11}}
or \textbf{-\/-std-c23\index{-/-std-c23@-\/-std-c23}} command line
options is used.
\item option -\/-regextend has been removed.
\item option -\/-noregparms has been removed.
\item option -\/-stack-after-data has been removed.
\item \_\_bit\index{__bit@\_\_bit} and \_\_sbit\index{__sbit@\_\_sbit}
types now consistently behave like the C99 \_Bool type with respect
to type conversion\index{type conversion}\index{type promotion}.
The most common incompatibility resulting from this change is related
to bit toggling\index{Bit toggling} idioms, e.g.:\\
\texttt{~~\_\_bit b;}~\\
\texttt{~~b = \textasciitilde\index{ Operator@\textasciitilde{} Operator}b;
/{*} equivalent to b=1 instead of toggling b {*}/}~\\
\texttt{~~b = !b; /{*} toggles b {*}/}~\\
In previous versions, both forms would have toggled the bit.
\item in older versions, the preprocessor was always called with \textbf{-\/-std-c99\index{-/-std-c99@-\/-std-c99}}
regardless of the \textbf{-\/-std-xxx} setting. This is no longer
true, and can cause compilation failures on code built with \textbf{-\/-std-c90\index{-/-std-c90@-\/-std-c90}}
but using c99 preprocessor features, such as one-line (//) comments
\item in versions older than 2.8.4 the pic16 {*}printf() and printf\_tiny()
library functions supported undocumented and not standard compliant
'b' binary format specifier (\textquotedbl\%b\textquotedbl , \textquotedbl\%hb\textquotedbl{}
and \textquotedbl\%lb\textquotedbl ). The 'b' specifier is now
disabled by default. It can be enabled by defining BINARY\_SPECIFIER
macro in files device/lib/pic16/libc/stdio/vfprintf.c and device/lib/pic16/libc/stdio/printf\_tiny.c
and recompiling the library.
\item in versions older then 2.8.5 the unnamed bit-field structure members
participated in initialization, which is not conforming with ISO/IEC
9899:1999 standard (see section Section 6.7.8 Initialization, clause
9)\\
\\
Old behaviour, before version 2.8.5:\texttt{}~\\
\texttt{~~struct \{}~\\
\texttt{~~~~int a : 2;}~\\
\texttt{~~~~char~ : 2;}~\\
\texttt{~~~~int b : 2;}~\\
\texttt{~~\} s = \{1, 2, 3\};}\\
\texttt{/{*} s.a = 1, s.b = 3 {*}/}\\
\\
New behaviour:\texttt{}~\\
\texttt{~~struct \{}~\\
\texttt{~~~~int a : 2;}~\\
\texttt{~~~~char~ : 2;}~\\
\texttt{~~~~int b : 2;}~\\
\texttt{~~\} s = \{1, 2\};}\\
\texttt{/{*} s.a = 1, s.b = 2 {*}/}
\item In 2.9.0 libraries included in SDCC packages, are in ar format. See
section \ref{subsec:Using-sdar-to}.
\item In 3.0.0 targets for xa51 and avr are disabled by default.
\item In 3.0.0 sdldgb and sdldz80 don't support generation of Game Boy binary
image format. The makebin utility can be used to convert Intel Hex
format to Game Boy binary image format.
\item In 3.0.0 sdldgb and sdldz80 don't support generation of rrgb (Game
Boy simulator) map file and no\$gmb symbol file formats. The as2gbmap
utility can be used to convert sdld map format to rrgb and no\$gmb
file formats.
\item In 3.1.0 asranlib utility was renamed to sdranlib.
\item In 3.1.0 pic14 target, structured access to SFR via \texttt{<sfrname>\_bits.<bitname>}
is deprecated and replaced by \texttt{<sfrname>bits.<bitname>}. It
will be obsoleted (removed) in one of next SDCC releases. See section
\ref{subsec:Naming-of-special}.
\item sdar archive managing utility and sdnm utilities were introduced in
version 3.2.0. sdar, sdranlib and sdnm are derived from GNU Binutils
package.
\item In 3.2.0 the sdcclib utility is deprecated. Sdar utility should be
used to create SDCC object file archives. Sdcclib utility will become
obsolete in one of next SDCC releases and will be removed from SDCC
packages.
\item In 3.2.0 special SDCC keywords which are not preceded by a double
underscore are obsoleted (removed). See section \ref{subsec:Standard-Compliance}
Standard-Compliance.
\item In 3.2.0 compiler macro definitions not starting with double underscore
characters are deprecated if \code{-{}-std-cXX} command line option
is defined. They have been obsoleted (removed) after the 3.4.0 release
(except for the macro SDCC, which has been removed after the 3.6.0
release (and brought back for mcs51 for the 3.7.0 release)).
\item In 3.2.0 new compiler macros for processor definition were introduced
for pic14 and pic16 targets: -D\_\_SDCC\_PIC16XXXX and -D\_\_SDCC\_PIC18FXXX
respectively. The pic16 macro definition -D\_\_18fXXX is deprecated.
It was obsoleted (removed) after the 3.4.0 release.
\item In 3.2.0 pragma config for pic16 target was introduced. See section
\ref{subsec:PIC16_Pragmas}
\item In 3.2.0 new inline assembler format \texttt{\_\_asm\_\_ (''inline\_assembler\_code'');}
as an addition to \texttt{\_\_asm ... \_\_endasem;} format introduced.
See section \ref{sec:Inline-Assembler-Code}
\item sdobjcopy utility was introduced in version 3.3.0. It is derived from
GNU Binutils package.
\item Before 3.4.0 release, intrinsic named address spaces were called ''storage
classes'' in this manual.
\item In 3.6.0, the default for char changed from signed to unsigned.
\item In 3.7.0, the prototype for putchar() changed from void putchar(char)
to int putchar(int).
\item In 3.7.0 mcs51 and ds390 got a full \_Bool/bool type, separate from
\_\_bit.
\item In 3.7.0, the option \textbf{-\/-nojtbound} and the corresponding
pragma have been deprecated.
\item In 3.7.0, the prototype for getchar() changed from char getchar(void)
to int getchar(void).
\item In 3.8.6, the deprecated sdcclib was removed.
\item In 4.0.3, \_itoa, \_uitoa, \_ltoa, \_ultoa were renamed to \_\_itoa,
\_\_uitoa, \_\_ltoa, \_\_ultoa.
\item In 4.1.1, typeof.h has been removed.
\item In 4.1.3, support for \textbf{-\/-oldralloc} has been removed for
the z80-related backends.
\item In 4.1.10, the default calling convention switched from \_\_sdccall(0)
to \_\_sdccall(1) for stm8 and gbz80.
\item In 4.1.10, support for\textbf{ -\/-profile} has been removed for
gbz80.
\item In 4.1.11, the minimum Z80N Core version for the z80n port has been
raised from 1.0 to 2.0.
\item In 4.1.12, the default calling convention switched from \_\_sdccall(0)
to \_\_sdccall(1) for z80, z180 and z80n.
\item In 4.1.12, support for \textbf{-\/-profile} has been removed for
z80, z180, z80n.
\item In 4.1.13, support for \textbf{-\/-profile} has been removed.
\item In 4.1.14, the gbz80 port was renamed to sm83.
\item In 4.2.3, support for non-parenthesized arguments to \_\_using and
\_\_interrupt was dropped.
\item In 4.2.3, support for non-parenthesized arguments to \_\_at that are
not constants was dropped.
\item In 4.2.4, the placement of \_\_at in declarations was restricted.
\item In 4.2.6, bool is chosen as the underlying integer type for enumerations
with just two values.
\item In 4.2.9, support for\textbf{-\/-pedantic-parse-number} and \#pragma
pedantic\_parse\_numer was dropped.
\item In 4.2.9, support for \#pragma sdcc\_hash was dropped, necessitating
a wrapper macro for literal ''\#'' characters in macro bodies.
\item In 4.2.9, support for arguments to -MMD was dropped. The output file
can be specified via -MF instead.
\item In 4.2.10, \_sdcc\_external\_startup was renamed to \_\_sdcc\_external\_startup
and support for it was added to further ports.
\item In 4.2.13, for the sm83 port, \_\_sfr addresses need to be specified
using the full 16-bit address.
\item In 4.2.14, byte order in output from the \%p specifier of printf()-family
functions was corrected for big-endian platforms (stm8, hc08, s08,
mos6502) to match uintptr\_t.
\item In 4.3.1, \_\_builtin\_rlc, \_\_builtin\_rrc and \_\_builtin\_swap
were replaced by \_\_builtin\_rot.
\item In 4.3.6, support for \textbf{-\/-parms-in-bank1} was removed from
the mcs51 port.
\item In 4.4.1, the address width in .rel files was increased from 24 bits
to 32 bits for the z80 (and related) ports.
\end{itemize}

\section{System Requirements}

What do you need before you start installation of SDCC? A computer,
and a desire to compute. The preferred method of installation is to
compile SDCC from source using GNU GCC and make. For Windows some
pre-compiled binary distributions are available for your convenience.
You should have some experience with command line tools and compiler
use.

\section{Other Resources}

The SDCC home page at \url{http://sdcc.sourceforge.net/} is a great
place to find distribution sets. You can also find links to the user
mailing lists that offer help or discuss SDCC with other SDCC users.
Web links to other SDCC related sites can also be found here. This
document can be found in the doc directory of the source package.
The latest snapshot build version of this document in pdf format is
available at \url{http://sdcc.sourceforge.net/doc/sdccman.pdf}. Some
of the other tools (simulator and 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 from Subversion on \url{http://sourceforge.net/p/sdcc/code/8805/tree/trunk/sdcc/}.

\chapter{Installing SDCC\index{Installation}}

For most users it is sufficient to skip to either section \ref{subsec:Building-SDCC-on-Linux}
(Unix) or section \ref{subsec:Windows-Install} (Windows). More detailed
instructions follow below.

\section{Configure Options\index{Options SDCC configuration}}

The install paths, search paths and other options are defined when
running 'configure'. The defaults can be overridden by:
\begin{lyxlist}{00.00.0000}
\item [{-\/-prefix}] see table below
\item [{-\/-exec\_prefix}] see table below
\item [{-\/-bindir}] see table below
\item [{-\/-datadir}] see table below
\item [{-\/-datarootdir}] see table below\\
\item [{~~docdir}] environment variable, see table below
\item [{~~include\_dir\_suffix}] environment variable, see table below
\item [{~~non\_free\_include\_dir\_suffix}] environment variable, see
table below
\item [{~~lib\_dir\_suffix}] environment variable, see table below
\item [{~~~non\_free\_lib\_dir\_suffix}] environment variable, see table
below
\item [{~~sdccconf\_h\_dir\_separator}] environment variable, either
/ or \textbackslash\textbackslash{} makes sense here. This character
will only be used in sdccconf.h; don't forget it's a C-header, therefore
a double-backslash is needed there.\\
\item [{-\/-disable-mcs51-port}] Excludes the Intel mcs51 port
\item [{-\/-disable-z80-port}] Excludes the z80 port
\item [{-\/-disable-z180-port}] Excludes the z180 port
\item [{-\/-disable-ez80\_z80-port}] Excludes the e80\_z80 port
\item [{-\/-disable-z80n-port}] Excludes the z80n port
\item [{-\/-disable-r800-port}] Excludes the r800 port
\item [{-\/-disable-r2k-port}] Excludes the r2k port
\item [{-\/-disable-r2ka-port}] Excludes the r2ka port
\item [{-\/-disable-r3ka-port}] Excludes the r3ka port
\item [{-\/-disable-sm83-port}] Excludes the SM83 port
\item [{-\/-disable-tlcs90-port}] Excludes the TLCS-90 port
\item [{-\/-disable-ds390-port}] Excludes the DS390 port
\item [{-\/-disable-ds400-port}] Excludes the DS400 port
\item [{-\/-disable-hc08-port}] Excludes the HC08 port
\item [{-\/-disable-s08-port}] Excludes the S08 port
\item [{-\/-disable-stm8-port}] Excludes the STM8 port
\item [{-\/-disable-pdk13-port}] Excludes the PDK13 port
\item [{-\/-disable-pdk14-port}] Excludes the PDK14 port
\item [{-\/-disable-pdk15-port}] Excludes the PDK15 port
\item [{-\/-disable-pic14-port}] Excludes the PIC14 port
\item [{-\/-disable-pic16-port}] Excludes the PIC16 port
\item [{-\/-disable-mos6502-port}] Excludes the MOS6502
\item [{-\/-disable-mos65c02-port}] Excludes the MOS65C02
\item [{-\/-disable-ucsim}] Disables configuring and building of ucsim
\item [{-\/-disable-device-lib}] Disables automatically building device
libraries
\item [{-\/-disable-packihx}] Disables building packihx
\item [{-\/-enable-doc}] Build pdf, html and txt files from the lyx sources
\item [{-\/-enable-libgc}] Use the Bohem memory allocator. Lower runtime
footprint.
\item [{-\/-without-ccache}] Do not use ccache even if available
\end{lyxlist}
Furthermore the environment variables CC, CFLAGS, ... the tools and
their arguments can be influenced. Please see `configure -\/-help'
and the man/info pages of `configure' for details.\\
\\
The names of the standard libraries STD\_LIB, STD\_INT\_LIB, STD\_LONG\_LIB,
STD\_FP\_LIB, STD\_DS390\_LIB, STD\_XA51\_LIB and the environment
variables SDCC\_DIR\_NAME, SDCC\_INCLUDE\_NAME, SDCC\_LIB\_NAME are
defined by `configure' too. At the moment it's not possible to change
the default settings (it was simply never required).\\
\\
These configure options are compiled into the binaries, and can only
be changed by rerunning 'configure' and recompiling SDCC. The configure
options are written in \emph{italics} to distinguish them from run
time environment variables (see section search paths).\\
\\
The settings for ''Win32 builds'' are used by the SDCC team to build
the official Win32 binaries. The SDCC team uses Mingw32 to build the
official Windows binaries, because it's
\begin{enumerate}
\item open source, 
\item a gcc compiler and last but not least
\item the binaries can be built by cross compiling on SDCC Distributed Compile
Farm.
\end{enumerate}
See the examples, how to pass the Win32 settings to 'configure'. The
other Win32 builds using VC or whatever don't use 'configure', but
a header file sdcc\_vc.h.in is the same as sdccconf.h built by 'configure'
for Win32.\\
\\
These defaults are:\\

\begin{center}
\begin{tabular}{|c|c|c|}
\hline 
Variable & default & Win32 builds\tabularnewline
\hline 
\hline 
\emph{PREFIX} & /usr/local & \textbackslash sdcc\tabularnewline
\hline 
\emph{EXEC\_PREFIX} & \emph{\$PREFIX} & \emph{\$PREFIX}\tabularnewline
\hline 
\emph{BINDIR} & \emph{\$EXEC\_PREFIX}/bin & \emph{\$EXEC\_PREFIX}\textbackslash bin\tabularnewline
\hline 
\emph{DATADIR} & \emph{\$DATAROOTDIR} & \emph{\$DATAROOTDIR}\tabularnewline
\hline 
\emph{DATAROOTDIR} & \emph{\$PREFIX}/share & \emph{\$PREFIX}\tabularnewline
\hline 
\emph{DOCDIR} & \emph{\$DATAROOTDIR}/sdcc/doc & \emph{\$DATAROOTDIR}\textbackslash doc\tabularnewline
\hline 
\emph{INCLUDE\_DIR\_SUFFIX} & sdcc/include & include\tabularnewline
\hline 
\emph{NON\_FREE\_INCLUDE\_DIR\_SUFFIX} & sdcc/non-free/include & non-free/include\tabularnewline
\hline 
\emph{LIB\_DIR\_SUFFIX} & sdcc/lib & lib\tabularnewline
\hline 
\emph{NON\_FREE\_LIB\_DIR\_SUFFIX} & sdcc/non-free/lib & non-free/lib\tabularnewline
\hline 
\end{tabular}\\
\par\end{center}

\noindent 'configure' also computes relative paths. This is needed
for full relocatability of a binary package and to complete search
paths (see section search paths below):\\
 

\begin{center}
\begin{tabular}{|c|c|c|}
\hline 
Variable (computed) & default & Win32 builds\tabularnewline
\hline 
\hline 
\emph{BIN2DATA\_DIR} & ../share & ..\tabularnewline
\hline 
\emph{PREFIX2BIN\_DIR} & bin & bin\tabularnewline
\hline 
\emph{PREFIX2DATA\_DIR} & share/sdcc & \tabularnewline
\hline 
\end{tabular}\\
\par\end{center}

\noindent Examples:
\begin{lyxcode}
./configure~\\
./configure~-\/-prefix=''/usr/bin''~-\/-datarootdir=''/usr/share''~\\
./configure~-\/-disable-avr-port~-\/-disable-xa51-port
\end{lyxcode}
To cross compile on linux for Mingw32 (see also 'sdcc/support/scripts/sdcc\_mingw32'):
\begin{lyxcode}
./configure~\textbackslash ~\\
CC=''i586-mingw32msvc-gcc''~CXX=''i586-mingw32msvc-g++''~\textbackslash ~\\
RANLIB=''i586-mingw32msvc-ranlib''~\textbackslash ~\\
STRIP=''i586-mingw32msvc-strip''~\textbackslash ~\\
-\/-prefix=''/sdcc''~\textbackslash ~\\
-\/-datarootdir=''/sdcc''~\textbackslash ~\\
docdir=''\textbackslash\$\{datarootdir\}/doc''~\textbackslash ~\\
include\_dir\_suffix=''include''~\textbackslash ~\\
non\_free\_include\_dir\_suffix=''non-free/include''~\textbackslash ~\\
lib\_dir\_suffix=''lib''~\textbackslash ~\\
non\_free\_lib\_dir\_suffix=''non-free/lib''~\textbackslash ~\\
sdccconf\_h\_dir\_separator=''\textbackslash\textbackslash\textbackslash\textbackslash ''~\textbackslash ~\\
-\/-disable-device-lib~\textbackslash ~\\
-\/-host=i586-mingw32msvc~\textbackslash ~\\
-\/-build=unknown-unknown-linux-gnu
\end{lyxcode}
To ''cross''compile on Cygwin for Mingw32 (see also sdcc/support/scripts/sdcc\_cygwin\_mingw32):
\begin{lyxcode}
./configure~\textbackslash ~\\
-\/-prefix=''/sdcc''~\textbackslash ~\\
-\/-datarootdir=''/sdcc''~\textbackslash ~\\
docdir=''\textbackslash\$\{datarootdir\}/doc''~\textbackslash ~~\\
include\_dir\_suffix=''include''~\textbackslash ~\\
non\_free\_include\_dir\_suffix=''non-free/include''~\textbackslash ~\\
lib\_dir\_suffix=''lib''~\textbackslash ~\\
non\_free\_lib\_dir\_suffix=''non-free/lib''~\textbackslash ~\\
sdccconf\_h\_dir\_separator=''\textbackslash\textbackslash\textbackslash\textbackslash ''~\textbackslash ~\\
CC=''gcc~-mno-cygwin''~\textbackslash ~\\
CXX=''g++~-mno-cygwin''~
\end{lyxcode}

\section{Install paths\label{subsec:Install-paths}\index{Install paths}}
\begin{center}
\begin{tabular}{|l|>{\raggedright}p{4.5cm}|>{\raggedright}p{4cm}|>{\raggedright}p{4cm}|}
\hline 
\textbf{Description} & \textbf{Path} & \textbf{Default} & \textbf{Win32 builds}\tabularnewline
\hline 
\hline 
Binary files{*} & \emph{\$EXEC\_PREFIX} & /usr/local/bin & \textbackslash sdcc\textbackslash bin\tabularnewline
\hline 
Include files & \emph{\$DATADIR/}\\
\emph{\$INCLUDE\_DIR\_SUFFIX} & /usr/local/share/\\
sdcc/include & \textbackslash sdcc\textbackslash include\tabularnewline
\hline 
Non-free include files & \emph{\$DATADIR/non-free/}\\
\emph{\$INCLUDE\_DIR\_SUFFIX} & /usr/local/share/\\
sdcc/non-free/include & \textbackslash sdcc\textbackslash non-free\textbackslash include\tabularnewline
\hline 
Library file{*}{*} & \emph{\$DATADIR/}\\
\emph{\$LIB\_DIR\_SUFFIX} & /usr/local/share/\\
sdcc/lib & \textbackslash sdcc\textbackslash lib\tabularnewline
\hline 
Library file{*}{*} & \emph{\$DATADIR/non-free/}\\
\emph{\$LIB\_DIR\_SUFFIX} & /usr/local/share/\\
sdcc/non-free/lib & \textbackslash sdcc\textbackslash non-free\textbackslash lib\tabularnewline
\hline 
Documentation & \emph{\$DOCDIR} & /usr/local/share/\\
sdcc/doc & \textbackslash sdcc\textbackslash doc\tabularnewline
\hline 
\end{tabular}
\par\end{center}
\begin{verse}
{\footnotesize{*}compiler, preprocessor, assembler, and linker}\\
{\footnotesize{*}{*}the }{\footnotesize\textit{model}}{\footnotesize{}
is auto-appended by the compiler, e.g. small, large, z80, ds390 etc}{\footnotesize\par}
\end{verse}
\noindent The install paths can still be changed during `make install'
with e.g.:
\begin{lyxcode}
make~install~prefix=\$(HOME)/local/sdcc
\end{lyxcode}
Of course this doesn't change the search paths compiled into the binaries.\\
\\
Moreover the install path can be changed by defining DESTDIR\index{DESTDIR}:
\begin{lyxcode}
make~install~DESTDIR=\$(HOME)/sdcc.rpm/
\end{lyxcode}
Please note that DESTDIR must have a trailing slash!

\section{Search Paths\label{subsec:Search-Paths}\index{Search path}}

Some search paths or parts of them are determined by configure variables
(in \emph{italics}, see section above). Further search paths are determined
by environment variables during runtime. \\
The paths searched when running the compiler are as follows (the first
catch wins):\\
\\
1. Binary files (preprocessor, assembler and linker)\\

\begin{center}
\begin{tabular}{|c|c|c|}
\hline 
Search path & default & Win32 builds\tabularnewline
\hline 
\hline 
\$SDCC\_HOME/\emph{\$PPREFIX2BIN\_DIR} & \$SDCC\_HOME/bin & \$SDCC\_HOME\textbackslash bin\tabularnewline
\hline 
Path of argv{[}0{]} (if available) & Path of argv{[}0{]} & Path of argv{[}0{]}\tabularnewline
\hline 
\$PATH & \$PATH & \$PATH\tabularnewline
\hline 
\end{tabular} \\
\par\end{center}

\noindent 2. Include files\\

\begin{center}
\begin{tabular}{|p{0.5cm}|p{4.8cm}|p{4.8cm}|c|}
\hline 
\# & Search path & default & Win32 builds\tabularnewline
\hline 
\hline 
1 & -\/-I dir & -\/-I dir & -\/-I dir\tabularnewline
\hline 
2 & \$SDCC\_INCLUDE & \$SDCC\_INCLUDE & \$SDCC\_INCLUDE\tabularnewline
\hline 
3 & \$SDCC\_HOME/\newline
\emph{\$PREFIX2DATA\_DIR/}\newline
\emph{\$INCLUDE\_DIR\_SUFFIX} & \$SDCC\_HOME/\newline
share/sdcc/include & \$SDCC\_HOME\textbackslash include\tabularnewline
\hline 
4 & path(argv{[}0{]})/\newline
\emph{\$BIN2DATADIR/}\newline
\emph{\$INCLUDE\_DIR\_SUFFIX} & path(argv{[}0{]})/../\newline
sdcc/include & path(argv{[}0{]})\textbackslash ..\textbackslash include\tabularnewline
\hline 
5 & \emph{\$DATADIR/}\newline
\emph{\$INCLUDE\_DIR\_SUFFIX} & /usr/local/share/\newline
sdcc/include & (not on Win32)\tabularnewline
\hline 
6 & \$SDCC\_HOME/\newline
\emph{\$PREFIX2DATA\_DIR/}\newline
\emph{non-free/}\newline
\emph{\$INCLUDE\_DIR\_SUFFIX} & \$SDCC\_HOME/share/\newline
sdcc/non-free/include & \$SDCC\_HOME\textbackslash non-free\textbackslash include\tabularnewline
\hline 
7 & path(argv{[}0{]})/\newline
\emph{\$BIN2DATADIR/}\newline
\emph{non-free/}\newline
\emph{\$INCLUDE\_DIR\_SUFFIX} & path(argv{[}0{]})/../\newline
sdcc/non-free/include & path(argv{[}0{]})\textbackslash ..\textbackslash non-free\textbackslash include\tabularnewline
\hline 
8 & \emph{\$DATADIR/}\newline
\emph{non-free/}\newline
\emph{\$INCLUDE\_DIR\_SUFFIX} & /usr/local/share/\newline
sdcc/non-free/include & (not on Win32)\tabularnewline
\hline 
\end{tabular} \\
\par\end{center}

\noindent The option -\/-nostdinc disables all search paths except
\#1 and \#2.\\
\\
3. Library files\\

With the exception of ''-\/-L dir'' the \textit{model} is auto-appended
by the compiler (e.g. small, large, z80, ds390 etc.).\\

\begin{center}
\begin{tabular}{|p{0.5cm}|p{4.5cm}|p{5cm}|p{4.5cm}|}
\hline 
\# & Search path & default & Win32 builds\tabularnewline
\hline 
\hline 
1 & -\/-L dir & -\/-L dir & -\/-L dir\tabularnewline
\hline 
2 & \$SDCC\_LIB/\emph{<model>} & \$SDCC\_LIB/\emph{<model>} & \$SDCC\_LIB/\emph{<model>}\tabularnewline
\hline 
3 & \$SDCC\_LIB & \$SDCC\_LIB & \$SDCC\_LIB\tabularnewline
\hline 
4 & \$SDCC\_HOME/\newline
\emph{\$PREFIX2DATA\_DIR/}\newline
\emph{\$LIB\_DIR\_SUFFIX/}\newline
\emph{<model>} & \$SDCC\_HOME/\newline
share/sdcc/lib/<\emph{model>} & \$SDCC\_HOME\textbackslash\newline
lib\textbackslash\emph{<model>}\tabularnewline
\hline 
5 & path(argv{[}0{]})/\newline
\emph{\$BIN2DATADIR/}\newline
\emph{\$LIB\_DIR\_SUFFIX/}\newline
\emph{<model>} & path(argv{[}0{]})/../sdcc/\newline
lib/\emph{<model>} & path(argv{[}0{]})\textbackslash\newline
..\textbackslash lib\textbackslash\newline
\emph{<model>}\tabularnewline
\hline 
6 & \emph{\$DATADIR/non-free/}\newline
\emph{\$LIB\_DIR\_SUFFIX/}\newline
\emph{<model>} & /usr/local/share/sdcc/\newline
lib/\emph{<model>} & (not on Win32)\tabularnewline
\hline 
7 & \$SDCC\_HOME/\newline
\emph{\$PREFIX2DATA\_DIR/}\newline
\emph{non-free/}\newline
\emph{\$LIB\_DIR\_SUFFIX/}\newline
\emph{<model>} & \$SDCC\_HOME/share/sdcc/\newline
non-free/lib/\emph{<model>} & \$SDCC\_HOME\textbackslash\newline
lib\textbackslash non-free\emph{\textbackslash <model>}\tabularnewline
\hline 
8 & path(argv{[}0{]})/\newline
\emph{\$BIN2DATADIR/}\newline
\emph{non-free/}\newline
\emph{\$LIB\_DIR\_SUFFIX/}\newline
\emph{<model>} & path(argv{[}0{]})/../sdcc/\newline
non-free/lib/\emph{<model>} & path(argv{[}0{]})\textbackslash ..\textbackslash\newline
lib\textbackslash non-free\emph{\textbackslash <model>}\tabularnewline
\hline 
9 & \emph{\$DATADIR/non-free/}\newline
\emph{\$LIB\_DIR\_SUFFIX/}\newline
\emph{<model>} & /usr/local/share/sdcc/\newline
non-free/lib/\newline
\emph{<model>} & (not on Win32)\tabularnewline
\hline 
\end{tabular}\\
\par\end{center}

~\\
The option -\/-nostdlib disables all search paths except \#1 and
\#2.

\section{Building SDCC\index{Building SDCC}}

SDCC can be built for various host platforms using the instructions
provided below. Note that the PIC14 and PIC16 library folders in the
source distribution contain Autotools-generated files. These are included
for convenience and to avoid introducing Autotools as an additional
dependency. They have to be regenerated in case of a version mismatch.
Alternatively, the PIC backends can be disabled.

\subsection{Building SDCC on Linux\label{subsec:Building-SDCC-on-Linux}}
\begin{enumerate}
\item Download the source package either from the SDCC Subversion repository
or from snapshot builds, it will be named something like sdcc-src-yyyymmdd-rrrr.tar.bz2
\url{http://sdcc.sourceforge.net/snap.php}.
\item Bring up a command line terminal, such as xterm.
\item Unpack the file using a command like: \textsf{\textbf{\textquotedbl tar
-xvjf sdcc-src-yyyymmdd-rrrr.tar.bz2''}}, this will create a sub-directory
called sdcc with all of the sources.
\item Change directory into the main SDCC directory, for example type: \textsf{\textbf{\textquotedbl cd
sdcc}}\textsf{\textquotedbl .}
\item Type \textsf{\textbf{\textquotedbl ./configure}}\textquotedbl .
This configures the package for compilation on your system. When the
treedec library is available, it should be found and used automatically
(improving the compilation time / code quality trade-off). As of SDCC
3.7.0, the current develop branch from https://github.com/freetdi/tdlib
is a suitable version of treedec.
\item Type \textsf{\textbf{\textquotedbl make}}\textquotedbl . All of
the source packages will compile, this can take a while.
\item Type \textsf{\textbf{\textquotedbl make install\textquotedbl}}
as root. This copies the binary executables, the include files, the
libraries and the documentation to the install directories. Proceed
with section \ref{sec:Testing-the-SDCC}.
\end{enumerate}

\subsection{Building SDCC on Mac OS X}

Follow the instruction for Linux.\\
\\
On Mac OS X 10.2.x it was reported, that the default gcc (version
3.1 20020420 (prerelease)) fails to compile SDCC. Fortunately there's
also gcc 2.9.x installed, which works fine. This compiler can be selected
by running 'configure' with:
\begin{lyxcode}
./configure~CC=gcc2~CXX=g++2
\end{lyxcode}
Universal (ppc and i386) binaries can be produced on Mac OS X 10.4.x
with Xcode. Run 'configure' with:
\begin{lyxcode}
./configure~\textbackslash{}

LDFLAGS=\textquotedbl -Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk~-arch~i386~-arch~ppc\textquotedbl ~\textbackslash{}

CXXFLAGS~=~\textquotedbl -O2~-isysroot~/Developer/SDKs/MacOSX10.4u.sdk~-arch~i386~-arch~ppc\textquotedbl ~\textbackslash{}

CFLAGS~=~\textquotedbl -O2~-isysroot~/Developer/SDKs/MacOSX10.4u.sdk~-arch~i386~-arch~ppc\textquotedbl{}
\end{lyxcode}

\subsection{Cross compiling SDCC on Linux for Windows}

With the MinGW gcc cross compiler SDCC can be cross-compiled for Win32.
See section 'Configure Options'. SDCC requires boost, but the header-only
parts should be sufficient: Get a current boost tarball from www.boost.org,
unpack it, and choose suitable configure options so the headers are
found by the C++ compiler.

\subsection{Building SDCC using Cygwin and Mingw32}

For building and installing a Cygwin executable follow the instructions
for Linux.\\
\\
On Cygwin a ''native'' Win32-binary can be built, which will not
need the Cygwin-DLL. For the necessary 'configure' options see section
'configure options' or the script 'sdcc/support/scripts/sdcc\_cygwin\_mingw32'.\\
\\
In order to install Cygwin on Windows download setup.exe from www.cygwin.com
\url{http://www.cygwin.com/}. Run it, set the ''default text file
type'' to ''unix'' and download/install at least the following
packages. Some packages are selected by default, others will be automatically
selected because of dependencies with the manually selected packages.
Never deselect these packages!
\begin{itemize}
\item flex
\item bison
\item gcc ; version 3.x is fine, no need to use the old 2.9x
\item binutils ; selected with gcc
\item make
\item libboost-dev
\item rxvt ; a nice console, which makes life much easier under windoze
(see below)
\item man ; not really needed for building SDCC, but you'll miss it sooner
or later
\item less ; not really needed for building SDCC, but you'll miss it sooner
or later
\item svn ; only if you use Subversion access
\end{itemize}
If you want to develop something you'll need:
\begin{itemize}
\item python ; for the regression tests
\item gdb ; the gnu debugger, together with the nice GUI ''insight''
\item openssh ; to access the CF or commit changes
\item autoconf and autoconf-devel ; if you want to fight with 'configure',
don't use autoconf-stable!
\end{itemize}
rxvt is a nice console with history. Replace in your cygwin.bat the
line
\begin{lyxcode}
bash~-\/-login~-i~
\end{lyxcode}
with (one line):
\begin{lyxcode}
rxvt~-sl~1000~-fn~\textquotedbl Lucida~Console-12\textquotedbl ~-sr~-cr~red

~~~~~-bg~black~-fg~white~-geometry~100x65~-e~bash~-\/-login
\end{lyxcode}
Text selected with the mouse is automatically copied to the clipboard,
pasting works with shift-insert.\\
\\
The other good tip is to make sure you have no //c/-style paths anywhere,
use /cygdrive/c/ instead. Using // invokes a network lookup which
is very slow. If you think ''cygdrive'' is too long, you can change
it with e.g.
\begin{lyxcode}
mount~-s~-u~-c~/mnt
\end{lyxcode}
SDCC sources use the unix line ending LF. Life is much easier, if
you store the source tree on a drive which is mounted in binary mode.
And use an editor which can handle LF-only line endings. Make sure
not to commit files with Windows line endings. The tabulator spacing\index{tabulator spacing (8 columns)}
used in the project is 8. Although a tabulator spacing of 8 is a sensible
choice for programmers (it's a power of 2 and allows to display 8/16
bit signed variables without loosing columns) the plan is to move
towards using only spaces in the source.

\subsection{Building SDCC Using Microsoft Visual C++ 2010 (MSVC)}

TODO: This section is outdated. Current SDCC requires features noit
present in MSVC++ 2010. MSVC++ 2019 or newer is required.

Download the source package either from the SDCC Subversion repository
or from the snapshot builds \url{http://sdcc.sourceforge.net/snap.php},
it will be named something like sdcc-src-yyyymmdd-rrrr.tar.bz2. SDCC
is distributed with all the project, solution and other files you
need to build it using Visual C++ 2010 (except for ucSim). The solution
name is 'sdcc.sln'. Please note that as it is now, all the executables
are created in a folder called sdcc\textbackslash bin\_vc. Once built
you need to copy the executables from sdcc\textbackslash bin\_vc
to sdcc\textbackslash bin before running SDCC. \\
\\
Apart from the SDCC sources you also need to have the BOOST libraries
installed for MSVC. Get it here \url{http://www.boost.org/}\\
\\
In order to build SDCC with MSVC you need win32 executables of bison.exe,
flex.exe, and gawk.exe. One good place to get them is here \url{http://unxutils.sourceforge.net}\\
\\
If UnxUtils didn't work well, \index{msys}msys (\url{http://www.mingw.org/wiki/msys})
or msys2\index{msys2}(\url{https://msys2.github.io}) can be an alternative.\\
\\
Download the file UnxUtils\index{UnxUtils}.zip. Now you have to install
the utilities and setup MSVC so it can locate the required programs.
Here there are two alternatives (choose one!):
\begin{enumerate}
\item The easy way:\\
\\
a) Extract UnxUtils.zip to your C:\textbackslash{} hard disk PRESERVING
the original paths, otherwise bison won't work. (If you are using
WinZip make certain that 'Use folder names' is selected)\\
\\
b) Add 'C:\textbackslash user\textbackslash local\textbackslash wbin'
to VC++ Directories / Executable Directories.\\
\\
(As a side effect, you get a bunch of Unix utilities that could be
useful, such as diff and patch.)
\item A more compact way:\\
\\
This one avoids extracting a bunch of files you may not use, but requires
some extra work:\\
\\
a) Create a directory were to put the tools needed, or use a directory
already present. Say for example 'C:\textbackslash util'.\\
\\
b) Extract 'bison.exe', 'bison.hairy', 'bison.simple', 'flex.exe',
and gawk.exe to such directory WITHOUT preserving the original paths.
(If you are using WinZip make certain that 'Use folder names' is not
selected)\\
\\
c) Rename bison.exe to '\_bison.exe'.\\
\\
d) Create a batch file 'bison.bat' in 'C:\textbackslash util\textbackslash '
and add these lines:\\
~~set BISON\_SIMPLE=C:\textbackslash util\textbackslash bison.simple
\\
~~set BISON\_HAIRY=C:\textbackslash util\textbackslash bison.hairy\\
~~\_bison \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9\\
\\
Steps 'c' and 'd' are needed because bison requires by default that
the files 'bison.simple' and 'bison.hairy' reside in some weird Unix
directory, '/usr/local/share/' I think. So it is necessary to tell
bison where those files are located if they are not in such directory.
That is the function of the environment variables BISON\_SIMPLE and
BISON\_HAIRY.\\
\\
e) Add 'C:\textbackslash util' to VC++ Directories / Executable Directories.
Note that you can use any other path instead of 'C:\textbackslash util',
even the path where the Visual C++ tools are, probably: 'C:\textbackslash Program
Files\textbackslash Microsoft Visual Studio\textbackslash Common\textbackslash Tools'.
So you don't have to execute step 'e' :)
\end{enumerate}
That is it. Open 'sdcc.sln' in Visual Studio, click 'build all', when
it finishes copy the executables from sdcc\textbackslash bin\_vc
to sdcc\textbackslash bin, and you can compile using SDCC.

\subsection{Windows Install Using a ZIP Package}
\begin{enumerate}
\item Download the binary zip package from \url{http://sdcc.sf.net/snap.php}
and unpack it using your favorite unpacking tool (gunzip, WinZip,
etc). This should unpack to a group of sub-directories. An example
directory structure after unpacking the mingw32 package is: C:\textbackslash sdcc\textbackslash bin
for the executables, C:\textbackslash sdcc\textbackslash include
and C:\textbackslash sdcc\textbackslash lib for the include and
libraries.
\item Adjust your environment variable PATH to include the location of the
bin directory or start sdcc using the full path.
\end{enumerate}

\subsection{Windows Install Using the Setup Program\label{subsec:Windows-Install}}

Download the setup program \emph{sdcc-x.y.z-setup.exe} for an official
release from\\
\url{http://sourceforge.net/projects/sdcc/files/} or a setup program
for one of the snapshots \emph{sdcc-yyyymmdd-xxxx-setup.exe} from
\url{http://sdcc.sourceforge.net/snap.php} and execute it. A Windows
typical installer will guide you through the installation process.

\subsection{VPATH\index{VPATH} feature}

SDCC supports the VPATH feature provided by configure and make. It
allows to separate the source and build trees. Here's an example:

\texttt{cd \textasciitilde ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\#
cd \$HOME}

\texttt{tar -xjf sdcc-src-yyyymmdd-rrrr.tar.bz2~\# extract source
to directory sdcc}

\texttt{mkdir sdcc.build~~~~~~~~~~~~~~~~~~~~~~~~\#
put output in sdcc.build}

\texttt{cd sdcc.build}

\texttt{../sdcc/configure~~~~~~~~~~~~~~~~~~~~~~~\#
configure is doing all the magic!}

\texttt{make}

\noindent That's it! \textbf{configure} will create the directory
tree will all the necessary Makefiles in \textasciitilde /sdcc.build.
It automagically computes the variables srcdir, top\_srcdir and top\_buildir
for each directory. After running \textbf{make} the generated files
will be in \textasciitilde /sdcc.build, while the source files stay
in \textasciitilde /sdcc.\\
This is not only usefull for building different binaries, e.g. when
cross compiling. It also gives you a much better overview in the source
tree when all the generated files are not scattered between the source
files. And the best thing is: if you want to change a file you can
leave the original file untouched in the source directory. Simply
copy it to the build directory, edit it, enter `make clean', `rm Makefile.dep'
and `make'. \textbf{make} will do the rest for you!

\section{Building the Documentation}

Add -\/-enable-doc to the configure arguments to build the documentation
together with all the other stuff. You will need several tools (\LyX ,
\LaTeX , \LaTeX 2HTML, pdflatex, dvipdf, dvips and makeindex) to get
the job done. Another possibility is to change to the doc directory
and to type \textsf{\textbf{''make''}} there. You're invited to
make changes and additions to this manual (sdcc/doc/sdccman.lyx).
Using \LyX{} \url{http://www.lyx.org} as editor is straightforward.
Prebuilt documentation is available from \url{http://sdcc.sourceforge.net/snap.php}.

\section{Reading the Documentation\index{Documentation}}

Currently, reading the document in PDF format is recommended, as for
unknown reason the hyperlinks are working there whereas in the HTML
version they are not\footnote{If you should know why please drop us a note}.\\
You'll find the PDF version\index{PDF version of this document} at
\url{http://sdcc.sourceforge.net/doc/sdccman.pdf}.\\
This documentation is in some aspects different from a commercial
documentation: 
\begin{itemize}
\item It tries to document SDCC for several processor architectures in one
document (commercially these probably would be separate documents/products).
This document\index{Status of documentation} currently matches SDCC
for mcs51 and DS390 best and does give too few information about f.e.
Z80, PIC14, PIC16 and HC08.
\item There are many references pointing away from this documentation. Don't
let this distract you. If there f.e. was a reference like \url{http://www.opencores.org}
together with a statement ''some processors which are targeted by
SDCC can be implemented in a \emph{f}ield \emph{p}rogrammable \emph{g}ate
\emph{a}rray\index{FPGA (field programmable gate array)}'' or \url{http://sourceforge.net/projects/fpgac/}\index{FpgaC ((subset of) C to FPGA compiler)}
''have you ever heard of an open source compiler that compiles a
subset of C for an FPGA?'' we expect you to have a quick look there
and come back. If you read this you are on the right track.
\item Some sections attribute more space to problems, restrictions and warnings
than to the solution.
\item The installation section and the section about the debugger is intimidating.
\item There are still lots of typos and there are more different writing
styles than pictures.
\end{itemize}

\section{Testing the SDCC Compiler\label{sec:Testing-the-SDCC}}

The first thing you should do after installing your SDCC compiler
is to see if it runs. Type \textsf{\textbf{\textquotedbl sdcc -\/-version\textquotedbl\index{version}}}
at the prompt, and the program should run and output its version like:
\\
\texttt{SDCC : mcs51/z80/z180/r2k/r2ka/r3ka/sm83/tlcs90/ez80\_z80/z80n/r800/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8/pdk13/pdk14/pdk15/mos6502/mos65c02
4.4.0 \#14546 (Linux)}

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 section \ref{subsec:Install-Trouble-shooting}~Install
trouble-shooting for suggestions). Make sure that the sdcc program
is in the bin folder, if not perhaps something did not install correctly.\\
\\
SDCC is commonly installed as described in section ''Install and
search paths''.\\
\\
Make sure the compiler works on a very simple example. Type in the
following test.c program using your favorite ASCII editor:
\begin{verse}
\texttt{char test;}~\\
\texttt{}~\\
\texttt{void main(void) \{}~\\
\texttt{~~~~test=0;}~\\
\texttt{\}}
\end{verse}
Compile this using the following command: \textsf{\textbf{\textquotedbl sdcc
-c test.c\textquotedbl .}} 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 \textsf{\textbf{\textquotedbl sdcc
test.c}}\textquotedbl . 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 section \ref{subsec:Install-Trouble-shooting}~Install
trouble-shooting for suggestions).\\
\\
The final test is to ensure SDCC can use the standard header files
and libraries. Edit test.c and change it to the following:
\begin{verse}
\texttt{\#include <string.h>}~\\
\texttt{}~\\
\texttt{char str1{[}10{]};}~\\
\texttt{}~\\
\texttt{void main(void) \{}~\\
\texttt{~~strcpy(str1, \textquotedbl testing\textquotedbl );}~\\
\texttt{\}}
\end{verse}
Compile this by typing \textsf{\textbf{\textquotedbl sdcc test.c\textquotedbl}}.
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 section \ref{subsec:Install-Trouble-shooting}~Install
trouble-shooting section for suggestions). Use option \textbf{-\/-print-search-dirs}\index{-/-print-search-dirs@-\/-print-search-dirs}
to find exactly where SDCC is looking for the include and lib files.

\section{Install Trouble-shooting\label{subsec:Install-Trouble-shooting}\index{Install trouble-shooting}}

\subsection{If SDCC does not build correctly}

A thing to try is starting from scratch by unpacking the .tgz source
package again in an empty directory. Configure it like:\\
\\
\textsf{\textbf{./configure 2>\&1 | tee configure.log}}\\
\\
and build it like:\\
\\
\textsf{\textbf{make 2>\&1 | tee make.log}}\\
\\
If anything goes wrong, you can review the log files to locate the
problem. Or a relevant part of this can be attached to an email that
could be helpful when requesting help from the mailing list.

\subsection{What the \textquotedblright ./configure\textquotedblright{} does}

The ''./configure'' command is a script that analyzes your system
and performs some configuration to ensure the source package compiles
on your system. It will take a few minutes to run, and will compile
a few tests to determine what compiler features are installed.

\subsection{What the \textquotedblright make\textquotedblright{} does}

This runs the GNU make tool, which automatically compiles all the
source packages into the final installed binary executables.

\subsection{What the \textquotedblright make install\textquotedblright{} command
does.}

This will install the compiler, other executables libraries and include
files into the appropriate directories. See sections \ref{subsec:Install-paths},~\ref{subsec:Search-Paths}~about
install and search paths.\\
On most systems you will need super-user privileges to do this.

\section{Components of SDCC}

SDCC is not just a compiler, but a collection of tools by various
developers. These include linkers, assemblers, simulators and other
components. Here is a summary of some of the components. Note that
the included simulator and assembler have separate documentation which
you can find in the source package in their respective directories.
As SDCC grows to include support for other processors, other packages
from various developers are included and may have their own sets of
documentation.\\
\\
You might want to look at the files which are installed in <installdir>.
At the time of this writing, we find the following programs, among
others, for gcc-builds:\\
 \\
In <installdir>/bin:
\begin{itemize}
\item sdcc - The compiler.
\item sdcpp - The C preprocessor.
\item sdas8051 - The assembler for 8051 type processors.
\item sdas390 - The assembler for DS80C390 processor.
\item sdasz80\textbf{,} sdasgb - The Z80 and GameBoy Z80 assemblers.
\item sdas6808 - The 6808 assembler.
\item sdasstm8 - The STM8 assembler.
\item sdld -The linker for 8051 and STM8 type processors.
\item sdldz80\textbf{,} sdldgb - The Z80 and GameBoy Z80 linkers.
\item sdld6808 - The 6808 linker.
\item ucsim\_51, s51 - The ucSim 8051 simulator.
\item ucsim\_m68hc08 - The ucSim 6808 simulator.
\item ucsim\_stm8 - The ucSim STM8 simulator.
\item ucsim\_z80 - The ucSim Z80 simulator.
\item sdcdb - The source debugger.
\item sdar, sdranlib, sdnm, sdobjcopy - The sdcc archive managing and indexing
utilites.
\item packihx - A tool to pack (compress) Intel hex files.
\item makebin - A tool to convert Intel Hex file to a binary and GameBoy
binary image file format.
\end{itemize}
In <installdir>/share/sdcc/include
\begin{itemize}
\item the include files
\end{itemize}
In <installdir>/share/sdcc/non-free/include
\begin{itemize}
\item the non-free include files
\end{itemize}
In <installdir>/share/sdcc/lib
\begin{itemize}
\item the src and target subdirectories with the precompiled relocatables.
\end{itemize}
In <installdir>/share/sdcc/non-free/lib
\begin{itemize}
\item the src and target subdirectories with the non-free precompiled relocatables.
\end{itemize}
In <installdir>/share/sdcc/doc
\begin{itemize}
\item the documentation
\end{itemize}

\subsection{sdcc - The Compiler}

This is the actual compiler, it in turn uses the C-preprocessor and
invokes the assembler and linkage editor.

\subsection{sdcpp - The C-Preprocessor\index{Preprocessor}}

The preprocessor\index{sdcpp (preprocessor)} is a modified version
of the GNU cpp\index{cpp|see{sdcpp}} preprocessor \url{http://gcc.gnu.org/}.
The C preprocessor is used to pull in \#include sources, process \#ifdef
statements, \#defines and so on.

\subsection{sdas, sdld - The Assemblers and Linkage Editors}

This is a set of retargettable assemblers and linkage editors, which
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 SDCC. 

SDCC used an about 1998 branch of asxxxx version 2.0 which unfortunately
is not compatible with the more advanced (f.e. macros, more targets)
ASxxxx Cross Assemblers nowadays available from Alan Baldwin \url{https://shop-pdp.net/}.
In 2009 Alan made his ASxxxx Cross Assemblers version 5.0 available
under the GPL license (GPLv3 or later), so a reunion is now a work
in progress. Thanks Alan!

\subsection{ucsim\_51, ucsim\_z80, ucsim\_stm8 etc. - The Simulators}

ucsim\_51 (or s51)\index{s51 (simulator)}, ucsim\_z80\index{sz80 (simulator)}
ucsim\_m68hc08\index{shc08 (simulator)} and ucsim\_stm8 \index{sstm8 (simulator)},
as well as similarly named programs provided with SDCC, are free open
source simulators developed by Daniel Drotos. The simulators are built
as part of the build process. For more information visit Daniel's
web site at: \url{http://mazsola.iit.uni-miskolc.hu/~drdani/embedded/s51}.
It currently supports the core mcs51, the Dallas DS80C390, the Phillips
XA51 family, the Z80, 6808 the STM8 and various others.

\subsection{sdcdb - Source Level Debugger}

SDCDB\index{SDCDB (debugger)} is the companion source level debugger.
More about SDCDB in section \ref{cha:Debugging-with-SDCDB}. The current
version of the debugger uses Daniel's Simulator S51\index{s51 (simulator)},
but can be easily changed to use other simulators.

\chapter{Using SDCC}

\section{Standard-Compliance\index{Standard-compliance}\label{subsec:Standard-Compliance}}

SDCC aims to be a conforming freestanding implementation of the C
programming language. The latest publicly available version of the
standard \emph{ISO/IEC 9899 - Programming languages - C} should be
available at: \url{https://www.open-std.org/jtc1/sc22/wg14/www/projects\#9899}.

\subsection{ISO C90 and ANSI C89}

Use \textbf{\code{\textbf{-{}-std-c90}}\index{-/-std-c90@-\/-std-c90}}
to compile in this mode.


\subsubsection*{Deviations from standard compliance}
\begin{itemize}
\item initialization of structure arrays must be fully braced.

\begin{verse}
\texttt{struct s \{ char x \} a{[}{]} = \{1, 2\};~~~~~/{*} invalid
in SDCC {*}/}~\\
\texttt{struct s \{ char x \} a{[}{]} = \{\{1\}, \{2\}\}; /{*} OK
{*}/}
\end{verse}
\item \code{float}\index{Floating point support} is substituted for (\code{long})
\code{double}\index{double (not supported)} and a warning is emitted.
\item K\&R style\index{K&R style@K\&R style} functions are syntactically
supported, but with the semantics of ISO style functions.
\end{itemize}

\subsubsection*{Features missing in some ports}
\begin{itemize}
\item pic14, pic16: structures\index{struct} and unions\index{union} cannot
be passed as function parameters
\item hc08, s08, mos6502, pic14, pic16: they cannot be a return value\index{return value}
from a function, e.g.:

\begin{verse}
\texttt{struct s \{ ... \};}~\\
\texttt{\textbf{struct}} \texttt{s foo1 (}\texttt{\textbf{struct}}
\texttt{s parms) /{*} unsupported in these SDCC ports {*}/}~\\
\texttt{\{}~\\
\texttt{~~~~struct s rets;}~\\
\texttt{~~~~...}~\\
\texttt{~~~~return rets; /{*} unsupported in these SDCC ports
{*}/}~\\
\texttt{\}}
\end{verse}
\item mcs51, ds390, hc08, s08, pdk13, pdk14, pdk15 and mos6502 ports: functions
are not reentrant unless explicitly declared as such or \textbf{\code{\textbf{-{}-}stack-auto}}
is specified.
\end{itemize}

\subsection{ISO C95}

Use \textbf{\code{\textbf{-{}-std-c95}}\index{-/-std-c95@-\/-std-c95}}
to compile in this mode.

\subsubsection*{Implementation status}

Except for the issues mentioned in the section above, this standard
is supported.

\subsection{ISO C99}

Use \textbf{\code{\textbf{-{}-std-c99}}\index{-/-std-c99@-\/-std-c99}}
to compile in this mode.

\subsubsection*{Deviations from standard compliance}

In addition to what is mentioned in the section above, the following
features of this standard are not supported by SDCC:
\begin{itemize}
\item Compound literals. 
\item Objects of variably-modified types.
\item \code{ptrdiff\_t} has 16 bits, while the standard requires at least
17 bits.
\end{itemize}

\subsubsection*{Features missing in some ports}
\begin{itemize}
\item pic14: there is no support for 64 bit integer types. 
\end{itemize}

\subsection{ISO C11 and ISO C17}

Use \textbf{\code{\textbf{-{}-std-c11}}\index{-/-std-c11@-\/-std-c11}}
to compile in this mode.

\subsubsection*{Implementation status}

Except for the issues mentioned in the section above, this standard
is supported. Note: Variably-modified types became optional in this
version.

\subsection{ISO C23}

Use \textbf{\code{\textbf{-{}-std-c23}}\index{-/-std-c23@-\/-std-c23}}
to compile in this mode.

\subsubsection*{Deviations from standard compliance}
\begin{itemize}
\item initialization of structure arrays must be fully braced.

\begin{verse}
\texttt{struct s \{ char x \} a{[}{]} = \{1, 2\};~~~~~/{*} invalid
in SDCC {*}/}~\\
\texttt{struct s \{ char x \} a{[}{]} = \{\{1\}, \{2\}\}; /{*} OK
{*}/}
\end{verse}
\item \code{float}\index{Floating point support} is substituted for (\code{long})
\code{double}\index{double (not supported)} and a warning is emitted.
\item Compound literals are not supported.
\item Support for attributes is slightly incomplete.
\item Checked integer arithmetic is not supported for (\code{unsigned})
\code{long long}.
\item Qualifier-preserving standard library functions are not implemented.
\item \code{constexpr} is not implemented.
\end{itemize}

\subsubsection*{Features missing in some ports}
\begin{itemize}
\item pic14, pic16: structures\index{struct} and unions\index{union} cannot
be passed as function parameters
\item hc08, s08, mos6502, pic14, pic16: they cannot be a return value\index{return value}
from a function, e.g.:

\begin{verse}
\texttt{struct s \{ ... \};}~\\
\texttt{\textbf{struct}} \texttt{s foo1 (}\texttt{\textbf{struct}}
\texttt{s parms) /{*} unsupported in these SDCC ports {*}/}~\\
\texttt{\{}~\\
\texttt{~~~~struct s rets;}~\\
\texttt{~~~~...}~\\
\texttt{~~~~return rets; /{*} unsupported in these SDCC ports
{*}/}~\\
\texttt{\}}
\end{verse}
\item mcs51, ds390, hc08, s08, pdk13, pdk14, pdk15 and mos6502 ports: functions
are not reentrant unless explicitly declared as such or \textbf{\code{\textbf{-{}-}stack-auto}}
is specified.
\item pic14: there is no support for 64 bit integer types. 
\item pic14, pic16: \code{\_BitInt} is not supported.
\end{itemize}

\subsection{ISO C2y preview}

Use \textbf{\code{\textbf{-{}-std-c2y}}\index{-/-std-c2y@-\/-std-c2y}}
to compile in this mode.

\subsubsection*{Implementation status}

In anticipation of the upcoming version of the language standard,
C2y, SDCC supports the following prospective features:
\begin{itemize}
\item \href{https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3260.pdf}{N3260}:
\code{\_Generic} selection expression with a type operand
\item \href{https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3370.htm}{N3370}:
Case range expressions
\end{itemize}

\subsection{Embedded C}

SDCC supports objects in named address spaces and to some degree pointers
to such objects. The support for fixed-point math in SDCC is inconsistent
with the standard. Other parts of the standard are not supported.

\subsection{Implementation-defined behavior}

\subsubsection{Translation}
\begin{itemize}
\item Diagnostics are output to stderr, in the format <filename>:<line-number>:
<warning|error> <diagnostic-number>: <diagnostic-description>
\item Nonempty sequences of white-space are retained in translation phase
3.
\end{itemize}

\subsubsection{Environment}
\begin{itemize}
\item See SDCC source (and your own code if you use a custom crt0 for a
target that supports it) for any information on the environment.
\end{itemize}

\subsubsection{Identifiers}
\begin{itemize}
\item See the compiler and assembler source for information on characters
that may appear in identifiers and on the number of significant initial
characters.
\end{itemize}

\subsubsection{Characters}
\begin{itemize}
\item There are 8 bits in a byte.
\item Values of members of the execution character set: TODO.
\item Values of members of the execution character set for escape sequences:
TODO.
\item Value of char with something weird stored in it: TODO.
\item unsigned char has the same range, representation and behavior as ''plain''
char (unless -\textbf{\/}-fsigned-char\textbf{\index{-/-fsigned-char@-\/-fsigned-char}}
is used).
\item See the SDCC source for further information on character sets.
\end{itemize}

\subsubsection{Integers}
\begin{itemize}
\item There are no extended integer types.
\end{itemize}

\subsubsection{Floating point}
\begin{itemize}
\item See the implementation (soft float library) for any information on
floating point.
\end{itemize}

\subsubsection{Arrays and Pointers}
\begin{itemize}
\item For the result of converting between pointers and integers see the
SDCC source code.
\item For the size of the result of subtracting two pointers to elements
of the same array see the SDCC source code.
\end{itemize}

\subsubsection{Hints}
\begin{itemize}
\item The extend to which suggestions made by register are effective depends
on the target.
\item SDCC will inline functions if and only if they are declared using
inline and do not have variable arguments.
\end{itemize}

\subsubsection{Structures, unions, enumerations and bit-fields}
\begin{itemize}
\item A plain int bit-field is treated as an unsigned int bit-field.
\item There are no allowed bit-field types other than \_Bool, int, signed
int, unsigned int and the bit-precise integer types.
\item Atomic types are not permitted for bit-fields.
\item If a bit-fields does not fit into the same byte as the previous bit-fields,
it starts on the next byte.
\item bit-fields are allocated in the same order as they appear in the source.
\item Non-bit-field members of structures are aligned on byte boundaries
(i.e. there are no padding bytes).
\item For enumerations, the compatible type is the first from the following
list that fits the constants: bool, unsigned char, signed char, unsigned
int, signed int, unsigned long int, signed long int, unsigned long
long int, signed long long int.
\end{itemize}

\subsubsection{Qualifiers}
\begin{itemize}
\item SDCC shall preserve all volatile reads and writes, but does not guarantee
them to be atomic (except for atomic types and volatile sig\_atomic\_t).
\end{itemize}

\subsubsection{Preprocessing directives}
\begin{itemize}
\item See the preprocessor source for information on preprocessing directives.
\end{itemize}

\subsubsection{Library functions}
\begin{itemize}
\item See the respective library headers for the library functions available.
\item See assert.h and library source for the format of the diagnostic printed
by the assert macro.
\item There is no fegetexceptflag function.
\item There is no feraiseexcept function.
\item There is no setlocale function.
\item There is no FLT\_EVAL\_METHOD macro.
\item There is no DEC\_EVAL\_METHOD macro.
\item There are no non-required domain errors for mathematics functions.
\item See library source for the values returned by mathematical functions
on domain error and pole error (and anything else on mathematical
functions and floating type encodings).
\item See library headers for the null-pointer constant to which NULL expands.
\item See library headers and source for anything else about the library.
\end{itemize}

\subsubsection{Architecture}
\begin{itemize}
\item See the respective library headers for the values or expressions for
macros specified in float.h, limits.h, stdint.h.
\item Multithreading is not supported.
\item The number of bytes in any object is the minimum allowed (except for
some padding bits on bit-fields), byte order depends on the target.
\item No extended alignments are supported.
\item There are no valid alignments other than those returned by \_Alignof.
\item sizeof always returns the smallest value allowed assuming an 8-bit
char. \_Alignof always returns 0.
\end{itemize}

\section{Compiling}

\subsection{Single Source File Projects}

For single source file 8051 projects the process is very simple. Compile
your programs with the following command \textsf{\textbf{\textquotedbl sdcc
sourcefile.c\textquotedbl .}} This will compile, assemble and link
your source file. Output files are as follows:
\begin{itemize}
\item sourcefile.asm\index{<file>.asm} - Assembler source\index{Assembler source}
file created by the compiler
\item sourcefile.lst\index{<file>.lst} - Assembler listing\index{Assembler listing}
file created by the Assembler
\item sourcefile.rst\index{<file>.rst} - Assembler listing\index{Assembler listing}
file updated with linkedit information, created by linkage editor
\item sourcefile.sym\index{<file>.sym} - symbol listing\index{Symbol listing}
for the sourcefile, created by the assembler
\item sourcefile.rel\index{<file>.rel} - Object file\index{Object file}
created by the assembler, input to Linkage editor
\item sourcefile.map\index{<file>.map} - The memory map\index{Memory map}
for the load module, created by the Linker
\item sourcefile.mem\index{<file>.mem} - A file with a summary of the memory
usage
\item sourcefile.ihx\index{<file>.ihx} - The load module in Intel hex format\index{Intel hex format}
(you can select the Motorola S19 format\index{Motorola S19 format}
with -\/-out-fmt-s19\index{-/-out-fmt-s19@-\/-out-fmt-s19}. If you
need another format you might want to use \textsf{\textit{objdump}}\index{objdump (tool)}
or \textsf{\textit{srecord}}\index{srecord (bin, hex, ... tool)}
- see also section \vref{subsec:Postprocessing-the-Intel}). Both
formats are documented in the documentation of srecord\index{srecord (bin, hex, ... tool)}
\item sourcefile.adb\index{<file>.adb} - An intermediate file containing
debug information needed to create the .cdb file (with -\/-debug\index{-/-debug@-\/-debug}) 
\item sourcefile.cdb\index{<file>.cdb} - An optional file (with -\/-debug)
containing debug information. The format is documented in cdbfileformat.pdf
\item sourcefile.omf\index{<file>.omf} - An optional AOMF or AOMF51\index{AOMF, AOMF51}
\label{OMF file}file containing debug information (generated with
option -\/-debug). The (Intel) \emph{a}bsolute \emph{o}bject \emph{m}odule
\emph{f}ormat is a subformat of the OMF51 format and is commonly used
by third party tools (debuggers\index{Debugger}, simulators, emulators).
\item sourcefile.dump{*}\index{<file>.dump{*}} - Dump file to debug the
compiler it self (generated with option -\/-dumpall) (see section
\ref{subsec:Intermediate-Dump-Options}~ and section \ref{subsec:The-anatomy-of}~''Anatomy
of the compiler'').
\end{itemize}

\subsection{Postprocessing the Intel Hex\index{Intel hex format} file\label{subsec:Postprocessing-the-Intel}}

In most cases this won't be needed but the Intel Hex file\index{<file>.ihx}
which is generated by SDCC might include lines of varying length and
the addresses within the file are not guaranteed to be strictly ascending.
If your toolchain or a bootloader does not like this you can use the
tool \texttt{packihx}\index{packihx (tool)} which is part of the
SDCC distribution: \\
\\
 \textsf{\textbf{packihx sourcefile.ihx >sourcefile.hex}}\\
\\
The separately available \emph{srecord}\index{srecord (bin, hex, ... tool)}
package additionally allows to set undefined locations to a predefined
value, to insert checksums\index{checksum} of various flavours (crc,
add, xor) and to perform other manipulations (convert, split, crop,
offset, ...). \\
\\
\textsf{\textbf{srec\_cat~~sourcefile.ihx -intel~~-o sourcefile.hex
-intel}}\\
\textsf{\textbf{}}\\
An example for a more complex command line\footnote{the command backfills\index{backfill unused memory} unused memory
with 0x12 and the overall 16 bit sum of the complete 64 kByte block
is zero. If the program counter on an mcs51 runs wild the backfill
pattern 0x12 will be interpreted as an \texttt{lcall} to address \texttt{0x1212}
(where an emergency routine could sit).} could look like:\\
\\
{\footnotesize\textsf{\textbf{srec\_cat~sourcefile.ihx -intel~~-fill
0x12 0x0000 0xfffe~-little-endian-checksum-negative 0xfffe 0x02 0x02~~-o
sourcefile.hex -intel}}}\textsf{\textbf{}}\\
\textsf{\textbf{}}\\
The srecord package is available at \url{http://sourceforge.net/projects/srecord/}.

\subsection{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)\\
foo2.c (contains some more functions)\\
foomain.c (contains more functions and the function main)\\
{\footnotesize}\\
The first two files will need to be compiled separately with the commands:\\
\\
\textsf{\textbf{sdcc~-c~foo1.c}}{\footnotesize}\\
\textsf{\textbf{sdcc~-c~foo2.c}}\\
\\
Then compile the source file containing the \emph{main()} function
and link\index{Linker} the files together with the following command:\\
\\
\textsf{\textbf{sdcc~foomain.c~foo1.rel~foo2.rel}}\index{<file>.rel}\\
\\
Note that in this case, \strong{the source file being compiled is always linked in first},
regardless of its position in the command line. This can be problematic
when a custom CRT is supplied as object file. As an alternative to
the above, \emph{foomain.c} can be compiled separately, and the resulting
object file can then be linked with the other object files using a
separate command:\textsf{\textbf{}}\\
\textsf{\textbf{}}\\
\textsf{\textbf{sdcc~-c~foomain.c}}\\
\textsf{\textbf{sdcc foomain.rel foo1.rel foo2.rel}}\\
\textsf{\textbf{}}\\
\strong{The file containing the \emph{main()} function must be the first file
specified in the command line}, since the linkage editor processes object files in the order they
are presented to it. The linker is invoked from SDCC using a script
file with extension .lnk\index{<file>.lnk}. You can view this file
to troubleshoot linking problems such as those arising from missing
libraries.

\subsection{Projects with Additional Libraries\index{Libraries}}

Some reusable routines may be compiled into a library, see the documentation
for the assembler and linkage editor (which are in <installdir>/share/sdcc/doc)
for how to create a \emph{.lib\index{<file>.lib}} library file. Section
\ref{subsec:Using-sdar-to} below contains a minimal example. 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 \emph{foomain.c}
and a library \emph{foolib.lib} in the directory \emph{mylib} (if
that is not the same as your current project):\\
\\
\textsf{\textbf{sdcc foomain.c foolib.lib -L mylib}}\\
\textsf{\textbf{}}\\
Note here that \emph{mylib} must be an absolute path name.\\
\\
The most efficient way to use libraries is to keep separate modules
in separate source files. The lib file now should name all the modules.rel\index{<file>.rel}
files. For an example see the standard library file \emph{libsdcc.lib}
in the directory <installdir>/share/lib/small.

\subsection{Using sdar to Create and Manage Libraries\index{sdar}\label{subsec:Using-sdar-to}}

Support for sdar format libraries was introduced in SDCC 2.9.0.\textbf{}\\
\textbf{}\\
Both the GNU and BSD ar format variants are supported by sdld linkers.\textbf{}\\
\textbf{}\\
To create a library containing sdas object files, you should use the
following sequence:\textbf{}\\

\textsf{\textbf{sdar -rc <library name>.lib <list of .rel files>}}

\section{Command Line Options\index{Command Line Options}\label{sec:Command-Line-Options}}

\subsection{Processor Selection Options\index{Options processor selection}\index{Processor selection options}}
\begin{lyxlist}{00.00.0000}
\item [{\textbf{-mmcs51\index{-mmcs51}}}] Generate code for the Intel
MCS51\index{MCS51} family of processors. This is the default processor
target.
\item [{\textbf{-mds390\index{-mds390}}}] Generate code for the Dallas
DS80C390\index{DS80C390} processor.
\item [{\textbf{-mds400\index{-mds400}}}] Generate code for the Dallas
DS80C400\index{DS80C400} processor.
\item [{\textbf{-mhc08\index{-mhc08}}}] Generate code for the Freescale/Motorola
HC08 (aka 68HC08) \index{HC08} family of processors.
\item [{\textbf{-ms08\index{-ms08}}}] Generate code for the Freescale/Motorola
S08 (aka 68HCS08, HCS08, CS08) \index{S08} family of processors.
\item [{\textbf{-mz80\index{-mz80}}}] Generate code for the Zilog Z80\index{Z80}
family of processors.
\item [{\textbf{-mz180\index{-mz180}}}] Generate code for the Zilog Z180\index{Z180}
family of processors.
\item [{\textbf{-mr2k\index{-mr2k}}}] Generate code for the Rabbit 2000
/ Rabbit 3000 family of processors.
\item [{\textbf{-mr3ka\index{-mr3ka}}}] Generate code for the Rabbit 3000A
family of processors.
\item [{\textbf{-msm83\index{-msm83}}}] Generate code for the Sharp SM83\index{sm83 (GameBoy Z80)}
processor.
\item [{\textbf{-mtlcs90\index{-mtlcs90}}}] Generate code for the Toshiba
TLCS-90 processor.
\item [{\textbf{-mez80\_z80\index{-mez80_z80@-mez80\_z80}}}] Generate
code for the Zilog eZ80 processor in Z80 mode.
\item [{\textbf{-mstm8\index{-mstm8}}}] Generate code for the STMicroelectronics
STM8 family of processors.
\item [{\textbf{-mpdk13\index{-mpdk13}}}] Generate code for Padauk processors
with 13 bit wide program memory.
\item [{\textbf{-mpdk14\index{-mpdk14}}}] Generate code for Padauk processors
with 14 bit wide program memory.
\item [{\textbf{-mpdk15\index{-mpdk15}}}] Generate code for Padauk processors
with 15 bit wide program memory.
\item [{\textbf{-mpic14\index{-mpic14}}}] Generate code for the Microchip
PIC 14\index{PIC14}-bit processors (p16f84 and variants. In development,
not complete).
\end{lyxlist}

\begin{lyxlist}{00.00.0000}
\item [{\textbf{-mpic16\index{-mpic16}}}] Generate code for the Microchip
PIC 16\index{PIC16}-bit processors (p18f452 and variants. In development,
not complete).
\item [{\textbf{-mmos6502\index{-mmos6502}}}] Generate code for the original
MOS Technology NMOS 6502 processor and compatible derivatives including
the 6510 and 8502.
\item [{\textbf{-mmos65c02\index{-mmos65c02}}}] Generate code for the
CMOS Rockwell/WDC 65C02. 
\end{lyxlist}
SDCC inspects the program name it was called with so the processor
family can also be selected by renaming the sdcc binary (to f.e. z80-sdcc)
or by calling SDCC from a suitable link. Option -m has higher priority
than setting from program name.

\subsection{Preprocessor Options\index{Options preprocessor}\index{Preprocessor!Options}\index{sdcpp (preprocessor)}}

SDCC uses \textit{sdcpp}, an adapted version of the GNU Compiler Collection\index{gcc (GNU Compiler Collection)}
preprocessor \emph{cpp}\index{cpp|see{sdcpp}} (\emph{gcc} \url{http://gcc.gnu.org/}).
If you need more dedicated options than those listed below please
refer to the GCC~CPP~Manual at \url{http://www.gnu.org/software/gcc/onlinedocs/}.
\begin{lyxlist}{00.00.0000}
\item [{\textbf{-I<path>\index{-I<path>}}}] The additional location where
the preprocessor will look for <..h> or ``..h'' files.
\item [{\textbf{-D<macro{[}=value{]}>\index{-D<macro{[}=value{]}>}}}] Command
line definition of macros. Passed to the preprocessor.
\item [{\textbf{-M\index{-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 `\textbackslash '-newline if it is long.
The list of rules is printed on standard output instead of the preprocessed
C program. `-M' implies `-E\index{-E}'.
\item [{\textbf{-C\index{-C}}}] Tell the preprocessor not to discard comments.
Used with the `-E' option.
\item [{\textbf{-MM\index{-MM}}}] Like `-M' but the output mentions only
the user header files included with `\#include ``file\textquotedbl '.
System header files included with `\#include <file>' are omitted.
\item [{\textbf{-Aquestion(answer)\index{-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.
\item [{\textbf{-Umacro\index{-Umacro}}}] Undefine macro macro. `-U' options
are evaluated after all `-D' options, but before any `-include' and
`-imacros' options.
\item [{\textbf{-dM\index{-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.
\item [{\textbf{-dD\index{-dD}}}] Tell the preprocessor to pass all macro
definitions into the output, in their proper sequence in the rest
of the output.
\item [{\textbf{-dN\index{-dN}}}] Like `-dD' except that the macro arguments
and contents are omitted. Only `\#define name' is included in the
output.
\item [{\textbf{-Wp~preprocessorOption{[},preprocessorOption{]}}\index{-Wp preprocessorOption{[},preprocessorOption{]}}...}] Pass
the preprocessorOption to the preprocessor \texttt{sdcpp}\index{sdcpp (preprocessor)}. 
\end{lyxlist}

\subsection{Optimization Options\index{Options optimization}\index{Optimization options}}
\begin{lyxlist}{00.00.0000}
\item [{\textbf{-\/-nogcse\index{-/-nogcse@-\/-nogcse}}}] Will not do
global common subexpression elimination, this option may be used when
the compiler creates undesirably large stack/data spaces to store
compiler temporaries (\emph{s}pill \emph{loc}ations, sloc\index{sloc (spill location)}).
A warning message will be generated when this happens and the compiler
will indicate the number of extra bytes it allocated. It is recommended
that this option NOT be used, \#pragma~nogcse\index{#pragma nogcse@\#pragma nogcse}
can be used to turn off global subexpression elimination\index{Subexpression elimination}
for a given function only.
\item [{\textbf{-\/-noinvariant\index{-/-noinvariant@-\/-noinvariant}}}] Will
not do loop invariant optimizations, this may be turned off for reasons
explained for the previous option. For more details of loop optimizations
performed see Loop Invariants in section \ref{subsec:Loop-Optimizations}.
It is recommended that this option NOT be used, \#pragma~noinvariant\index{#pragma noinvariant@\#pragma noinvariant}
can be used to turn off invariant optimizations for a given function
only.
\item [{\textbf{-\/-noinduction\index{-/-noinduction@-\/-noinduction}}}] Will
not do loop induction optimizations, see section strength reduction
for more details. It is recommended that this option is NOT used,
\#pragma~noinduction\index{#pragma noinduction@\#pragma noinduction}
can be used to turn off induction optimizations for a given function
only.
\item [{\textbf{-\/-noloopreverse\index{-/-noloopreverse@-\/-noloopreverse}}}] Will
not do loop reversal \index{Loop reversing}optimization.
\item [{-\/-\textbf{nolabelopt}}] \index{-/-nolabelopt@-\/-nolabelopt}Will
not optimize labels (makes the dumpfiles more readable).
\item [{\textbf{-\/-no-xinit-opt\index{-/-no-xinit-opt@-\/-no-xinit-opt}}}] Will
not memcpy initialized data from code space into xdata space. This
saves a few bytes in code space if you don't have initialized data\index{Variable initialization}.
\item [{\textbf{-\/-nooverlay\index{-/-nooverlay@-\/-nooverlay}}}]  The
compiler will not overlay parameters and local variables of any function,
see section Parameters and local variables for more details.
\item [{\textbf{-\/-no-peep\index{-/-no-peep@-\/-no-peep}}}] Disable
peep-hole optimization with built-in rules.
\item [{\textbf{-\/-peep-file}\index{-/-peep-file@-\/-peep-file}~<filename>}] This
option can be used to use additional rules to be used by the peep
hole optimizer. See section \ref{subsec:Peephole-Optimizer}~Peep
Hole optimizations for details on how to write these rules.
\item [{\textbf{-\/-peep-asm\index{-/-peep-asm@-\/-peep-asm}}}] Pass
the inline assembler code through the peep hole optimizer. This can
cause unexpected changes to inline assembler code, please go through
the peephole optimizer\index{Peephole optimizer} rules defined in
the source file tree '<target>/peeph.def' before using this option.
\item [{\textbf{-\/-peep-return\index{-/-peep-return@-\/-peep-return}}}] Let
the peep hole optimizer do return optimizations. This is the default
without \textbf{-\/-}debug\textbf{\index{-/-debug@-\/-debug}}.
\item [{\textbf{-\/-no-peep-return\index{-/-no-peep-return@-\/-no-peep-return}}}] Do
not let the peep hole optimizer do return optimizations. This is the
default with \textbf{-\/-}debug\textbf{\index{-/-debug@-\/-debug}}.
\item [{\textbf{-\/-opt-code-speed\index{-/-opt-code-speed@-\/-opt-code-speed}}}] The
compiler will optimize code generation towards fast code, possibly
at the expense of code size.
\item [{\textbf{-\/-opt-code-size\index{-/-opt-code-size@-\/-opt-code-size}}}] The
compiler will optimize code generation towards compact code, possibly
at the expense of code speed.
\item [{-\/-\textbf{fomit-frame-pointer}\index{-/-fomit-frame-pointer@-\/-fomit-frame-pointer}}] Frame
pointer will be omitted when the function uses no local variables.
On the z80-related ports this option will result in the frame pointer
always being omitted.
\item [{-\/-\textbf{max-allocs-per-node}\index{-/-max-allocs-per-node@-\/-max-allocs-per-node}}] Setting
this to a high value will result in increased compilation time (and
increased memory use during compilation) and more optimized code being
generated. Setting it to lower values speeds up compilation, but does
not optimize as much. The default value is 3000. This option currently
does not affect the mcs51, ds390, pic14 and pic16 ports.
\item [{-\/-\textbf{nolospre}\index{-/-nolospre@-\/-nolospre}}] Disable
lospre. lospre is an advanced redundancy elimination technique, essentially
an improved variant of global subexpression elimination.
\item [{-\/-\textbf{allow-unsafe-read}\index{-/-allow-unsafe-read@-\/-allow-unsafe-read}}] Allow
optimizations to generate unsafe reads. This will enable additional
optimizations, but can result in spurious reads from undefined memory
addresses, which can be harmful if the target system uses certain
ways of doing memory-mapped I/O.
\item [{-\/-\textbf{nostdlibcall}\index{-/-nostdlibcall@-\/-nostdlibcall}}] Disable
the optimization of calls to the standard library.
\end{lyxlist}

\subsection{Other Options\index{Options other}}
\begin{lyxlist}{00.00.0000}
\item [{\textbf{-v~-\/-version\index{-/-version@-\/-version}\index{-v}}}] displays
the sdcc version.
\item [{\textbf{-c~-\/-compile-only\index{-/-compile-only@-\/-compile-only}\index{-c}}}] will
compile and assemble the source, but will not call the linkage editor.
\item [{\textbf{-}\/\textbf{-c1mode\index{-/-c1mode@-\/-c1mode}}}] reads
the preprocessed source from standard input and compiles it. The file
name for the assembler output must be specified using the -o option.
\item [{\textbf{-E\index{-E}}}] Run only the C preprocessor\index{Preprocessor}.
Preprocess all the C source files specified and output the results
to standard output.
\item [{\textbf{-\/-syntax-only\index{-/-syntax-only@-\/-syntax-only}}}] Parse
and verify syntax only, no output files are produced.
\item [{\textbf{-o~<path/file>\index{-o <path/file>}}}] The output path
where everything will be placed or the file name used for all generated
output files. If the parameter is a path, it must have a trailing
slash (or backslash for the Windows binaries) to be recognized as
a path. Note for Windows users: if the path contains spaces, it should
be surrounded by quotes. The trailing backslash should be doubled
in order to prevent escaping the final quote, for example: \emph{-o
''F:\textbackslash Projects\textbackslash test3\textbackslash output
1\textbackslash\textbackslash ''} or put after the final quote,
for example: \emph{-o ''F:\textbackslash Projects\textbackslash test3\textbackslash output
1''\textbackslash}. The path using slashes for directory delimiters
can be used too, for example: \emph{-o ''F:/Projects/test3/output
1/''}.
\item [{\textbf{-x~<type>\index{-x <type>}}}] The specified type overrides
the file type that SDCC detected based on the file name extension.
The currently supported options are ''c'', ''c-header'' and ''none''.
The option ''none'' restores the default behavior.
\item [{\textbf{-\/-stack-auto\index{-/-stack-auto@-\/-stack-auto}}}] All
functions in the source file will be compiled as \emph{reentrant}\index{reentrant},
i.e. the parameters and local variables will be allocated on the stack\index{stack}.
See section \ref{sec:Parameters-and-Local-Variables} Parameters and
Local Variables for more details. If this option is used all source
files in the project should be compiled with this option. It automatically
implies -\textbf{\/}-int-long-reent and -\textbf{\/}-float-reent.
\item [{\textbf{-\/-callee-saves\index{-/-callee-saves@-\/-callee-saves}}}] \textbf{\label{lyx:--callee-saves-function1=00005B.function2=00005D=00005B.function3=00005D...}function1{[},function2{]}{[},function3{]}....}
The compiler by default uses a caller saves convention for register
saving across function calls, however this can cause unnecessary register
pushing and popping when calling small functions from larger functions.
This option can be used to switch the register saving convention for
the function names specified. The compiler will not save registers
when calling these functions, no extra code will be generated at the
entry and exit (function prologue\textbf{\index{function prologue}}
and epilogue\textbf{\index{function epilogue}}) for these functions
to save and restore the registers used by these functions, this can
SUBSTANTIALLY reduce code and improve run time performance of the
generated code. In the future the compiler (with inter procedural
analysis) will be able to determine the appropriate scheme to use
for each function call. DO NOT use this option for built-in functions
such as \_mulint..., if this option is used for a library function
the appropriate library function needs 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~callee\_saves \index{#pragma callee_saves@\#pragma callee\_saves}
\vpageref{ite:callee_saves-function1=00005B.function2=00005B.function3...=00005D=00005D--}.
\item [{\textbf{-\/-all-callee-saves\index{-/-all-callee-saves@-\/-all-callee-saves}}}] Function
of -\/-callee-saves will be applied to all functions by default.
\item [{\textbf{-\/-debug\index{-/-debug@-\/-debug}}}] When this option
is used the compiler will generate debug information. By default,
the debug information collected in a file with .cdb extension can
be used with the SDCDB. For more information see documentation for
SDCDB. Another file with a .omf extension contains debug information
in AOMF or AOMF51\index{AOMF, AOMF51} format which is commonly used
by third party tools. When –out-gmt-elf is used, the debug information
is in DWARF format instead.
\item [{\textbf{-S\index{-S}}}] Stop after the stage of compilation proper;
do not assemble. The output is an assembler code file for the input
file specified.
\item [{\textbf{-\/-int-long-reent\index{-/-int-long-reent@-\/-int-long-reent}}}] Integer
(16 bit) and long (32 bit) libraries have been compiled as reentrant.
Note by default these libraries are compiled as non-reentrant. See
section Installation for more details.
\item [{\textbf{-\/-cyclomatic\index{-/-cyclomatic@-\/-cyclomatic}}}] This
option will cause the compiler to generate an information message
for each function in the source file. The message contains some \emph{important}
information about the function. The number of edges and nodes the
compiler detected in the control flow graph of the function, and most
importantly the \emph{cyclomatic complexity\index{Cyclomatic complexity}}
see section on Cyclomatic Complexity for more details.
\item [{\textbf{-\/-float-reent\index{-/-float-reent@-\/-float-reent}}}] Floating
point library is compiled as reentrant\index{reentrant}. See section
Installation for more details.
\item [{\textbf{-\/-fsigned-char\index{-/-fsigned-char@-\/-fsigned-char}}}] By
default char is \texttt{unsigned}. To set the signedness for characters
to signed, use the option -\textbf{\/}-fsigned-char. If this option
is set and no signedness keyword (unsigned/signed) is given, a char
will be unsigned. All other types are unaffected.
\item [{\textbf{-\/-nostdinc\index{-/-nostdinc@-\/-nostdinc}}}] This
will prevent the compiler from passing on the default include path
to the preprocessor.
\item [{\textbf{-\/-nostdlib\index{-/-nostdlib@-\/-nostdlib}}}] This
will prevent the compiler from passing on the default library\index{Libraries}
path to the linker.
\item [{\textbf{-\/-verbose\index{-/-verbose@-\/-verbose}}}] Shows the
various actions the compiler is performing.
\item [{\textbf{-V\index{-V}}}] Shows the actual commands the compiler
is executing.
\item [{\textbf{-\/-no-c-code-in-asm\index{-/-no-c-code-in-asm@-\/-no-c-code-in-asm}}}] Hides
your ugly and inefficient c-code from the asm file, so you can always
blame the compiler :)
\item [{\textbf{-\/-no-peep-comments\index{-/-no-peep-comments@-\/-no-peep-comments}}}] Don't
include peep-hole comments in the generated asm files even if -\textbf{\/}-fverbose-asm
option is specified.
\item [{\textbf{-\/-i-code-in-asm\index{-/-i-code-in-asm@-\/-i-code-in-asm}}}] Include
i-codes in the asm file. Sounds like noise but is helpful for debugging
the compiler itself.
\item [{\textbf{-\/-less-pedantic\index{pedantic}\index{-/-less-pedantic@-\/-less-pedantic}}\label{lyx:--less-pedantic}}] Disable
some of the more pedantic warnings\index{Warnings}. For more details,
see the less\_pedantic pragma \vpageref{ite:less_pedantic}.
\item [{\textbf{-\/-disable-warning~<nnnn>\index{-/-disable-warning@-\/-disable-warning}}}] Disable
specific warning with number <nnnn>.
\item [{\textbf{-\/-Werror\index{-/-Werror@-\/-Werror}}}] Treat all warnings
as errors.
\item [{\textbf{-\/-print-search-dirs\index{-/-print-search-dirs@-\/-print-search-dirs}}}] Display
the directories in the compiler's search path
\item [{\textbf{-\/-vc\index{-/-vc@-\/-vc}}}] Display errors and warnings
using MSVC style, so you can use SDCC with the visual studio IDE\index{IDE}.
With SDCC both offering a GCC-like (the default) and a MSVC-like\index{MSVC output style}
output style, integration into most programming editors should be
straightforward.
\item [{\textbf{-\/-use-stdout\index{-/-use-stdout@-\/-use-stdout}}}] Send
errors and warnings to stdout instead of stderr.
\item [{\textbf{-Wa~asmOption{[},asmOption{]}}\index{-Wa asmOption{[},asmOption{]}}...}] Pass
the asmOption to the assembler\index{Options assembler}\index{Assembler options}.
See file sdcc/sdas/doc/asmlnk.txt for assembler options.cd
\item [{\textbf{-\/-std-<arg>}}] Determine the language standard. For
enhanced compatibility with other compilers, \textbf{-\/-std} can
also be used with a single dash (i.e. \textbf{-std}) and with \textbf{=}
or \textbf{\textvisiblespace{}} (whitespace) as delimiter. The language
standard, specified via \textbf{<arg>}, can be one of the following:
\begin{lyxlist}{00.00.0000}
\item [{\textbf{c90}}] \textbf{\index{-/-std-c89@-\/-std-c89}} Follow
the ISO/IEC 9899 First Edition standard (ANSI C89 / ISO C90). Alternative
spellings: \textbf{c89}, \textbf{iso9899:1990}
\item [{\textbf{c94}}] \textbf{\index{-/-std-sdcc99@-\/-std-sdcc99}} Follow
the ISO/IEC 9899 First Edition standard as modified in amendment 1.
Alternative spelling: \textbf{c95, iso9899:199409}
\item [{\textbf{c99}}] \textbf{\index{-/-std-sdcc99@-\/-std-sdcc99}} Follow
the ISO/IEC 9899 Second Edition standard (ISO C99). Alternative spelling:
\textbf{iso9899:1999}
\item [{\textbf{c11}}] \textbf{\index{-/-std-sdcc11@-\/-std-sdcc11}} Follow
the ISO/IEC 9899 Third Edition standard (ISO C11). Alternative spelling:
\textbf{iso9899:2011}
\item [{\textbf{c17}}] \textbf{\index{-/-std-sdcc17@-\/-std-sdcc17}} Follow
the ISO/IEC 9899 Fourth Edition standard (ISO C17). Alternative spellings:
\textbf{iso9899:2017}, \textbf{c18}, \textbf{iso9899:2018}
\item [{\textbf{c23}}] \textbf{\index{-/-std-sdcc23@-\/-std-sdcc23}} Follow
the ISO/IEC 9899 Fifth Edition standard (ISO C23). Alternative spelling:
\textbf{c2x}
\item [{\textbf{c2y}}] \textbf{\index{-/-std-sdcc2y@-\/-std-sdcc2y}} Enable
features anticipated for the Sixth Edition standard (currently abbreviated
ISO C2y).
\item [{\textbf{sdcc90}}] \textbf{\index{-/-std-sdcc89@-\/-std-sdcc89}}
Generally follow ANSI C89 / ISO C90, but allow some SDCC behaviour
that conflicts with the standard. Alternative spelling: \textbf{sdcc89}
\item [{\textbf{sdcc99}}] \textbf{\index{-/-std-sdcc99@-\/-std-sdcc99}}
Generally follow ISO C99, but allow some SDCC behaviour that conflicts
with the standard.
\item [{\textbf{sdcc11}}] \textbf{\index{-/-std-sdcc11@-\/-std-sdcc11}}
Generally follow ISO C11, but allow some SDCC behaviour that conflicts
with the standard (default).
\item [{\textbf{sdcc17}}] \textbf{\index{-/-std-sdcc17@-\/-std-sdcc17}}
Generally follow ISO C17, but allow some SDCC behaviour that conflicts
with the standard. Alternative spelling: \textbf{sdcc18}
\item [{\textbf{sdcc23}}] \textbf{\index{-/-std-sdcc23@-\/-std-sdcc23}}
Generally follow ISO C23, but allow some SDCC behaviour that conflicts
with the standard. Alternative spelling: \textbf{sdcc2x}
\item [{\textbf{sdcc2y}}] \textbf{\index{-/-std-sdcc2y@-\/-std-sdcc2y}}
Generally follow ISO C2y, but allow some SDCC behaviour that conflicts
with the standard.
\end{lyxlist}
\item [{\textbf{-\/-codeseg}\index{-/-codeseg <Value>@-\/-codeseg <Value>}\label{lyx:-codeseg}~<Name>}] The
name to be used for the code\index{code} segment, default CSEG. This
is useful if you need to tell the compiler to put the code in a special
segment so you can later on tell the linker to put this segment in
a special place in memory. Can be used for instance when using bank
switching to put the code in a bank.
\item [{\textbf{-\/-constseg}\index{-/-constseg <Value>@-\/-constseg <Value>}~<Name>}] The
name to be used for the const\index{const} segment, default CONST.
This is useful if you need to tell the compiler to put the const data
in a special segment so you can later on tell the linker to put this
segment in a special place in memory. Can be used for instance when
using bank switching to put the const data in a bank.
\item [{\textbf{-\/-fdollars-in-identifiers\index{-/-fdollars-in-identifiers@-\/-fdollars-in-identifiers}}}] Permit
'\$' as an identifier character.
\item [{\textbf{-\/-more-pedantic}\index{-/-more-pedantic@-\/-more-pedantic}\index{pedantic}}] Actually
this is \textbf{\emph{not}} a SDCC compiler option but if you want
\emph{more} warnings you can use a separate tool dedicated to syntax
checking like splint\label{lyx:more-pedantic-SPLINT}\index{lint (syntax checking tool)}
\url{http://www.splint.org}. To make your source files parseable
by splint you will have to include \textsf{lint.h}\index{splint (syntax checking tool)}
in your source file and add brackets around extended keywords (like
\textsf{''\_\_at~}\textsf{\textbf{(}}\textsf{0xab}\textsf{\textbf{)}}\textsf{''}
and \textsf{''\_\_interrupt~(2)''}). \\
Splint has an excellent on line manual at \url{http://www.splint.org/manual/}
and it's capabilities go beyond pure syntax checking. You'll need
to tell splint the location of SDCC's include files so a typical command
line could look like this: \\
\textsf{splint~-I~/usr/local/share/sdcc/include/mcs51/~~myprogram.c}
\item [{\textbf{-\/-use-non-free}\index{-/-use-non-free@-\/-use-non-free}\label{lyx:--use-non-free}}] Search
/ include non-free licensed libraries and header files, located under
the non-free directory - see section \ref{subsec:Search-Paths}
\end{lyxlist}

\subsection{Linker Options\index{Options linker}\index{Linker options}}
\begin{lyxlist}{00.00.0000}
\item [{\textbf{-}\/\textbf{-lib-path\index{-/-lib-path <path>@-\/-lib-path <path>}}~<absolute}] path
to additional libraries> This option is passed to the linkage editor's
additional libraries\index{Libraries} search path. The path name
must be absolute. Additional library files may be specified in the
command line. See section Compiling programs for more details.
\item [{\textbf{-L~\index{-L <path>}}~<absolute}] path to additional
libraries> Same as above.
\item [{\textbf{-\/-xram-loc}\index{-/-xram-loc <Value>@-\/-xram-loc <Value>}~<Value>}] The
start location of the external ram\index{__xdata (mcs51, ds390 named address space)@\_\_xdata (mcs51, ds390 named address space)},
default value is 0. The value entered can be in Hexadecimal or Decimal
format, e.g.: -\/-xram-loc 0x8000 or -\/-xram-loc 32768.
\item [{\textbf{-\/-code-loc}\index{-/-code-loc <Value>@-\/-code-loc <Value>}~<Value>}] The
start location of the code\index{code} segment, default value 0.
Note when this option is used the interrupt vector table\index{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.
\item [{\textbf{-\/-stack-loc}\index{-/-stack-loc <Value>@-\/-stack-loc <Value>}~<Value>}] The
value entered can be in Hexadecimal or Decimal format, e.g. -\/-stack-loc
0x20 or -\/-stack-loc 32.

For stm8, by default the stack is placed at the device-specific reset
value. By using this option, the stack can be placed anywhere in the
lower 16-bits of the stm8 memory space. This is particularly useful
for working around the stack roll-over antifeature present in some
stm8 devices.
\item [{\textbf{-\/-xstack-loc}\index{-/-xstack-loc <Value>@-\/-xstack-loc <Value>}~<Value>}] By
default the external stack\index{xstack} is placed after the \_\_pdata\index{__pdata (mcs51, ds390 named address space)@\_\_pdata (mcs51, ds390 named address space)}
segment. Using this option the xstack can be placed anywhere in the
external memory space of the 8051. The value entered can be in Hexadecimal
or Decimal format, e.g. -\/-xstack-loc 0x8000 or -\/-xstack-loc
32768. The provided value should not overlap any other memory areas
such as the pdata or xdata segment and with enough space for the current
application.
\item [{\textbf{-\/-data-loc}\index{-/-data-loc <Value>@-\/-data-loc <Value>}~<Value>}] The
start location of the internal ram data\index{__data (mcs51, ds390 named address space)@\_\_data (mcs51, ds390 named address space)}
segment. The value entered can be in Hexadecimal or Decimal format,
eg. -\/-data-loc 0x20 or -\/-data-loc 32. (By default, the start
location of the internal ram data segment  is set as low as possible
in memory, taking into account the used register banks and the bit
segment at address 0x20. For example if register banks 0 and 1 are
used without bit variables, the data segment will be set, if -\/-data-loc
is not used, to location 0x10.)
\item [{\textbf{-\/-idata-loc}\index{-/-idata-loc <Value>@-\/-idata-loc <Value>}~<Value>}] The
start location of the indirectly addressable internal ram\index{__idata (mcs51, ds390 named address space)@\_\_idata (mcs51, ds390 named address space)}
of the 8051, default value is 0x80. The value entered can be in Hexadecimal
or Decimal format, eg. -\/-idata-loc 0x88 or -\/-idata-loc 136.
\item [{\textbf{-\/-bit-loc}~<Value>}] The start location of the bit\index{bit}
addressable internal ram of the 8051. This is \emph{not} implemented
yet. Instead an option can be passed directly to the linker: -Wl~-bBSEG=<Value>.
\item [{\textbf{-\/-out-fmt-ihx\index{-/-out-fmt-ihx@-\/-out-fmt-ihx}}}] The
linker output (final object code) is in Intel Hex format.\index{Intel hex format}
This is the default option. The format itself is documented in the
documentation of srecord\index{srecord (bin, hex, ... tool)}.
\item [{\textbf{-\/-out-fmt-s19\index{-/-out-fmt-s19@-\/-out-fmt-s19}}}] The
linker output (final object code) is in Motorola S19 format\index{Motorola S19 format}.
The format itself is documented in the documentation of srecord.
\item [{\textbf{-\/-out-fmt-elf\index{-/-out-fmt-s19@-\/-out-fmt-s19}\index{HC08!Options!-/-out-fmt-elf@-\/-out-fmt-elf}}}] The
linker output (final object code) is in ELF format\index{ELF format}.
(Currently only supported for the HC08\index{HC08}, S08 and STM8
processors). When used with –debug, the debug info is in DWARF format
instead of CDB.
\item [{\textbf{-Wl~linkOption{[},linkOption{]}}\index{-Wl linkOption{[},linkOption{]}}\label{lyx:-Wl option}...}] Pass
the linkOption to the linker. If a bootloader is used an option like
''-Wl~-bCSEG=0x1000'' would be typical to set the start of the
code segment. Either use the double quotes around this option or use
no space (e.g. -Wl-bCSEG=0x1000). See also \#pragma constseg and \#pragma
codeseg in section\ref{sec:Pragmas}. File sdcc/sdas/doc/asmlnk.txt
has more on linker options.
\end{lyxlist}

\subsection{MCS51 Options\index{Options MCS51}\index{MCS51 options}}
\begin{lyxlist}{00.00.0000}
\item [{\textbf{-\/-model-small\index{-/-model-small@-\/-model-small}}}] Generate
code for Small model programs, see section Memory Models for more
details. This is the default model.
\item [{\textbf{-\/-model-medium\index{-/-model-medium@-\/-model-medium}}}] Generate
code for Medium model programs, see section Memory Models for more
details. If this option is used all source files in the project have
to be compiled with this option. It must also be used when invoking
the linker.
\item [{\textbf{-\/-model-large\index{-/-model-large@-\/-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 have
to be compiled with this option. It must also be used when invoking
the linker.
\item [{\textbf{-\/-model-huge\index{-/-model-huge@-\/-model-huge}}}] Generate
code for Huge model programs, see section Memory Models for more details.
If this option is used all source files in the project have to be
compiled with this option. It must also be used when invoking the
linker.
\item [{\textbf{-\/-xstack\index{-/-xstack@-\/-xstack}}}] Uses a pseudo
stack in the \_\_pdata\index{__pdata (mcs51, ds390 named address space)@\_\_pdata (mcs51, ds390 named address space)}
area (usually the first 256 bytes in the external ram) for allocating
variables and passing parameters. See section \ref{subsec:External-Stack}~
External Stack for more details.
\item [{\textbf{-\/-iram-size}~<Value>\index{-/-iram-size <Value>@-\/-iram-size <Value>}}] Causes
the linker to check if the internal ram usage is within limits of
the given value.
\item [{\textbf{-\/-xram-size}~<Value>\index{-/-xram-size <Value>@-\/-xram-size <Value>}}] Causes
the linker to check if the external ram usage is within limits of
the given value.
\item [{\textbf{-\/-code-size}~<Value>\index{-/-code-size <Value>@-\/-code-size <Value>}}] Causes
the linker to check if the code memory usage is within limits of the
given value.
\item [{\textbf{-\/-stack-size}~<Value>\index{-/-stack-size <Value>@-\/-stack-size <Value>}}] Causes
the linker to check if there is at minimum <Value> bytes for stack.
\item [{\textbf{-\/-acall-ajmp}~\index{-/-acall-ajmp@-\/-acall-ajmp}}] Replaces
the three byte instructions lcall/ljmp with the two byte instructions
acall/ajmp. Only use this option if your code is in the same 2k block
of memory. You may need to use this option for some 8051 derivatives
which lack the lcall/ljmp instructions.
\item [{\textbf{-\/-no-ret-without-call}~\index{-/-no-ret-without-call@-\/-no-ret-without-call}}] Causes
the code generator to insert an extra lcall or acall instruction whenever
it needs to use a ret instruction in a context other than a function
returning. This option is needed when using the Infineon\index{Infineon}
XC800 series microcontrollers to keep its Memory Extension Stack balanced.
\end{lyxlist}

\subsection{DS390 / DS400 Options\index{Options DS390}\index{DS390}}
\begin{lyxlist}{00.00.0000}
\item [{\textbf{-\/-model-flat24}\index{DS390!Options!-/-model-flat24@-\/-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 \emph{-mds390}.
See section Memory Models for more details.
\item [{\textbf{-\/-protect-sp-update\index{DS390!Options!-/-protect-sp-update@-\/-protect-sp-update}}}] disable
interrupts during ESP:SP updates.
\item [{\textbf{-\/-stack-10bit}\index{DS390!Options!-/-stack-10bit@-\/-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 \emph{-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 \emph{-\/-stack-auto\index{-/-stack-auto@-\/-stack-auto}}
option, but that has not been tested. It is incompatible with the
\emph{-\/-xstack\index{-/-xstack@-\/-xstack}} option. It also only
makes sense if the processor is in 24 bit contiguous addressing mode
(see the \emph{-\/-model-flat24 option}).\textbf{}
\item [{\textbf{-\/-stack-probe\index{DS390!Options!-/-stack-probe@-\/-stack-probe}}}] insert
call to function \_\_stack\_probe at each function prologue.
\item [{\textbf{-\/-tini-libid\index{DS390!Options!-/-tini-libid@-\/-tini-libid}}}] <nnnn>
LibraryID used in -mTININative. 
\item [{\textbf{-\/-use-accelerator\index{DS390!Options!-/-use-accelerator@-\/-use-accelerator}}}] generate
code for DS390 Arithmetic Accelerator. 
\end{lyxlist}

\subsection{Options common to all z80-related ports (z80, z180, r2k, r3ka, sm83,
tlcs90, ez80\_z80)}
\begin{lyxlist}{00.00.0000}
\item [{\textbf{-\/-no-std-crt0}\index{Z80!Options!-/-no-std-crt0@-\/-no-std-crt0}}] When
linking, skip the standard crt0.rel object file. You must provide
your own crt0.rel for your system when linking.
\item [{\textbf{-\/-callee-saves-bc}\index{Z80!Options!-/-callee-saves-bc@-\/-callee-saves-bc}}] Force
a called function to always save BC.
\item [{\textbf{-\/-codeseg}~<Value>\index{Z80!Options!-/-codeseg <Value>@-\/-codeseg <Value>}}] Use
<Value> for the code segment name.
\item [{\textbf{-\/-constseg}~<Value>\index{Z80!Options!-/-constseg <Value>@-\/-constseg <Value>}}] Use
<Value> for the const segment name.
\end{lyxlist}

\subsection{Z80 Options\index{Options Z80}\index{Z80} (apply to z80, z180,
r2k, r3ka, tlcs90, ez80\_z80)}
\begin{lyxlist}{00.00.0000}
\item [{\textbf{-\/-portmode=}<Value>\index{Z80!Options!-/-portmode=<Value>@-\/-portmode=<Value>}}] Determinate
PORT I/O mode (<Value> is z80 or z180).
\item [{\textbf{-\/-asm=}<Value>\index{Z80!Options!-/-asm=<Value>@-\/-asm=<Value>}}] Define
assembler name (<Value> is rgbds, sdasz80, isas or z80asm).
\item [{\textbf{-\/-reserve-regs-iy}\index{Z80!Options!-/-reserve-regs-iy@-\/-reserve-regs-iy}}] This
option tells the compiler that it is not allowed to use register pair
iy. The option can be useful for systems where iy is reserved for
the OS. This option is incompatible with -\/-fomit-frame-pointer.
\item [{\textbf{-\/-fno-omit-frame-pointer}\index{Z80!Options!-/-fno-omit-frame-pointer@-\/-fno-omit-frame-pointer}}] Never
omit the frame pointer.
\end{lyxlist}

\subsection{SM83 Options\index{Options GBZ80}\index{SM83}}
\begin{lyxlist}{00.00.0000}
\item [{\textbf{-bo}~<Num>\index{GBZ80!Options!-bo <Num>}}] Use code
bank <Num>.
\item [{\textbf{-ba}~<Num>\index{GBZ80!Options!-ba <Num>}}] Use data
bank <Num>.
\end{lyxlist}

\subsection{STM8 Options\index{Options STM8}\index{STM8 options}}
\begin{lyxlist}{00.00.0000}
\item [{\textbf{-\/-model-medium\index{-/-model-medium@-\/-model-medium}}}] Generate
code for Medium model programs, see section Memory Models for more
details. This is the default model.
\item [{\textbf{-\/-model-large\index{-/-model-large@-\/-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 have
to be compiled with this option. It must also be used when invoking
the linker.
\end{lyxlist}

\subsection{MOS6502 Options\index{Options MOS6502}\index{MOS6502 options} (apply
to mos6502, mos65c02)}
\begin{lyxlist}{00.00.0000}
\item [{\textbf{-\/-model-small\index{-/-model-small@-\/-model-small}}}] Generate
code for small model programs, see section Memory Models for more
details. 
\item [{\textbf{-\/-model-large\index{-/-model-large@-\/-model-large}}}] Generate
code for large model programs, see section Memory Models for more
details. This is the default memory model.
\item [{\textbf{-\/-no-zp-spill\index{-/-no-zp-spill@-\/-no-zp-spill}}}] Force
the compiler to spill registers to 16-bit addressable memory (xdata)
instead of Page Zero. When running out of Page Zero space, this option
will allow to free many Page Zero locations at the expense of slightly
larger and slower code
\end{lyxlist}

\subsection{Intermediate Dump Options\label{subsec:Intermediate-Dump-Options}\index{Options intermediate dump}\index{Intermediate dump options}}

The following options are provided for the purpose of retargetting
and debugging the compiler. They provide a means to dump the intermediate
code (iCode\index{iCode}) generated by the compiler in human readable
form at various stages of the compilation process. More on iCodes
see chapter \ref{subsec:The-anatomy-of} ''The anatomy of the compiler''.
\begin{lyxlist}{00.00.0000}
\item [{\textbf{-\/-dum-ast\index{-/-dump-ast@-\/-dump-ast}}}] This option
will cause the compiler to dump the abstract syntax tree to the econsole.
\item [{\textbf{-\/-dump-i-code\index{-/-dump-i-code@-\/-dump-i-code}}}] Will
dump iCodes at various stages into files named \emph{<source filename>.dump<stage>}.
\item [{\textbf{-\/-dump-graphs\index{-/-dump-graphs@-\/-dump-graphs}}}] Will
dump internal representations as graphviz .dot files. Depending on
other options, this can include the control-flow graph at lospre,
insertion of bank selection instructions or register allocation and
the conflict graph and tree-decomposition at register allocation.
\item [{\textbf{-\/-fverbose-asm\index{-/-no-gen-comments@-\/-no-gen-comments}}}] Include
code generator and peep-hole comments in the generated asm files.
\end{lyxlist}

\subsection{Redirecting output on Windows Shells}

By default SDCC writes its error messages to ''standard error''.
To force all messages to ''standard output'' use \textbf{-}\emph{\/}\textbf{-}use-stdout\index{-/-use-stdout@-\/-use-stdout}.
Additionally, if you happen to have visual studio installed in your
Windows machine, you can use it to compile your sources using a custom
build and the SDCC -\emph{\/}-vc\index{-/-vc@-\/-vc} option. Something
like this should work:\\
\\
\textbf{c:\textbackslash sdcc\textbackslash bin\textbackslash sdcc.exe
-}\emph{\/}\textbf{-vc -}\emph{\/}\textbf{-model-large -c \$(InputPath)}

\section{Environment variables\index{Environment variables}}

SDCC recognizes the following environment variables:
\begin{lyxlist}{00.00.0000}
\item [{\textbf{SDCC\_LEAVE\_SIGNALS\index{SDCC!Environment variables!SDCC_LEAVE_SIGNALS@SDCC\_LEAVE\_SIGNALS}}}] SDCC
installs a signal handler\index{signal handler} to be able to delete
temporary files after an user break (\textasciicircum C) or an exception.
If this environment variable is set, SDCC won't install the signal
handler in order to be able to debug SDCC.
\item [{\textbf{TMP,~TEMP,~TMPDIR\index{SDCC!Environment variables!TMP, TEMP, TMPDIR}}}] Path,
where temporary files will be created. The order of the variables
is the search order. In a standard {*}nix environment these variables
are not set, and there's no need to set them. On Windows it's recommended
to set one of them.
\item [{\textbf{SDCC\_HOME\index{SDCC!Environment variables!SDCC_HOME@SDCC\_HOME}}}] Path,
see section \ref{subsec:Install-paths}~'' Install Paths''.
\item [{\textbf{SDCC\_INCLUDE\index{SDCC!Environment variables!SDCC_INCLUDE@SDCC\_INCLUDE}}}] Path,
see section \ref{subsec:Search-Paths}~''Search Paths''.
\item [{\textbf{SDCC\_LIB\index{SDCC!Environment variables!SDCC_LIB@SDCC\_LIB}}}] Path,
see section \ref{subsec:Search-Paths}~''Search Paths''..
\end{lyxlist}
There are some more environment variables recognized by SDCC, but
these are mainly used for debugging purposes. They can change or disappear
very quickly, and won't be documented\footnote{if you are curious search in SDCC's sources for \texttt{''getenv''}}\index{SDCC!Environment variables!undocumented}.

\section{SDCC Language Extensions}

SDCC supports some language extensions useful for embedded systems.
These include named address spaces (see also section 5.1 of the Embedded
C standard). SDCC supports both intrinsic named address spaces (which
ones are supported depends on the target architecture) and non-intrinsic
named address spaces (defined by the user using the keyword \_\_addressmod,
they are particularly useful with custom bank-switching hardware).
Unlike the Embedded C standard, SDCC allows local variables to have
an intrinsic named address space even when not explicitly declared
as static or extern. Depending on the target architecture, support
can be limited to objects in such address spaces and exclude pointer-based
access to those.

\subsection{MCS51/DS390 intrinsic named address spaces}

SDCC supports the following MCS51-specific intrinsic address spaces:

\includegraphics{MCS51_named}

\subsubsection{\_\_data\index{__data (mcs51, ds390 named address space)@\_\_data (mcs51, ds390 named address space)}
/ \_\_near\index{__near (named address space)@\_\_near (named address space)}}

This is the \textbf{default} (generic) address space for the Small
Memory model. Variables in this address space will be allocated in
the directly addressable portion of the internal RAM of a 8051, e.g.:
\begin{verse}
\texttt{\_\_data unsigned char test\_data;}
\end{verse}
Writing 0x01 to this variable generates the assembly code:
\begin{verse}
\texttt{75{*}00 01~~~mov~~\_test\_data,\#0x01}
\end{verse}

\subsubsection{\_\_xdata\index{__xdata (mcs51, ds390 named address space)@\_\_xdata (mcs51, ds390 named address space)}
/ \_\_far\index{__far (named address space)@\_\_far (named address space)}}

Variables in this address space will be placed in the external RAM.
This is the \textbf{default} (generic) address space for the Large
Memory model, e.g.:
\begin{verse}
\texttt{\_\_xdata unsigned char test\_xdata;}
\end{verse}
Writing 0x01 to this variable generates the assembly code:
\begin{verse}
\texttt{90s00r00~~~mov~~dptr,\#\_test\_xdata}~\\
\texttt{74~01~~~~~~mov~~a,\#0x01}~\\
\texttt{F0~~~~~~~~~movx~@dptr,a }
\end{verse}

\subsubsection{\_\_idata\index{__idata (mcs51, ds390 named address space)@\_\_idata (mcs51, ds390 named address space)}}

Variables in this address space will be allocated into the indirectly
addressable portion of the internal ram of a 8051, e.g.:
\begin{verse}
\texttt{\_\_idata unsigned char test\_idata;}
\end{verse}
Writing 0x01 to this variable generates the assembly code:
\begin{verse}
\texttt{78r00~~~~~~~mov~~r0,\#\_test\_idata}~\\
\texttt{76~01~~~~~~~mov~~@r0,\#0x01}
\end{verse}
Please note, the first 128 byte of idata physically access the same
RAM as the data memory. The original 8051 had 128 byte idata memory,
nowadays most devices have 256 byte idata memory. The stack\index{stack}
is located in idata memory (unless \code{-{}-xstack} is specified).

\subsubsection{\_\_pdata\index{__pdata (mcs51, ds390 named address space)@\_\_pdata (mcs51, ds390 named address space)}}

Paged xdata access is just as straightforward as using the other addressing
modes of a 8051. It is typically located at the start of xdata and
has a maximum size of 256 bytes. The following example writes 0x01
to the pdata variable. Please note, pdata access physically accesses
xdata memory. The high byte of the address is determined by port P2
\index{P2 (mcs51 sfr)}(or in case of some 8051 variants by a separate
Special Function Register, see section \ref{subsec:MCS51-variants}).
This is the \textbf{default} (generic) address space for the Medium
Memory model, e.g.:
\begin{verse}
\texttt{\_\_pdata unsigned char test\_pdata;}
\end{verse}
Writing 0x01 to this variable generates the assembly code:
\begin{verse}
\texttt{78r00~~~~~~mov r0,\#\_test\_pdata}~\\
\texttt{74 01~~~~~~mov a,\#0x01}~\\
\texttt{F2~~~~~~~~~movx @r0,a}
\end{verse}
If the -\/-xstack\index{-/-xstack@-\/-xstack} option is used the
pdata memory area is followed by the xstack memory area and the sum
of their sizes is limited to 256 bytes.

\subsubsection{\_\_code\index{__code@\_\_code}}

'Variables' in this address space will be placed in the code memory:
\begin{verse}
\texttt{\_\_code unsigned char test\_code;}
\end{verse}
Read access to this variable generates the assembly code:
\begin{verse}
\texttt{90s00r6F~~~mov dptr,\#\_test\_code}~\\
\texttt{E4~~~~~~~~~clr a}~\\
\texttt{93~~~~~~~~~movc a,@a+dptr }
\end{verse}
\texttt{char} indexed arrays of characters in code memory can be accessed
efficiently:
\begin{verse}
\texttt{\_\_code char test\_array{[}{]} = \{'c','h','e','a','p'\}; }
\end{verse}
Read access to this array using an 8-bit unsigned index generates
the assembly code:
\begin{verse}
\texttt{E5{*}00~~~~~~mov a,\_index }

\texttt{90s00r41~~~mov dptr,\#\_test\_array}

\texttt{93~~~~~~~~~movc a,@a+dptr }
\end{verse}

\subsubsection{\_\_bit\index{__bit@\_\_bit}}

This is a data-type and an address space. When a variable is declared
as a bit, it is allocated into the bit addressable memory of 8051,
e.g.:
\begin{verse}
\texttt{\_\_bit test\_bit;}
\end{verse}
Writing 1 to this variable generates the assembly code:
\begin{verse}
\texttt{D2{*}00~~~~~~~setb~\_test\_bit}
\end{verse}
The bit addressable memory consists of 128 bits which are located
from 0x20 to 0x2f in data memory.\\
Apart from this 8051 specific intrinsic named address space most architectures
support ANSI-C bit-fields\index{bit-fields}\footnote{Not really meant as examples, but nevertheless showing what bit-fields
are about: device/include/mc68hc908qy.h and support/regression/tests/bitfields.c}. In accordance with ISO/IEC 9899 bits and bitfields without an explicit
signed modifier are implemented as unsigned.

\subsubsection{\_\_sfr\index{__sfr@\_\_sfr} / \_\_sfr16\index{__sfr16@\_\_sfr16}
/ \_\_sfr32\index{__sfr32@\_\_sfr32} / \_\_sbit\index{sbit}}

Like the \_\_bit keyword, \emph{\_\_sfr / \_\_sfr16 / \_\_sfr32 /
\_\_sbit} signify both a data-type and named address space, they are
used to describe the \emph{s}pecial \emph{f}unction \emph{r}egisters
and special \emph{\_\_bit} variables of a 8051, eg:
\begin{verse}
\texttt{\_\_sfr \_\_at\index{__at@\_\_at} (0x80) P0;~ /{*} special
function register P0 at location 0x80 {*}/}~\\
\texttt{}~\\
\texttt{/{*} 16 bit special function register combination for timer
0}~\\
\texttt{~~ with the high byte at location 0x8C and the low byte
at location 0x8A {*}/}~\\
\texttt{\_\_sfr16 \_\_at (0x8C8A) TMR0;}~\\
\texttt{}~\\
\texttt{\_\_sbit \_\_at\index{__at@\_\_at} (0xd7) CY;~ /{*} CY (Carry
Flag\index{Flags}\index{Carry flag}) {*}/}
\end{verse}
Special function registers which are located on an address dividable
by 8 are bit-addressable, an \emph{\_\_sbit} addresses a specific
bit within these sfr.\\
16 Bit and 32 bit special function register combinations which require
a certain access order are better not declared using \emph{\_\_sfr16}
or \emph{\_\_sfr32.} Although SDCC usually accesses them Least Significant
Byte (LSB) first, this is not guaranteed.\\

Please note, if you use a header file which was written for another
compiler then the \_\_sfr / \_\_sfr16 / \_\_sfr32 / \_\_sbit intrinsic
named address spaces will most likely be \emph{not} compatible. Specifically
the syntax \texttt{~sfr P0 = 0x80;~} is compiled \emph{without warning}
by SDCC to an assignment of 0x80 to a variable called P0\texttt{.}
\textbf{Nevertheless with the file }\texttt{\textbf{compiler.h\index{compiler.h (include file)}}}\textbf{
it is possible to write header files\index{Header files}\index{Include files}
which can be shared among different compilers (see section \ref{sec:Porting-code-to-other-compilers}). }

\subsubsection{Pointers\index{Pointer} to MCS51/DS390 intrinsic named address spaces}

SDCC allows (via language extensions) pointers to explicitly point
to any of the named address spaces\index{Memory model} of the 8051.
In addition to the explicit pointers, the compiler uses (by default)
generic pointers which can be used to point to any of the memory spaces.\\
\\
Pointer declaration examples:
\begin{verse}
\texttt{/{*} pointer physically in internal ram pointing to object
in external ram {*}/}~\\
\texttt{\_\_xdata unsigned char {*} \_\_data p;}~\\
\texttt{}~\\
\texttt{/{*} pointer physically in external ram pointing to object
in internal ram {*}/}~\\
\texttt{\_\_data unsigned char {*} \_\_xdata p;}~\\
\texttt{}~\\
\texttt{/{*} pointer physically in code rom pointing to data in xdata
space {*}/}~\\
\texttt{\_\_xdata unsigned char {*} \_\_code p;}~\\
\texttt{}~\\
\texttt{/{*} pointer physically in code space pointing to data in
code space {*}/}~\\
\texttt{\_\_code unsigned char {*} \_\_code p;}~\\
\texttt{}~\\
\texttt{/{*} generic pointer physically located in xdata space {*}/}~\\
\texttt{unsigned char {*} \_\_xdata p;}~\\
\texttt{}~\\
\texttt{/{*} generic pointer physically located in default memory
space {*}/}~\\
\texttt{unsigned char {*} p;}~\\
\texttt{}~\\
\texttt{/{*} the following is a function pointer\index{function pointer}
physically located in data space {*}/}~\\
\texttt{char ({*} \_\_data fp)(void);}
\end{verse}
Well you get the idea.\\
\\
All unqualified pointers are treated as 3-byte (4-byte for the ds390)
\emph{generic} pointers.{\small}\\
{\small}\\
The highest order byte of the \emph{generic} pointers contains the
data space information. Assembler support routines are called whenever
data is stored or retrieved using \emph{generic} pointers. These are
useful for developing reusable library\index{Libraries} routines.
Explicitly specifying the pointer\index{Pointer} type will generate
the most efficient code.

\subsubsection{Notes on MCS51 memory\index{MCS51 memory} layout}

The 8051 family of microcontrollers have a minimum of 128 bytes of
internal RAM memory \emph{\_\_data}\index{__data (mcs51, ds390 named address space)@\_\_data (mcs51, ds390 named address space)}
which is structured as follows:\\
\\
- Bytes 00-1F - 32 bytes to hold up to 4 banks of the registers R0
to R7,\\
- Bytes 20-2F - 16 bytes to hold 128 bit\index{bit} variables and,\\
- Bytes 30-7F - 80 bytes for general purpose use.\\

Additionally some members of the MCS-51 family may have up to 128
bytes of additional, indirectly addressable, internal RAM memory (\emph{\_\_idata}\index{__idata (mcs51, ds390 named address space)@\_\_idata (mcs51, ds390 named address space)}).
Furthermore, some chips may have some built in external memory (\emph{\_\_xdata}\index{__xdata (mcs51, ds390 named address space)@\_\_xdata (mcs51, ds390 named address space)})
which should not be confused with the internal, directly addressable
RAM memory (\emph{\_\_data}\index{__data (mcs51, ds390 named address space)@\_\_data (mcs51, ds390 named address space)}).
Sometimes this built in \emph{\_\_xdata} memory has to be activated
before using it (you can probably find this information on the datasheet
of the microcontroller your are using, see also section \ref{subsec:MCS51-Startup-Code}~Startup-Code).

Normally SDCC will only use the first bank\index{register bank (mcs51, ds390)}
of registers (register bank 0), but it is possible to specify that
other banks of registers (keyword \emph{\_\_using} \emph{\index{__using (mcs51, ds390 register bank)@\_\_using (mcs51, ds390 register bank)}})
should be used for example in interrupt\index{interrupt}\index{__interrupt@\_\_interrupt}
routines. By default, the compiler will place the stack after the
last byte of allocated memory for variables. For example, if the first
2 banks of registers are used, and only four bytes are used for \emph{\_\_data}
variables, it will position the base of the internal stack at address
20 (0x14). This implies that as the stack\index{stack} grows, it
will use up the remaining register banks, and the 16 bytes used by
the 128 bit variables, and 80 bytes for general purpose use. If any
bit variables are used, the \emph{\_\_data} variables will be placed
in unused register banks and after the byte holding the last \_\_bit
variable. For example, if register banks 0 and 1 are used, and there
are 9 bit variables (two bytes used), \emph{\_\_data} variables will
be placed starting from address 0x10 to 0x20 and continue at address
0x22. You can also use -\/-data-loc\index{-/-data-loc <Value>@-\/-data-loc <Value>}
to specify the start address of the \emph{\_\_data} and -\/-iram-size\index{-/-iram-size <Value>@-\/-iram-size <Value>}
to specify the size of the total internal RAM (\emph{\_\_idata}).
\\

By default the 8051 linker will place the stack after the last byte
of \_\_(i)data variables. Option -\/-stack-loc\index{-/-stack-loc <Value>@-\/-stack-loc <Value>}
allows you to specify the start of the stack, i.e. you could start
it after any data in the general purpose area. If your microcontroller
has additional indirectly addressable internal RAM (\emph{idata})
you can place the stack on it. You may also need to use -\/-xdata-loc\index{-/-xdata-loc<Value>@-\/-xdata-loc<Value>}
to set the start address of the external RAM (\emph{xdata}) and -\/-xram-size\index{-/-xram-size <Value>@-\/-xram-size <Value>}
to specify its size. Same goes for the code memory, using -\/-code-loc\index{-/-code-loc <Value>@-\/-code-loc <Value>}
and -\/-code-size\index{-/-code-size <Value>@-\/-code-size <Value>}.
If in doubt, don't specify any options and see if the resulting memory
layout is appropriate, then you can adjust it.

The linker generates two files with memory allocation information.
The first, with extension .map\index{<file>.map} shows all the variables
and segments. The second with extension .mem\index{<file>.mem} shows
the final memory layout. The linker will complain either if memory
segments overlap, there is not enough memory, or there is not enough
space for stack. If you get any linking warnings and/or errors related
to stack or segments allocation, take a look at either the .map or
.mem files to find out what the problem is. The .mem file may even
suggest a solution to the problem.

\subsection{Z80/Z180/eZ80 intrinsic named address spaces}

\subsubsection{\_\_sfr\index{__sfr@\_\_sfr} (in/out to 8-bit addresses)}

The Z80\index{Z80} family has separate address spaces for memory
and \emph{i}nput/\emph{o}utput memory. I/O memory\index{I/O memory (Z80, Z180)}\index{Z80!I/O memory}\index{Z180!I/O memory}
is accessed with special instructions, e.g.:
\begin{verse}
\texttt{\_\_sfr \_\_at(0x78) IoPort;~~/{*} define a var in I/O space
at 78h called IoPort {*}/ }
\end{verse}
Writing 0x01 to this variable generates the assembly code:
\begin{verse}
\texttt{3E 01~~~~~~ld a,\#0x01}~\\
\texttt{D3 78~~~~~~out (\_IoPort),a }
\end{verse}

\subsubsection{\_\_banked \_\_sfr\index{__sfr@\_\_sfr} (in/out to 16-bit addresses)}

The keyword \emph{\_\_banked} is used to support 16 bit addresses
in I/O memory e.g.:
\begin{verse}
\texttt{\_\_sfr \_\_banked \_\_at\index{__at@\_\_at}(0x123) IoPort; }
\end{verse}
Writing 0x01 to this variable generates the assembly code:
\begin{verse}
\texttt{01 23 01~~~ld bc,\#\_IoPort}~\\
\texttt{3E 01~~~~~~ld a,\#0x01}~\\
\texttt{ED 79~~~~~~out (c),a }
\end{verse}

\subsubsection{\_\_sfr\index{__sfr@\_\_sfr} (in0/out0 to 8 bit addresses on Z180\index{Z180}/HD64180\index{HD64180 (see Z180)})}

The compiler option -\/-portmode\index{Z180!Options!-/-portmode@-\/-portmode}=180
(80) and a compiler \#pragma~portmode\index{Z180!Pragmas!#pragma portmode@\#pragma portmode}
z180 (z80) is used to turn on (off) the Z180/HD64180 port addressing
instructions \texttt{in0/out0} instead of \texttt{in/out}. If you
include the file z180.h this will be set automatically.

\subsection{SM83 intrinsic named address spaces}

\subsubsection{\_\_sfr\index{__sfr@\_\_sfr}}

The keyword \emph{\_\_sfr} is an alternative way to access memory
locations 0xff00 to 0xffff, which are typically used for memory-mapped
I/O e.g.:
\begin{verse}
\texttt{\_\_sfr \_\_at\index{__at@\_\_at}(0xff01) IoPort; }
\end{verse}

\subsection{HC08/S08 intrinsic named address spaces}

\subsubsection{\_\_data\index{__data (hc08 named address space)@\_\_data (hc08 named address space)} }

Variables in the address space \_\_data resides in the first 256 bytes
of memory (the direct page). The HC08\index{HC08} is most efficient
at accessing variables (especially pointers) stored here.

\subsubsection{\_\_xdata\index{__xdata (hc08 named address space)@\_\_xdata (hc08 named address space)} }

Variables in the address space\_\_xdata can reside anywhere in memory.
This is the default (generic address space).

\subsection{PDK14/PDK15 intrinsic named address spaces}

\subsubsection{\_\_sfr\index{__sfr@\_\_sfr}}

The Padauk family has separate address spaces for memory and \emph{i}nput/\emph{o}utput
memory. I/O memory is accessed with special instructions, e.g.:
\begin{verse}
\texttt{\_\_sfr \_\_at(0x18) gpcc;~~/{*} define a var in I/O space
at 18h called gpcc {*}/}
\end{verse}

\subsubsection{\_\_sfr16\index{__sfr16@\_\_sfr16}}

The Padauk family has a 16-bit timer accessed with special instructions.

\subsection{MOS6502 intrinsic named address spaces}

\subsubsection{\_\_zp/\_\_data\index{__data (mos6502 named address space)@\_\_data (mos6502 named address space)}
/\_\_near}

Variables in the address space \_\_zp reside in the first 256 bytes
of memory (the Page Zero). The MOS6502\index{MOS6502} is most efficient
at accessing variables stored here. Pointers can only be dereferenced
directly if they reside in Page Zero. This is the default for the
small memory model.

\subsubsection{\_\_xdata\index{__xdata (mos6502 named address space)@\_\_xdata (mos6502 named address space)}
/\_\_far}

Variables in the address space \_\_xdata can reside anywhere in the
64K memory space. This is the default (for the large memory model).

\subsection{Non-intrinsic named address spaces\index{Non-intrinsic named address spaces}}

SDCC supports user-defined non-intrinsic named address spaces. So
far SDCC only supports them for bank-switching. You need to have a
function that switches to the desired memory bank and declare a corresponding
named address space:
\begin{verse}
\texttt{void setb0(void); // The function that sets the currently
active memory bank to b0}~\\
\texttt{void setb1(void); // The function that sets the currently
active memory bank to b1}~\\
\texttt{\_\_addressmod}\index{__addressmod@\_\_addressmod}\texttt{
setb0 spaceb0; // Declare a named address space called spaceb0 that
uses setb0()}~\\
\texttt{\_\_addressmod setb1 spaceb1; // Declare a named address space
called spaceb1 that uses setb1()}~\\
\texttt{spaceb0 int x; // An int in address space spaceb0}~\\
\texttt{spaceb1 int {*}y; // A pointer to an int in address space
spaceb1}~\\
\texttt{spaceb0 int {*}spaceb1 z; // A pointer in address space spaceb1
that points to an int in address space spaceb0}
\end{verse}
Non-intrinsic named address spaces for data in ROM are declared using
the const keyword:
\begin{verse}
\texttt{void setb0(void); // The function that sets the currently
active memory bank to b0}~\\
\texttt{void setb1(void); // The function that sets the currently
active memory bank to b1}~\\
\texttt{\_\_addressmod}\index{__addressmod@\_\_addressmod}\texttt{
setb0 const spaceb0; // Declare a named address space called spaceb0
that uses setb0() and resides in ROM}~\\
\texttt{\_\_addressmod setb1 spaceb1; // Declare a named address space
called spaceb1 that uses setb1() and resides in RAM}~\\
\texttt{const spaceb0 int x = 42; // An int in address space spaceb0}~\\
\texttt{spaceb1 int {*}y; // A pointer to an int in address space
spaceb1}~\\
\texttt{const spaceb0 int {*}spaceb1 z; // A pointer in address space
spaceb1 that points to a constant int in address space spaceb0}
\end{verse}
Variables in non-intrinsic named address spaces will be placed in
areas of the same name (this can be used for the placement of named
address spaces in memory by the linker).

SDCC will automatically insert calls to the corresponding function
before accessing the variable. SDCC inserts the minimum possible number
calls to the bank selection functions. See Philipp Klaus Krause, ''Optimal
Placement of Bank Selection Instructions in Polynomial Time'' for
details on how this works.

\subsection{Absolute Addressing\index{Absolute addressing}}

Data items can be assigned an absolute address with the \emph{\_\_at\index{__at@\_\_at}
<address>} keyword (the address needs to be either a parenthesized
constant expression or a constant), which can also be used in addition
to a named address space, e.g.:
\begin{verse}
\texttt{\_\_xdata unsigned int \_\_at (0x7ffe) chksum;}
\end{verse}
In the above example the variable chksum will be located at 0x7ffe
and 0x7fff of the external ram. The compiler does \emph{not} reserve
any space for variables declared in this way\marginpar{\textbf{~!}}
(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\index{<file>.lst}) and the linker output files
(.rst\index{<file>.rst}) and (.map\index{<file>.map}) are good places
to look for such overlaps.

If however you provide an initializer\index{Variable initialization}
actual memory allocation will take place and overlaps will be detected
by the linker. E.g.:
\begin{verse}
\texttt{\_\_code char \_\_at (0x7ff0) Id{[}5{]} = ''SDCC'';}
\end{verse}
In the above example the variable Id will be located from 0x7ff0 to
0x7ff4 in code memory.

In case of memory mapped I/O devices the keyword \emph{volatile} has
to be used to tell the compiler that accesses might not be removed:
\begin{verse}
\texttt{volatile\index{volatile} \_\_xdata\index{__xdata (mcs51, ds390 named address space)@\_\_xdata (mcs51, ds390 named address space)}
unsigned char \_\_at\index{__at@\_\_at} (0x8000) PORTA\_8255;}
\end{verse}
For some architectures (mcs51) array accesses are more efficient if
an (xdata/far) array{\footnotesize\texttt{\index{Aligned array}}}
starts at a block (256 byte) boundary\index{block boundary} (section
\ref{subsec:A-Step-by Assembler Introduction} has an example).\\
Absolute addresses can be specified for variables in all named address
spaces, e.g.:
\begin{verse}
\texttt{\_\_bit\index{__bit@\_\_bit} \_\_at\index{__at@\_\_at} (0x02)
bvar;}
\end{verse}
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. One possible use would be to write
hardware portable code. For example, if you have a routine that uses
one or more of the microcontroller I/O pins, and such pins are different
for two different hardwares, you can declare the I/O pins in your
routine using:
\begin{verse}
\texttt{extern volatile\index{volatile} \_\_bit MOSI;~~~~/{*}
master out, slave in {*}/}~\\
\texttt{extern volatile \_\_bit MISO;~~~~/{*} master in, slave
out {*}/}~\\
\texttt{extern volatile \_\_bit MCLK;~~~~/{*} master clock {*}/}~\\
\texttt{}~\\
\texttt{/{*} Input and Output of a byte on a 3-wire serial bus.}~\\
\texttt{~~~If needed adapt polarity of clock, polarity of data
and bit order}~\\
\texttt{~{*}/}~\\
\texttt{unsigned char spi\_io(unsigned char out\_byte)}~\\
\texttt{\{ }~\\
\texttt{~~~~unsigned char i=8;}~\\
\texttt{~~~~do \{ }~\\
\texttt{~~~~~~~~MOSI = out\_byte \& 0x80;}~\\
\texttt{~~~~~~~~out\_byte <\textcompwordmark <= 1;}~\\
\texttt{~~~~~~~~MCLK = 1;}~\\
\texttt{~~~~~~~~/{*} \_\_asm nop \_\_endasm; {*}/~~~~~~~~/{*}
for slow peripherals {*}/}~\\
\texttt{~~~~~~~~if(MISO)}~\\
\texttt{~~~~~~~~~~~~out\_byte += 1;}~\\
\texttt{~~~~~~~~MCLK = 0;}~\\
\texttt{~~~~\} while(-{}-i);}~\\
\texttt{~~~~return out\_byte;}~\\
\texttt{\}}
\end{verse}
Then, someplace in the code for the first hardware you would use
\begin{verse}
\texttt{\_\_bit \_\_at\index{__at@\_\_at} (0x80) MOSI;~~~~/{*}
I/O port 0, bit 0 {*}/}~\\
\texttt{\_\_bit \_\_at (0x81) MISO;~~~~/{*} I/O port 0, bit 1
{*}/}~\\
\texttt{\_\_bit \_\_at (0x82) MCLK;~~~~/{*} I/O port 0, bit 2
{*}/}
\end{verse}
Similarly, for the second hardware you would use
\begin{verse}
\texttt{\_\_bit \_\_at (0x83) MOSI;~~~~/{*} I/O port 0, bit 3
{*}/}~\\
\texttt{\_\_bit \_\_at (0x91) MISO;~~~~/{*} I/O port 1, bit 1
{*}/}~\\
\texttt{\_\_bit\index{__bit@\_\_bit} \_\_at (0x92) MCLK;~~~~/{*}
I/O port 1, bit 2 {*}/}
\end{verse}
and you can use the same hardware dependent routine without changes,
as for example in a library. This is somehow similar to sbit, but
only one absolute address has to be specified in the whole project.

\subsection{\_\_sdcc\_external\_startup\index{__sdcc_external_startup@\_\_sdcc\_external\_startup}}

When a function \code{unsigned char \_\_sdcc\_external\_startup(void)}
is present, it is executed before both the initialization of static
and global variables, as well as \code{main}. This allows to implement
functionality that needs to be done early. For example: disabling
a hardware watchdog that would otherwise bite during the time it takes
to initialize global variables; setup or calibration of system/peripheral
clocks; or, a memory check that needs to be done before any memory
(other than the return address for \code{\_\_sdcc\_external\_startup}
itself) is in use.

If this routine returns a non-zero value, the static and global variable
initialization will be skipped and the function \code{main} will
be invoked. Otherwise static and global variables will be initialized
before the function \code{main} is invoked.

For mos6502, z80, z80n, z180, sm83, ez80\_z80, tlcs90, r2k, r2ka,
r3ka, when using a custom crt0, support depends on the custom crt0.

\subsection{Preserved register specification}

SDCC allows to specify preserved registers in function declarations,
to enable further optimizations on calls to functions implemented
in assembler. Example for the Z80 architecture specifying that a function
will preserve register pairs bc and iy:
\begin{verse}
\texttt{void f(void) \_\_preserves\_regs(b, c, iyl, iyh);}
\end{verse}

\subsection{Binary constants\index{Binary constants}}

SDCC supports the use of C23 binary constants, such as 0b01100010
when the compiler is invoked using \code{-{}-std-sdccxx}, even when
the corresponding \code{-{}-std-cxx}, does not. Note: \code{xx}
is a placeholder for the desired version of the C standard.

\subsection{Returning void}

SDCC allows functions to return expressions of type void. This feature
is only enabled when the compiler is invoked using \code{-{}-std-sdccxx}.
Note: \code{xx} is a placeholder for the desired version of the C
standard.

\subsection{Omitting promotion on arguments of vararg function (does not apply
to pdk13, pdk14, pdk15)}

Arguments to vararg functions are not promoted when explicitly cast.
This feature is only enabled when the compiler is invoked using \code{-{}-std-sdccxx}.
This breaks compability with the C standards, so linking code compiled
with \code{-{}-std-sdccxx} with code compiled using \code{-{}-std-cxx}
can result in failing programs when arguments to vararg functions
are explicitly cast. Note: \code{xx} is a placeholder for the desired
version of the C standard.

\section{Parameters\index{Parameters}\index{function parameter} and Local
Variables\index{local variables}\label{sec:Parameters-and-Local-Variables}}

Automatic (local) variables and parameters to functions are placed
on the stack for most targets. For MCS51/DS390/HC08/S08/MOS6502/PDK13/PDK14/PDK15
they 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 medium or large model).
This in fact makes them similar to \emph{static\index{static}} so
by default functions are non-reentrant\index{reentrant}. \\
\\
They can be placed on the stack\index{stack} by using the \emph{-\/-stack-auto\index{-/-stack-auto@-\/-stack-auto}}
option, by using \emph{\#pragma~stackauto}\index{#pragma stackauto@\#pragma stackauto}
or by using the \emph{\_\_reentrant\index{reentrant}} keyword in
the function declaration, e.g.:
\begin{verse}
\texttt{unsigned char foo(char i) \_\_reentrant}~\\
\texttt{\{ }~\\
\texttt{~~~~... }~\\
\texttt{\}}
\end{verse}
Since stack space on 8051 and MOS6502 is limited, and accessing the
stack is slow for the Padauk, the \emph{\_\_reentrant} keyword or
the \emph{-\/-stack-auto} option should be used sparingly. Note that
the \emph{\_\_reentrant} keyword just means that the parameters \&
local variables will be allocated to the stack, it \emph{does not}
mean that the function is register bank\index{register bank (mcs51, ds390)}
independent.\\
\\
Local variables\index{local variables} can be assigned intrinsic
named address spaces and absolute\index{Absolute addressing} addresses,
e.g.: 
\begin{verse}
\texttt{unsigned char foo(\_\_xdata int parm)}~\\
\texttt{\{}~\\
\texttt{~~~~\_\_xdata unsigned char i;}~\\
\texttt{~~~~\_\_bit bvar;}~\\
\texttt{~~~~\_\_data unsigned char \_\_at\index{at} (0x31) j;}~\\
\texttt{~~~~... }~\\
\texttt{\}}
\end{verse}
In the above example the parameter\index{function parameter} \emph{parm}
and the variable \emph{i} will be allocated in the external ram, \emph{bvar}
in bit addressable space and \emph{j} in internal ram. When compiled
with \emph{-\/-stack-auto} or when a function is declared as \emph{reentrant}
this should only be done for static variables.

It is however allowed to use bit parameters in reentrant functions
and also non-static local bit variables are supported. Efficient use
is limited to 8 semi-bitregisters in bit space. They are pushed and
popped to stack\index{stack} as a single byte just like the normal
registers.

\section{Overlaying\label{subsec:Overlaying}\index{Overlaying}}

For non-reentrant\index{reentrant} functions SDCC will try to reduce
internal ram space usage by overlaying parameters and local variables
of a function (if possible). Parameters and local variables\index{local variables}
of a function will be allocated to an overlayable segment if the function
has \emph{no other function calls and the function is non-reentrant
and the memory model\index{Memory model} is small.} If an explicit
intrinsic named address space\index{intrinsic named address space}
is specified for a local variable, it will NOT be overlaid.

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\marginpar{\textbf{!}} should be preceded by a \#pragma~nooverlay\index{#pragma nooverlay@\#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 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\index{Multiplication} or division\index{Division}
will NOT be overlaid since these are implemented using external functions,
e.g.:
\begin{verse}
\texttt{\#pragma save}~\\
\texttt{\#pragma nooverlay\index{#pragma nooverlay@\#pragma nooverlay}}~\\
\texttt{void set\_error(unsigned char errcd)}~\\
\texttt{\{}~\\
\texttt{~~~~P3 = errcd;}~\\
\texttt{\} }~\\
\texttt{\#pragma restore}~\\
\texttt{}~\\
\texttt{void some\_isr () \_\_interrupt\index{interrupt} (2)}~\\
\texttt{\{}~\\
\texttt{~~~~...}~\\
\texttt{~~~~set\_error(10);}~\\
\texttt{~~~~...}~\\
\texttt{\}}
\end{verse}
In the above example the parameter \emph{errcd} for the function \emph{set\_error}
would be assigned to the overlayable segment if the \#pragma~nooverlay
was not present, this could cause unpredictable runtime behaviour
when called from an interrupt service routine. The \#pragma~nooverlay
ensures that the parameters and local variables for the function are
NOT overlaid.

\section{Interrupt Service Routines\label{subsec:Interrupt-Service-Routines}}

\subsection{General Information}

SDCC allows \emph{i}nterrupt \emph{s}ervice \emph{r}outines to be
coded in C, with some extended keywords.
\begin{verse}
\texttt{void timer\_isr (void) \_\_interrupt (1) \_\_using (1)}~\\
\texttt{\{}~\\
\texttt{~~~~...}~\\
\texttt{\}}
\end{verse}
The optional number following the \emph{\_\_interrupt\index{interrupt}\index{__interrupt@\_\_interrupt}}
keyword is the interrupt number this routine will service. When present,
the compiler will insert a call to this routine in the interrupt vector
table\index{interrupt vector table} for the interrupt number specified.
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 or included in the file that contains the function
\emph{main}. The optional (8051 specific) keyword \emph{\_\_using\index{__using (mcs51, ds390 register bank)@\_\_using (mcs51, ds390 register bank)}}
can be used to tell the compiler to use the specified register bank
when generating code for this function.\\
Interrupt service routines open the door for some very interesting
bugs:

\subsubsection{\label{subsec:Common-interrupt-pitfall-volatile}Common interrupt
pitfall: variable not declared \emph{volatile}}

If an interrupt service routine changes variables which are accessed
by other functions these variables have to be declared \emph{volatile}\index{volatile}.
See \url{http://en.wikipedia.org/wiki/Volatile_variable}.

\subsubsection{\label{subsec:Common-interrupt-pitfall-non-atomic}Common interrupt
pitfall: \emph{non-atomic access}}

If the access to these variables is not \emph{atomic\index{atomic}}
(i.e. the processor needs more than one instruction for the access
and could be interrupted while accessing the variable) the interrupt
must be disabled during the access to avoid inconsistent data. \\
Access to 16 or 32 bit variables is obviously not atomic on 8 bit
CPUs and should be protected by disabling interrupts. You're not automatically
on the safe side if you use 8 bit variables though. We need an example
here: f.e. on the 8051 the harmless looking ''\texttt{flags~|=~0x80;}''
is not atomic if \texttt{flags} resides in xdata. Setting ''\texttt{flags~|=~0x40;}''
from within an interrupt routine might get lost if the interrupt occurs
at the wrong time. ''\texttt{counter~+=~8;}'' is not atomic on
the 8051 even if \texttt{counter} is located in data memory.\\
Bugs like these are hard to reproduce and can cause a lot of trouble. 

\subsubsection{\label{subsec:Common-interrupt-pitfall-stack-overflow}Common interrupt
pitfall: \emph{stack overflow}}

The return address and the registers used in the interrupt service
routine are saved on the stack\index{stack} so there must be sufficient
stack space. If there isn't variables or registers (or even the return
address itself) will be corrupted. This \emph{stack overflow}\index{stack overflow}
is most likely to happen if the interrupt occurs during the ''deepest''
subroutine when the stack is already in use for f.e. many return addresses.

\subsubsection{\label{subsec:Common-interrupt-pitfall-non-reentrant}Common interrupt
pitfall: \emph{use of non-reentrant functions}}

A special note here, integer multiplicative operators and floating-point\index{Floating point support}
operations might be implemented using external support routines, depending
on the target architecture. If an interrupt service routine needs
to do any of these operations on a target where functions are non-reentrant
by default, then the support routines (as mentioned in a following
section) will have to be recompiled using the \emph{-\/-stack-auto\index{-/-stack-auto@-\/-stack-auto}}
option and the source file will need to be compiled using the \emph{-\/-int-long-reent}\index{-/-int-long-reent@-\/-int-long-reent}
compiler option. \\
Note, the type promotion\index{type promotion} required by ANSI C
can cause 16 bit routines to be used\marginpar{\textbf{~!}} without
the programmer being aware of it. See f.e. the cast \texttt{\textbf{(unsigned
char)(tail-1)}} \textbf{within the if clause in section \ref{subsec:A-Step-by Assembler Introduction}.}

Calling other functions from an interrupt service routine on a target
where functions are non-reentrant by default is not recommended, avoid
it if possible. Note that when some function is called from an interrupt
service routine it should be preceded by a \#pragma~nooverlay\index{#pragma nooverlay@\#pragma nooverlay}
if it is not reentrant. Furthermore non-reentrant functions should
not be called from the main program while the interrupt service routine
might be active. They also must not be called from low priority interrupt
service routines while a high priority interrupt service routine might
be active. You could use semaphores or make the function \emph{critical}
if all parameters are passed in registers.\\
 Also see section \ref{subsec:Overlaying}~about Overlaying and section
\ref{subsec:Functions-using-private-banks}~about Functions using
private register banks.

\subsection{MCS51/DS390 Interrupt Service Routines}

Interrupt\index{interrupt} numbers and the corresponding address
\& descriptions for the Standard 8051/8052 are listed below. SDCC
will automatically adjust the \index{interrupt vector table} to the
maximum interrupt number specified.\\

\begin{center}
\begin{tabular}{|c|l|l|}
\hline 
Interrupt \# & Description & Vector Address\tabularnewline
\hline 
\hline 
0 & External 0 & 0x0003\tabularnewline
\hline 
1 & Timer 0 & 0x000b\tabularnewline
\hline 
2 & External 1 & 0x0013\tabularnewline
\hline 
3 & Timer 1 & 0x001b\tabularnewline
\hline 
4 & Serial & 0x0023\tabularnewline
\hline 
\multicolumn{1}{|c|}{5} & Timer 2 (8052) & 0x002b\tabularnewline
\hline 
... &  & ...\tabularnewline
\hline 
n &  & 0x0003 + 8{*}n\tabularnewline
\hline 
\end{tabular}\\
\par\end{center}

If the interrupt service routine is defined without \emph{\_\_using\index{using (mcs51, ds390 register bank)}\index{__using (mcs51, ds390 register bank)@\_\_using (mcs51, ds390 register bank)}}
a register bank or with register bank 0 (\emph{\_\_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 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 \emph{a, b, dptr} \& psw are saved 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\index{stack}. This scheme is
recommended for larger interrupt service routines.

\subsection{HC08\index{HC08} Interrupt Service Routines}

Since the number of interrupts\index{HC08!interrupt} available is
chip specific and the interrupt vector table always ends at the last
byte of memory, the interrupt numbers corresponds to the interrupt
vectors in reverse order of address. For example, interrupt 1 will
use the interrupt vector at 0xfffc, interrupt 2 will use the interrupt
vector at 0xfffa, and so on. However, interrupt 0 (the reset vector
at 0xfffe) is not redefinable in this way; instead see section \ref{subsec:MCS51-Startup-Code}
for details on customizing startup.

\subsection{Z80, Z180 and eZ80 Interrupt Service Routines}

The Z80\index{Z80} uses several different methods for determining
the correct interrupt\index{Z80!interrupt} vector depending on the
hardware implementation. Therefore, SDCC does not attempt to generate
an interrupt vector table.

By default, SDCC generates code for a maskable interrupt, which uses
a RETI instruction to return from the interrupt. To write an interrupt
handler for the non-maskable interrupt, which needs a RETN instruction
instead, leave out the interrupt number:
\begin{verse}
\texttt{void nmi\_isr (void) \_\_critical \_\_interrupt}~\\
\texttt{\{}~\\
\texttt{~~~~...}~\\
\texttt{\}}
\end{verse}
Since interrupts on the Z80 and Z180 are level-triggered (except for
the NMI), interruptible interrupt handlers should only be used where
hardware acknowledge is available.

\begin{tabular}{|l|l|>{\raggedright}p{0.3\textwidth}|}
\hline 
Type & Syntax & Behaviour\tabularnewline
\hline 
\hline 
Interruptible interrupt handler & void f(void) \_\_interrupt & Interrupt handler can be interrupted by further interrupts\tabularnewline
\hline 
Non-interruptible interrupt handler & void f(void) \_\_critical \_\_interrupt(0) & Interrupt handler can be interrupted by NMI only\tabularnewline
\hline 
NMI handler & void f(void) \_\_critical \_\_interrupt & Interrupt handler can be interrupted by NMI only\tabularnewline
\hline 
\end{tabular}

\subsection{Rabbit 2000, 3000 and 3000A Interrupt Service Routines}

SDCC does not attempt to generate an interrupt vector table.

\begin{tabular}{|l|l|>{\raggedright}p{0.3\textwidth}|}
\hline 
Type & Syntax & Behaviour\tabularnewline
\hline 
\hline 
Interruptible interrupt handler & void f(void) \_\_interrupt & Interrupt handler can be interrupted by further interrupts of same
priority\tabularnewline
\hline 
Non-interruptible interrupt handler & void f(void) \_\_critical \_\_interrupt(0) & Interrupt handler can be interrupted by interrupts of higher priority
only\tabularnewline
\hline 
\end{tabular}

\subsection{SM83 and TLCS-90 Interrupt Service Routines}

SDCC does not attempt to generate an interrupt vector table.

\begin{tabular}{|l|l|>{\raggedright}p{0.3\textwidth}|}
\hline 
Type & Syntax & Behaviour\tabularnewline
\hline 
\hline 
Interruptible interrupt handler & void f(void) \_\_interrupt & Interrupt handler can be interrupted by further interrupts\tabularnewline
\hline 
Non-interruptible interrupt handler & void f(void) \_\_critical \_\_interrupt(0) & Interrupt handler cannot be interrupted by further interrupts\tabularnewline
\hline 
\end{tabular}

\subsection{STM8 Interrupt Service Routines}

The STM8 interrupt table contains 31 entries: Reset (used by SDCC
for program startup), trap and user interrupts 0 to 29. Where the
keyword \emph{\_\_interrupt\index{interrupt}} is used for normal
user interrupts, the \emph{\_\_trap} keyword is used for the trap
handler:
\begin{verse}
\texttt{void handler (void) \_\_trap}~\\
\texttt{\{}~\\
\texttt{~~~~...}~\\
\texttt{\}}
\end{verse}

\section{Enabling and Disabling Interrupts}

\subsection{Critical Functions and Critical Statements}

A special keyword may be associated with a block or a function declaring
it as \emph{\_\_critical}. SDCC will generate code to disable all
interrupts\index{interrupt} upon entry to a critical function and
restore the interrupt enable to the previous state before returning
(for architectures where there is no efficient way to do so (sm83,
tlcs90, stm8), interrupts will be unconditionally enabled instead).
Nesting critical functions will need one additional byte on the stack\index{stack}
for each call.
\begin{verse}
\texttt{int foo () \_\_critical\index{critical}\index{__critical@\_\_critical}}~\\
\texttt{\{}~\\
\texttt{~~~~...}~\\
\texttt{~~~~...}~\\
\texttt{\}}
\end{verse}
The critical attribute maybe used with other attributes like \emph{reentrant.}\\
The keyword \emph{\_\_critical} may also be used to disable interrupts
more locally:
\begin{verse}
\texttt{\_\_critical\{ i++; \}}
\end{verse}
More than one statement could have been included in the block.

\subsection{Enabling and Disabling Interrupts directly}

Interrupts\index{interrupt} can also be disabled and enabled directly
(8051):
\begin{verse}
\texttt{EA = 0;~~~~~~~~~~~~or:~~~~~~~~~~~EA\_SAVE
= EA;}

\texttt{...~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~EA
= 0;}

\texttt{EA = 1;~~~~~~~~~~~~~~~~~~~~~~~~~~...}

\texttt{~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~EA
= EA\_SAVE;}
\end{verse}
On other architectures which have separate opcodes for enabling and
disabling interrupts you might want to make use of defines with inline
assembly\index{Assembler routines} (HC08\index{HC08!interrupt}):
\begin{verse}
\texttt{\#define CLI \_\_asm\index{__asm@\_\_asm}~~cli~~\_\_endasm\index{__endasm@\_\_endasm}; }

\texttt{\#define SEI \_\_asm~~sei~~\_\_endasm; }

or for SDCC version 3.2.0 or newer:

\texttt{\#define CLI \_\_asm\_\_ (''cli''); }

\texttt{\#define SEI \_\_asm\_\_ (''sei''); }
\end{verse}
Note: it is sometimes sufficient to disable only a specific interrupt
source like f.e. a timer or serial interrupt by manipulating an \emph{interrupt
mask\index{interrupt mask}} register. 

Usually the time during which interrupts are disabled should be kept
as short as possible. This minimizes both \emph{interrupt latency}\index{interrupt latency}
(the time between the occurrence of the interrupt and the execution
of the first code in the interrupt routine) and \emph{interrupt jitter}\index{interrupt jitter}
(the difference between the shortest and the longest interrupt latency).
These really are something different, f.e. a serial interrupt has
to be served before its buffer overruns so it cares for the maximum
interrupt latency, whereas it does not care about jitter. On a loudspeaker
driven via a digital to analog converter which is fed by an interrupt
a latency of a few milliseconds might be tolerable, whereas a much
smaller jitter will be very audible.

You can re-enable interrupts within an interrupt routine and on some
architectures you can make use of two (or more) levels of \emph{interrupt
priorities}\index{interrupt priority}. On some architectures which
don't support interrupt priorities these can be implemented by manipulating
the interrupt mask and re-enabling interrupts within the interrupt
routine. Check there is sufficient space on the stack\index{stack}
and don't add complexity unless you have to. 

\subsection{Semaphore\index{semaphore} locking (mcs51/ds390)}

Some architectures (mcs51/ds390) have an atomic\index{atomic} bit
test and clear instruction. These type of instructions are typically
used in preemptive multitasking systems, where a routine f.e. claims
the use of a data structure ('acquires a lock\index{lock} on it'),
makes some modifications and then releases the lock when the data
structure is consistent again. The instruction may also be used if
interrupt and non-interrupt code have to compete for a resource. With
the atomic bit test and clear instruction interrupts\index{interrupt}
don't have to be disabled for the locking operation. 

SDCC generates this instruction if the source follows this pattern:
\begin{verse}
\texttt{volatile\index{volatile} bit resource\_is\_free;}~\\
\texttt{}~\\
\texttt{if (resource\_is\_free)}~\\
\texttt{~~\{}~\\
\texttt{~~~~resource\_is\_free=0;}~\\
\texttt{~~~~...}~\\
\texttt{~~~~resource\_is\_free=1;}~\\
\texttt{~~\} }
\end{verse}
Note, mcs51 and ds390 support only an atomic\index{atomic} bit test
and \emph{clear} instruction (as opposed to atomic bit test and \emph{set).}

\section{Functions using private register banks\label{subsec:Functions-using-private-banks}
(mcs51/ds390)}

Some architectures have support for quickly changing register sets.
SDCC supports this feature with the \emph{\_\_using\index{using (mcs51, ds390 register bank)}\index{__using (mcs51, ds390 register bank)@\_\_using (mcs51, ds390 register bank)}}
attribute (which tells the compiler to use a register bank\index{register bank (mcs51, ds390)}
other than the default bank zero). It should only be applied to \emph{interrupt\index{interrupt}}
functions (see footnote 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 \emph{\_\_using} attribute will have no effect on the generated
code for a \emph{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 'interrupt' functions. For instance,
if you have several ISRs using bank one, and all of them call memcpy(),
it might make sense to create a specialized version of memcpy() 'using
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}).\\
\emph{(pending: Note, nowadays the} \_\_using \emph{attribute has
an effect on} \emph{the generated code for a} non-interrupt \emph{function}.\emph{)}

An \emph{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\index{interrupts}\index{interrupt priority} can interrupt
low-priority ones on the 8051 and friends, this means that if a high-priority
ISR \emph{using} a particular bank occurs while processing a low-priority
ISR \emph{using} the same bank, terrible and bad things can happen.
To prevent this, no single register bank should be \emph{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 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. 

\section{Inline Assembler Code\label{sec:Inline-Assembler-Code}\index{Assembler routines}}

\subsection{Inline Assembler Code Formats}

SDCC supports two formats for inline assembler code definition:

\subsubsection{Old \_\_asm ... \_\_endasm; Format}

Most of inline assembler code examples in this manual use the old
inline assembler code format, but the new format could be used equivalently.

Example:
\begin{verse}
\texttt{\_\_asm}\\
\texttt{~~~~; This is a comment}~\\
\texttt{~~~~label:}~\\
\texttt{~~~~~~~~nop}~\\
\texttt{\_\_endasm;}
\end{verse}
Note: As of SDCC 4.2.9, assembler comments occurring in this type
of inline assembler block are affected by macro expansion.

\subsubsection{New \_\_asm\_\_ (\textquotedblright inline\_assembler\_code\textquotedblright )
Format}

The \_\_asm\_\_ inline assembler code format was introduced in SDCC
version 3.2.0. Its main advantage is that it is compatible with all
standard compliant C preprocessors.

Example:
\begin{verse}
\texttt{\_\_asm\_\_ (''; This is a comment\textbackslash nlabel:\textbackslash n\textbackslash tnop'');}
\end{verse}
%
Or for better readability:
\begin{verse}
\texttt{\_\_asm\_\_ (}

\texttt{''; This is a comment\textbackslash n''}

\texttt{''label:\textbackslash n''}

\texttt{''~~~~nop''}

\texttt{);}
\end{verse}

\subsection{A Step by Step Introduction\label{subsec:A-Step-by Assembler Introduction}}

Starting from a small snippet of c-code this example shows for the
MCS51 how to use inline assembly, access variables, a function parameter
and an array in xdata memory. The example uses an MCS51 here but is
easily adapted for other architectures. This is a buffer routine which
should be optimized:
\begin{verse}
{\footnotesize\texttt{unsigned char \_\_far\index{__far (named address space)@\_\_far (named address space)}
\_\_at\index{__at@\_\_at}(0x7f00) buf{[}0x100{]};\index{Aligned array}}}~\\
{\footnotesize\texttt{unsigned char head, tail;~~~~~~~~~~~~~~~~~/{*}
if interrupts\index{interrupt} are involved see}}~\\
{\footnotesize\texttt{~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~section
\ref{subsec:Common-interrupt-pitfall-volatile} about}}{\footnotesize{}
}{\footnotesize\texttt{\textbf{volatile}}}{\footnotesize{} }{\footnotesize\texttt{{*}/}}~\\
{\footnotesize\texttt{}}~\\
{\footnotesize\texttt{void to\_buffer( unsigned char c ) }}~\\
{\footnotesize\texttt{\{}}~\\
{\footnotesize\texttt{~~~~if( head != (unsigned char)(tail-1)
)~/{*} cast}}{\footnotesize{} }{\footnotesize\texttt{\textbf{needed}}}{\footnotesize{}
}{\footnotesize\texttt{to avoid promotion\index{promotion to signed int}\index{type promotion}
to integer {*}/}}{\footnotesize{\ttfamily\marginpar{\textbf{~!}}}}{\footnotesize\texttt{}}~\\
{\footnotesize\texttt{~~~~~~~~buf{[} head++ {]} = c;~~~~~~~~~~~~~~~~/{*}
access to a 256 byte aligned array {*}/}}~\\
{\footnotesize\texttt{\} }}{\footnotesize\par}
\end{verse}
If the code snippet (assume it is saved in buffer.c) is compiled with
SDCC then a corresponding buffer.asm file is generated. We define
a new function \texttt{to\_buffer\_asm()} in file buffer.c in which
we cut and paste the generated code, removing unwanted comments and
some ':'. Then add ''\textbf{\_\_asm}'' and ''\textbf{\_\_endasm;}''\footnote{Note, that the single underscore form (\_asm and \_endasm) are not
C99 compatible, and for C99 compatibility, the double-underscore form
(\_\_asm and \_\_endasm) has to be used. The latter is also used in
the library functions.} to the beginning and the end of the function body:
\begin{verse}
{\footnotesize\texttt{/{*} With a cut and paste from the .asm file,
we have something to start with.}}~\\
{\footnotesize\texttt{~~~The function is not yet OK! (registers
aren't saved) {*}/ }}~\\
{\footnotesize\texttt{void to\_buffer\_asm( unsigned char c ) }}~\\
{\footnotesize\texttt{\{ }}~\\
{\footnotesize\texttt{~~~~\_\_asm\index{__asm@\_\_asm}}}~\\
{\footnotesize\texttt{~~~~mov~~r2,dpl}}~\\
{\footnotesize\texttt{;buffer.c if( head != (unsigned char)(tail-1)
) ~/{*} cast}}{\footnotesize{} }{\footnotesize\texttt{\textbf{needed}}}{\footnotesize{}
}{\footnotesize\texttt{to avoid promotion\index{promotion to signed int}\index{type promotion}
to integer {*}/}}~\\
{\footnotesize\texttt{~~~~mov~~a,\_tail}}~\\
{\footnotesize\texttt{~~~~dec~~a}}~\\
{\footnotesize\texttt{~~~~mov~~r3,a}}~\\
{\footnotesize\texttt{~~~~mov~~a,\_head}}~\\
{\footnotesize\texttt{~~~~cjne a,ar3,00106\$}}~\\
{\footnotesize\texttt{~~~~ret}}~\\
{\footnotesize\texttt{00106\$:}}~\\
{\footnotesize\texttt{;buffer.c buf{[} head++ {]} = c; /{*} access
to a 256 byte aligned array {*}/\index{Aligned array}}}~\\
{\footnotesize\texttt{~~~~mov~~r3,\_head}}~\\
{\footnotesize\texttt{~~~~inc~~\_head}}~\\
{\footnotesize\texttt{~~~~mov~~dpl,r3}}~\\
{\footnotesize\texttt{~~~~mov~~dph,\#(\_buf >\textcompwordmark >
8)}}~\\
{\footnotesize\texttt{~~~~mov~~a,r2}}~\\
{\footnotesize\texttt{~~~~movx @dptr,a}}~\\
{\footnotesize\texttt{00103\$:}}~\\
{\footnotesize\texttt{~~~~ret}}~\\
{\footnotesize\texttt{~~~~\_\_endasm\index{__endasm@\_\_endasm};}}~\\
{\footnotesize\texttt{\} }}{\footnotesize\par}
\end{verse}
The new file buffer.c should compile with only one warning about the
unreferenced function argument 'c'. Now we hand-optimize the assembly
code and insert an \#define USE\_ASSEMBLY (1) and finally have:
\begin{verse}
{\footnotesize\texttt{unsigned char \_\_far \_\_at(0x7f00) buf{[}0x100{]};}}~\\
{\footnotesize\texttt{unsigned char head, tail;}}~\\
{\footnotesize\texttt{\#define USE\_ASSEMBLY (1)}}~\\
{\footnotesize\texttt{}}~\\
{\footnotesize\texttt{\#if !USE\_ASSEMBLY}}~\\
{\footnotesize\texttt{}}~\\
{\footnotesize\texttt{void to\_buffer( unsigned char c )}}~\\
{\footnotesize\texttt{\{}}~\\
{\footnotesize\texttt{~~~~if( head != (unsigned char)(tail-1)
)}}~\\
{\footnotesize\texttt{~~~~~~~~buf{[} head++ {]} = c;}}~\\
{\footnotesize\texttt{\}}}~\\
{\footnotesize\texttt{}}~\\
{\footnotesize\texttt{\#else}}~\\
{\footnotesize\texttt{}}~\\
{\footnotesize\texttt{void to\_buffer( unsigned char c )}}~\\
{\footnotesize\texttt{\{}}~\\
{\footnotesize\texttt{~~~~c; // to avoid warning: unreferenced
function argument}}~\\
{\footnotesize\texttt{~~~~\_\_asm\index{__asm@\_\_asm}}}~\\
{\footnotesize\texttt{~~~~~~~~; save used registers here.}}~\\
{\footnotesize\texttt{~~~~~~~~; If we were still using r2,r3
we would have to push them here.}}~\\
{\footnotesize\texttt{; if( head != (unsigned char)(tail-1) )}}~\\
{\footnotesize\texttt{~~~~~~~~mov~ a,\_tail}}~\\
{\footnotesize\texttt{~~~~~~~~dec~ a}}~\\
{\footnotesize\texttt{~~~~~~~~xrl~ a,\_head}}~\\
{\footnotesize\texttt{~~~~~~~~; we could do an ANL a,\#0x0f
here to use a smaller buffer (see below)}}~\\
{\footnotesize\texttt{~~~~~~~~jz~~ t\_b\_end\$}}~\\
{\footnotesize\texttt{~~~~~~~~;}}~\\
{\footnotesize\texttt{; buf{[} head++ {]} = c;}}~\\
{\footnotesize\texttt{~~~~~~~~mov~ a,dpl ~~~~~~~;
dpl holds lower byte of function argument}}~\\
{\footnotesize\texttt{~~~~~~~~mov~ dpl,\_head ~~~; buf
is 0x100 byte aligned so head can be used directly}}~\\
{\footnotesize\texttt{~~~~~~~~mov~ dph,\#(\_buf>\textcompwordmark >8)}}~\\
{\footnotesize\texttt{~~~~~~~~movx @dptr,a}}~\\
{\footnotesize\texttt{~~~~~~~~inc ~\_head}}~\\
{\footnotesize\texttt{~~~~~~~~; we could do an ANL \_head,\#0x0f
here to use a smaller buffer (see above)}}~\\
{\footnotesize\texttt{t\_b\_end\$:}}~\\
{\footnotesize\texttt{~~~~~~~~; restore used registers here}}~\\
{\footnotesize\texttt{~~~~\_\_endasm\index{__endasm@\_\_endasm};}}~\\
{\footnotesize\texttt{\}}}~\\
{\footnotesize\texttt{\#endif}}{\footnotesize\par}
\end{verse}
The inline assembler code can contain any valid code understood by
the assembler, this includes any assembler directives and comment
lines. The assembler does not like some characters like ':' or '''
in comments. You'll find an 100+ pages assembler manual in sdcc/sdas/doc/asmlnk.txt\index{sdas (sdasgb, sdas6808, sdas8051, sdasz80)}\index{Assembler documentation}
or online at \url{http://svn.code.sf.net/p/sdcc/code/trunk/sdcc/sdas/doc/asmlnk.txt}.

The compiler does not do any validation of the code within the \texttt{\_\_asm\index{__asm@\_\_asm}
... \_\_endasm}{\footnotesize\texttt{\index{__endasm@\_\_endasm}}}\texttt{;}
keyword pair. Specifically it will not know which registers are used
and thus register pushing/popping\index{push/pop} has to be done
manually. 

It is required that each assembly instruction be placed on a separate
line. This is also recommended for labels (as the example shows).
This is especially important to note when the inline assembler is
placed in a C preprocessor macro as the preprocessor will normally
put all replacing code on a single line. Only when the macro has each
assembly instruction on a single line that ends with a line continuation
character will it be placed as separate lines in the resulting .asm
file.
\begin{verse}
{\footnotesize\texttt{\#define~DELAY~~~\textbackslash}}~\\
{\footnotesize\texttt{~~~~\_\_asm~~~~~~~\textbackslash}}~\\
{\footnotesize\texttt{~~~~~~~~nop~~~~~\textbackslash}}~\\
{\footnotesize\texttt{~~~~~~~~nop~~~~~\textbackslash}}~\\
{\footnotesize\texttt{~~~~\_\_endasm}}{\footnotesize\par}
\end{verse}
When the -\/-\emph{peep-asm\index{-/-peep-asm@-\/-peep-asm}} command
line option is used, the inline assembler code will be passed through
the peephole optimizer\index{Peephole optimizer}. There are only
a few (if any) cases where this option makes sense, it might cause
some unexpected changes in the inline assembler code. Please go through
the peephole optimizer rules defined in file \emph{peeph.def} before
using this option.

\subsection{Naked Functions\label{subsec:Naked-Functions}\index{Naked functions}}

A special keyword may be associated with a function declaring it as
\emph{\_\_naked\index{_naked@\_naked}\index{__naked@\_\_naked}.}
The \emph{\_naked} function modifier attribute prevents the compiler
from generating prologue\index{function prologue} and epilogue\index{function 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 \emph{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 often
unnecessary) prologue/epilogue. For example, compare the code generated
by these two functions:
\begin{verse}
\texttt{volatile\index{volatile} \_\_data unsigned char counter;}~\\
\texttt{}~\\
\texttt{void simpleInterrupt(void) \_\_interrupt\index{interrupt}\index{__interrupt@\_\_interrupt}
(1)}~\\
\texttt{\{}~\\
\texttt{~~~~counter++;}~\\
\texttt{\}}~\\
\texttt{}~\\
\texttt{void nakedInterrupt(void) \_\_interrupt (2) \_\_naked}~\\
\texttt{\{}~\\
\texttt{~~~~\_\_asm\index{__asm@\_\_asm}}~\\
\texttt{~~~~~~inc~~~~~\_counter ; does not change flags,
no need to save psw}~\\
\texttt{~~~~~~reti~~~~; MUST explicitly include ret or reti
in \_naked function.}~\\
\texttt{~~~~\_\_endasm\index{__endasm@\_\_endasm};}~\\
\texttt{\}}
\end{verse}
For an 8051 target, the generated simpleInterrupt looks like:
\begin{verse}
\texttt{Note, this is an} \texttt{\emph{outdated}} \texttt{example,
recent versions of SDCC generate}~\\
\texttt{the} \texttt{\emph{same}} \texttt{code for simpleInterrupt()
and nakedInterrupt()!}~\\
\texttt{}~\\
\texttt{\_simpleInterrupt:}~\\
\texttt{~~~~push~~~~acc}~\\
\texttt{~~~~push~~~~b}~\\
\texttt{~~~~push~~~~dpl}~\\
\texttt{~~~~push~~~~dph}~\\
\texttt{~~~~push~~~~psw}~\\
\texttt{~~~~mov~~~~~psw,\#0x00}~\\
\texttt{~~~~inc~~~~~\_counter}~\\
\texttt{~~~~pop~~~~~psw}~\\
\texttt{~~~~pop~~~~~dph}~\\
\texttt{~~~~pop~~~~~dpl}~\\
\texttt{~~~~pop~~~~~b}~\\
\texttt{~~~~pop~~~~~acc}~\\
\texttt{~~~~reti}
\end{verse}
whereas nakedInterrupt looks like:
\begin{verse}
\texttt{\_nakedInterrupt:}~\\
\texttt{~~~~inc~~~~\_counter ; does not change flags, no need
to save psw}~\\
\texttt{~~~~reti~~~~~~~~~~~~; MUST explicitly include
ret or reti in \_naked function}
\end{verse}
The related directive \#pragma exclude\index{#pragma exclude@\#pragma exclude}
allows a more fine grained control over pushing \& popping\index{push/pop}
the registers.

While there is nothing preventing you from writing C code inside a
\texttt{\_naked} function, there are many ways to shoot yourself in
the foot doing this, and it is recommended that you stick to inline
assembler.

\subsection{Use of Labels within Inline Assembler}

SDCC allows the use of in-line assembler with a few restrictions regarding
labels. All labels defined within inline assembler code have to be
of the form \emph{nnnnn\$} where nnnnn is a number less than 100 (which
implies a limit of utmost 100 inline assembler labels \emph{per function}\noun{)}.\footnote{This is a slightly more stringent rule than absolutely necessary,
but stays always on the safe side. Labels in the form of nnnnn\$ are
local labels in the assembler, locality of which is confined within
two labels of the standard form. The compiler uses the same form for
labels within a function (but starting from nnnnn=00100); and places
always a standard label at the beginning of a function, thus limiting
the locality of labels within the scope of the function. So, if the
inline assembler part would be embedded into C-code, an improperly
placed non-local label in the assembler would break up the reference
space for labels created by the compiler for the C-code, leading to
an assembling error.

The numeric part of local labels does not need to have 5 digits (although
this is the form of labels output by the compiler), any valid integer
will do. Please refer to the assemblers documentation for further
details.} 
\begin{verse}
\texttt{\_\_asm\index{__asm@\_\_asm}}~\\
\texttt{~~~~mov~~~~~b,\#10}~\\
\texttt{00001\$:}~\\
\texttt{~~~~djnz~~~~b,00001\$}~\\
\texttt{\_\_endasm\index{__endasm@\_\_endasm} ;}
\end{verse}
Inline assembler code cannot reference any C-labels, however it can
reference labels\index{Labels} defined by the inline assembler, e.g.:
\begin{verse}
\texttt{foo() \{}~\\
\texttt{~~~~/{*} some c code {*}/}~\\
\texttt{~~~~\_\_asm}~\\
\texttt{~~~~~~; some assembler code}~\\
\texttt{~~~~~~ljmp 0003\$}~\\
\texttt{~~~~\_\_endasm;}~\\
\texttt{~~~~/{*} some more c code {*}/}~\\
\texttt{clabel:~~/{*} inline assembler cannot reference this label
{*}/ }{\ttfamily\footnote{Here, the C-label \texttt{clabel} is translated by the compiler into
a local label, so the locality of labels within the function is not
broken.}}\texttt{}~\\
\texttt{~~~~\_\_asm}~\\
\texttt{~~~~0003\$: ;label (can be referenced by inline assembler
only)}~\\
\texttt{~~~~\_\_endasm\index{__endasm@\_\_endasm} ;}~\\
\texttt{~~~~/{*} some more c code {*}/}~\\
\texttt{\}}
\end{verse}
In other words inline assembly code can access labels defined in inline
assembly within the scope of the function. The same goes the other
way, i.e. labels defines in inline assembly can not be accessed by
C statements.

\section{Support routines for integer multiplicative operators}

Depending on the target architecture, some integer multiplicative
operators might be implemented by support routines. These support
routines exist in portable C versions to facilitate porting to other
MCUs, although depending on the target, assembler routines might be
used instead. The following files contain some of the described routines,
all of them can be found in <installdir>/share/sdcc/lib.\\

\begin{center}
\begin{tabular}{|l|l|}
\hline 
\textbf{Function} & \textbf{Description}\tabularnewline
\hline 
\hline 
\_mulint.c  & 16 bit multiplication\tabularnewline
\hline 
\_divsint.c  &  signed 16 bit division (calls \_divuint)\tabularnewline
\hline 
\_divuint.c  &  unsigned 16 bit division\tabularnewline
\hline 
\_modsint.c & signed 16 bit modulus (calls \_moduint)\tabularnewline
\hline 
\_moduint.c & unsigned 16 bit modulus\tabularnewline
\hline 
\_mullong.c & 32 bit multiplication\tabularnewline
\hline 
\_divslong.c  &  signed 32 division (calls \_divulong)\tabularnewline
\hline 
\_divulong.c  & unsigned 32 division\tabularnewline
\hline 
\_modslong.c &  signed 32 bit modulus (calls \_modulong)\tabularnewline
\hline 
\_modulong.c & unsigned 32 bit modulus\tabularnewline
\hline 
\end{tabular}\\
\par\end{center}

In the mcs51, ds390, hc08, s08, pdk13, pdk14, pdk15, pic14 and pic16
backends they are by default compiled as \emph{non-reentrant}\index{reentrant};
when targeting on of these architectures, interrupt\index{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 \emph{-\/-stack-auto\index{-/-stack-auto@-\/-stack-auto}} option,
after which the source program will have to be compiled with \emph{-\/-int-long-reent\index{-/-int-long-reent@-\/-int-long-reent}}
option. Notice that you don't have to call these routines directly.
The compiler will use them automatically every time an integer operation
is required.

\section{Floating Point Support\index{Floating point support}}

SDCC supports (single precision 4 bytes) floating point numbers; the
format is somewhat similar to IEEE, but it is not IEEE; in particular,
denormalized floating -point numbers are not supported. The floating
point support routines are derived from gcc's floatlib.c and consist
of the following routines:\\

\begin{center}
{\footnotesize{}%
\begin{tabular}{|l|l|}
\hline 
Function  & Description\tabularnewline
\hline 
\hline 
\_fsadd.c & add floating point numbers\tabularnewline
\hline 
\_fssub.c  & subtract floating point numbers\tabularnewline
\hline 
\_fsdiv.c  & divide floating point numbers\tabularnewline
\hline 
\_fsmul.c  & multiply floating point numbers\tabularnewline
\hline 
\_fs2uchar.c & convert floating point to unsigned char\tabularnewline
\hline 
\_fs2schar.c & convert floating point to signed char\tabularnewline
\hline 
\_fs2uint.c & convert floating point to unsigned int\tabularnewline
\hline 
\_fs2sint.c & convert floating point to signed int\tabularnewline
\hline 
\_fs2ulong.c & convert floating point to unsigned long\tabularnewline
\hline 
\_fs2slong.c & convert floating point to signed long\tabularnewline
\hline 
\_uchar2fs.c & convert unsigned char to floating point\tabularnewline
\hline 
\_schar2fs.c & convert signed char to floating point\tabularnewline
\hline 
\_uint2fs.c & convert unsigned int to floating point\tabularnewline
\hline 
\_sint2fs.c & convert signed int to floating point\tabularnewline
\hline 
\_ulong2fs.c & convert unsigned long to floating point\tabularnewline
\hline 
\_slong2fs.c & convert signed long to floating point\tabularnewline
\hline 
\_ulonglong2fs.c & convert unsigned long long to floating point\tabularnewline
\hline 
\_slonglong2fs.c & convert singed long long to floating point\tabularnewline
\hline 
\end{tabular}}{\footnotesize}\\
{\footnotesize\par}
\par\end{center}

\section{Library Routines\index{Libraries}}

\emph{<pending: this is messy and incomplete - a little more information
is at }\url{http://sdcc.sourceforge.net/wiki/index.php/List_of_the_SDCC_library}>

\subsection{Compiler support routines (\_gptrget, \_mulint etc.)}

\subsection{Stdclib functions (puts, printf, strcat etc.)}

\subsubsection{<stdio.h>}

\paragraph{getchar(), putchar()}

\index{<stdio.h>}As usual on embedded systems you have to provide
your own \texttt{getchar()\index{getchar()}} and \texttt{putchar()\index{putchar()}\index{printf()!putchar()}}
routines. SDCC does not know whether the system connects to a serial
line with or without handshake, LCD, keyboard or other device. And
whether a \texttt{lf} to \texttt{crlf} conversion within \texttt{putchar()}
is intended. You'll find examples for serial routines f.e. in sdcc/device/lib.
For the mcs51 this minimalistic polling \texttt{putchar()} routine
might be a start:
\begin{verse}
\texttt{int putchar (int c) \{}~\\
\texttt{~~~~while (!TI)~~~ /{*} assumes UART is initialized
{*}/}~\\
\texttt{~~~~~~~~;}~\\
\texttt{~~~~TI = 0;}~\\
\texttt{~~~~SBUF = c;}

\texttt{~~~~return c;}

\texttt{\}}
\end{verse}

\paragraph{printf()}

The default \texttt{printf()\index{printf()}} implementation in \texttt{printf\_large.c}
does not support float\index{Floating point support} (except on ds390),
only <NO FLOAT>\index{<NO FLOAT>}\index{printf()!floating point support}
will be printed instead of the value. To enable floating point output,
recompile it with the option \emph{-\/DUSE\_FLOATS=1\index{USE_FLOATS@USE\_FLOATS}}
on the command line. Use \emph{-\/-model-large\index{-/-model-large@-\/-model-large}}
for the mcs51 port, since this uses a lot of memory. To enable float
support for the pic16 targets, see \ref{subsec:pic16Libraries}.

If you're short on code memory you might want to use \texttt{printf\_small()\index{printf()!printf_small()@printf\_small()}}
\emph{instead} of \texttt{printf().} For the mcs51 there additionally
are assembly versions \texttt{printf\_tiny()\index{printf()!printf_tiny() (mcs51)@printf\_tiny() (mcs51)}}
(subset of printf using less than 270 bytes) and \texttt{printf\_fast()\index{printf()!printf_fast() (mcs51)@printf\_fast() (mcs51)}}
and \texttt{printf\_fast\_f()\index{printf()!printf_fast_f() (mcs51)@printf\_fast\_f() (mcs51)}}
(floating-point aware version of printf\_fast) which should fit the
requirements of many embedded systems (printf\_fast() can be customized
by unsetting \#defines to \emph{not} support long variables and field
widths). Be sure to use only one of these printf options within a
project.\\

Feature matrix of different \emph{printf} options on mcs51.

\begin{longtable}[c]{|>{\raggedright}m{0.14\columnwidth}|c|>{\centering}p{0.12\columnwidth}|>{\centering}p{0.1\columnwidth}|c|>{\centering}p{0.12\columnwidth}|c|}
\hline 
{\large\textbf{mcs51}} & printf\index{printf()} & printf {\scriptsize USE\_FLOATS=1} & printf\_small & printf\_fast & printf\_fast\_f & printf\_tiny\tabularnewline
\hline 
\hline 
filename & {\scriptsize printf\_large.c} & {\scriptsize printf\_large.c} & {\scriptsize printfl.c} & {\scriptsize printf\_fast.c} & {\scriptsize printf\_fast\_f.c} & {\scriptsize printf\_tiny.c}\tabularnewline
\hline 
''Hello World'' size

small / large & 1.7k / 2.4k & 4.3k / 5.6k & 1.2k / 1.8k & 1.3k / 1.3k & 1.9k / 1.9k & 0.44k / 0.44k\tabularnewline
\hline 
code size

small / large & 1.4k / 2.0k & 2.8k / 3.7k & 0.45k / 0.47k (+ \_ltoa) & 1.2k / 1.2k & 1.6k / 1.6k & 0.26k / 0.26k\tabularnewline
\endhead
\hline 
formats & cdi\emph{o}psux & cdfi\emph{o}psux & cd\emph{o}sx & cdsux & cdfsux & cdsux\tabularnewline
\hline 
long (32 bit) support & x & x & x & x & x & -\tabularnewline
\hline 
byte arguments on stack & b & b & - & - & - & -\tabularnewline
\hline 
float format\index{Floating point support} & - & \%f & - & - & \%f\footnote{Range limited to +/- 4294967040, precision limited to 8 digits past
decimal} & -\tabularnewline
\hline 
float formats \%e \%g & - & - & - & - & - & -\tabularnewline
\hline 
field width & x & x & - & x & x & -\tabularnewline
\hline 
string speed\footnote{Execution time of printf(\textquotedbl\%s\%c\%s\%c\%c\%c\textquotedbl ,
\textquotedbl Hello\textquotedbl , ' ', \textquotedbl World\textquotedbl ,
'!', '\textbackslash r', '\textbackslash n'); standard 8051 @ 22.1184
MHz, empty putchar()},

small / large & 1.52 / 2.59 ms & 1.53 / 2.62 ms & 0.92 / 0.93 ms & 0.45 / 0.45 ms & 0.46 / 0.46 ms & 0.45 / 0.45 ms\tabularnewline
\hline 
int speed\footnote{Execution time of printf(\textquotedbl\%d\textquotedbl , -12345);
standard 8051 @ 22.1184 MHz, empty putchar()},

small / large & 3.01 / 3.61 ms & 3.01 / 3.61 ms & 3.51 / 18.13 ms & 0.22 / 0.22 ms & 0.23 / 0.23 ms & 0.25 / 0.25 ms\footnote{printf\_tiny integer speed is data dependent, worst case is 0.33 ms}\tabularnewline
\hline 
long speed\footnote{Execution time of printf(\textquotedbl\%ld\textquotedbl , -123456789);
standard 8051 @ 22.1184 MHz, empty putchar()},

small / large & 5.37 / 6.31 ms & 5.37 / 6.31 ms & 8.71 / 40.65 ms & 0.40 / 0.40 ms & 0.40 / 0.40 ms & -\tabularnewline
\hline 
float speed\footnote{Execution time of printf(\textquotedbl\%.3f\textquotedbl , -12345.678);
standard 8051 @ 22.1184 MHz, empty putchar()},

small / large & - & 7.49 / 22.47 ms & - & - & 1.04 / 1.04 ms & -\tabularnewline
\hline 
\end{longtable}

\subsubsection{<malloc.h>\index{malloc.h}}

As of SDCC 2.6.2 you no longer need to call an initialization routine
before using dynamic memory allocation\index{dynamic memory allocation (malloc)}
and a default heap\index{heap (malloc)} space of 1024 bytes is provided
for malloc to allocate memory from. If you need a different heap size
you need to recompile \_heap.c with the required size defined in HEAP\_SIZE.
It is recommended to make a copy of this file into your project directory
and compile it there with:
\begin{verse}
\texttt{sdcc -c \_heap.c -D HEAP\_SIZE=2048}
\end{verse}
And then link it with:
\begin{verse}
\texttt{sdcc main.rel \_heap.rel}
\end{verse}

\subsection{Math functions (sinf, powf, sqrtf etc.)}

\subsubsection{<math.h>}

See definitions in file <math.h>.

\subsection{Other libraries}

Libraries\index{Libraries} included in SDCC should have a license
at least as liberal as the GPLv2+LE\index{GPLv2+LE}. Exception are
pic device libraries and header files which are derived from Microchip
header (.inc) and linker script (.lkr) files. Microchip requires that
\textquotedbl The header files should state that they are only to
be used with authentic Microchip devices\textquotedbl{} which makes
them incompatible with GPL.

If you have ported some library or want to share experience about
some code which f.e. falls into any of these categories Busses (I$^{\textrm{2}}$C,
CAN, Ethernet, Profibus, Modbus, USB, SPI, JTAG ...), Media (IDE,
Memory cards, eeprom, flash...), En-/Decryption, Remote debugging,
Realtime kernel, Keyboard, LCD, RTC, FPGA, PID then the sdcc-user
mailing list \url{http://sourceforge.net/p/sdcc/mailman/sdcc-user/}
would certainly like to hear about it.

Programmers coding for embedded systems are not especially famous
for being enthusiastic, so don't expect a big hurray but as the mailing
list is searchable these references are very valuable. Let's help
to create a climate where information is shared.

\section{Memory Models}

\subsection{MCS51 Memory Models\index{Memory model}\index{MCS51 memory model}}

\subsubsection{Small, Medium, Large and Huge}

SDCC allows four memory models for MCS51 code, \textsl{small, medium,
large} and \textsl{huge}. Modules compiled with different memory models
should \emph{never} be combined together or the results would be unpredictable.
The library routines supplied with the compiler are compiled for all
models (however, the libraries for –stack-auto are compiled for the
small and large models only). The compiled library modules are contained
in separate directories as small, medium, large and huge so that you
can link to the appropriate set.

When the medium, large or huge model is used all variables declared
without specifying an intrinsic named address space will be allocated
into the external ram, this includes all parameters and local variables
(for non-reentrant\index{reentrant} functions). Medium model uses
pdata and large and huge models use xdata. When the small model is
used variables without an explicitly specified intrinsic named address
space are allocated in the internal ram.

The huge model compiles all functions as \emph{banked\ref{subsec:Bankswitching}}
and is otherwise equal to large for now. All other models compile
the functions without bankswitching by default.

Judicious usage of the processor specific intrinsic named address
spaces\index{intrinsic named address space} and the 'reentrant' function
type will yield much more efficient code, than using the large model.
Several optimizations are disabled when the program is compiled using
the large model, it is therefore recommended that the small model
be used unless absolutely required.

\subsubsection{External Stack\label{subsec:External-Stack}\index{stack}\index{External stack (mcs51)}}

The external stack (-\/-xstack option\index{-/-xstack@-\/-xstack})
is located in pdata\index{__pdata (mcs51, ds390 named address space)@\_\_pdata (mcs51, ds390 named address space)}
memory (usually at the start of the external ram segment) and uses
all unused space in pdata (max. 256 bytes). When -\/-xstack option
is used to compile the program, the parameters and local variables\index{local variables}
of all reentrant functions are allocated in this area. This option
is provided for programs with large stack space requirements. When
used with the -\/-stack-auto\index{-/-stack-auto@-\/-stack-auto}
option, all parameters and local variables are allocated on the external
stack (note: support libraries will need to be recompiled with the
same options. There is a predefined target in the library makefile).

The compiler outputs the higher order address byte of the external
ram segment into port P2\index{P2 (mcs51 sfr)} (see also section
\ref{subsec:MCS51-variants}), therefore when using the External Stack
option, this port \emph{may not} be used by the application program.

\subsection{DS390 Memory Model\index{Memory model}\index{DS390 memory model}}

The only model supported is Flat 24\index{Flat 24 (DS390 memory model)}.
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.\\
\\
Note that the compiler does not generate any code to place the processor
into 24 bit mode (although \emph{tinibios} in the ds390 libraries
will do that for you). If you don't use \emph{tinibios}\index{Tinibios (DS390)},
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 \emph{-\/-model-large} option, variables will by default
be placed into the XDATA segment.\\
\\
Segments may be placed anywhere in the 4 meg address space using the
usual -\/-{*}-loc options. Note that if any segments are located
above 64K, the -r flag must be passed to the 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
\emph{-Wl-r} on the SDCC command line. However, currently the linker
can not handle code segments > 64k.

\subsection{STM8 Memory Models\index{Memory model}\index{STM8 memory models}}

SDCC implements two memory models for the STM8: \emph{medium} (default)
and \emph{large}. Modules compiled with different memory models should
\emph{never} be combined together. The library routines supplied with
the compiler are compiled for all models.

In the medium model the address space is 16 bits for both objects
and functions, allowing for a memory space of 64 KB. Since the STM8
typically has Flash starting at 0x8000, this means that only up to
32 KB of Flash can be used (most STM8 devices don't have more than
32 KB of Flash).

In the large memory model, the address space is 16 bits for objects
and 24 bits for functions. Since the STM8 typically has flash starting
at 0x8000, this means that up to 32 KB of flash can be used for constant
data, while the whole Flash can be used for functions. Code generated
for the large model is slightly bigger and slower and needs slightly
more stack space than code generated for the medium model.

\subsection{MOS6502 Memory Models\index{Memory model}\index{MOS6502 memory models}}

SDCC implements two memory models for the MOS6502: \emph{small} and
\emph{large} (default). Modules compiled with different memory models
should \emph{never} be combined together. The library routines supplied
with the compiler are compiled for all models.

In the small model all data objects are placed by default in Page
Zero. This is normally only useful in embedded systems.

In the large memory model, data is placed by default in 16-bit addressable
memory. Critical data can still be placed in Page Zero using the \_\_ZP
or \_\_near storage modifier. Code generated for the large model is
slightly bigger and slower than code generated for the small model.

\section{Pragmas\label{sec:Pragmas}\index{Pragmas}}

Pragmas are used to turn on and/or off certain compiler options. Some
of them are closely related to corresponding command-line options
(see section \vref{sec:Command-Line-Options}).\\
Pragmas should be placed before and/or after a function, placing pragmas
inside a function body could have unpredictable results.\\
\\
SDCC supports the following \#pragma directives:
\begin{itemize}
\item \textbf{save}\index{#pragma save@\#pragma save} - this will save
most current options to the save/restore stack. See \#pragma~restore.
\item \textbf{restore}\index{#pragma restore@\#pragma restore} - will restore
saved options from the last save. saves \& restores can be nested.
SDCC uses a save/restore stack: save pushes current options to the
stack, restore pulls current options from the stack. See \#pragma~save.\\
\item \textbf{callee\_saves}\index{#pragma callee_saves@\#pragma callee\_saves}\index{function prologue}
function1{[},function2{[},function3...{]}{]} \label{ite:callee_saves-function1=00005B.function2=00005B.function3...=00005D=00005D--}-
The compiler by default uses a caller saves convention for register
saving across function calls, however this can cause unnecessary register
pushing and popping\index{push/pop} when calling small functions
from larger functions. This option can be used to switch off the register
saving convention for the function names specified. The compiler will
not save registers when calling these functions, extra code need to
be manually inserted at the entry and exit for these functions to
save and restore the registers used by these functions, this can SUBSTANTIALLY
reduce code and improve run time performance of the generated code.
In the future the compiler (with inter procedural analysis) may be
able to determine the appropriate scheme to use for each function
call. If -\/-callee-saves command line option is used (see page \vpageref{lyx:--callee-saves-function1=00005B.function2=00005D=00005B.function3=00005D...}),
the function names specified in \#pragma~callee\_saves\index{#pragma callee_saves@\#pragma callee\_saves}
is appended to the list of functions specified in the command line.
\item \textbf{exclude}\index{#pragma exclude@\#pragma exclude} none | \{acc{[},b{[},dpl{[},dph{[},bits{]}{]}{]}{]}\}
- The exclude pragma disables the generation of pairs of push/pop\index{push/pop}
instructions in \emph{I}nterrupt\index{interrupt} \emph{S}ervice
\emph{R}outines. 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\index{#pragma exclude@\#pragma exclude}.
See also the related keyword \emph{\_\_naked}\index{_naked@\_naked}\index{__naked@\_\_naked}.
\item \textbf{less\_pedantic}\index{pedantic}\index{#pragma less_pedantic@\#pragma less\_pedantic}\label{ite:less_pedantic}
- the compiler will not warn you anymore for obvious mistakes, you're
on your own now ;-(. See also the command line option -\/-less-pedantic
\vpageref{lyx:--less-pedantic}. \\
More specifically, the following warnings will be disabled: \textit{comparison
is always {[}true/false{]} due to limited range of data type} (94);
\textit{overflow in implicit constant conversion} (158); {[}the (in)famous{]}
\textit{conditional flow changed by optimizer: so said EVELYN the
modified DOG} (110); \textit{function '{[}function name{]}' must return
value} (59). \\
Furthermore, warnings of less importance (of PEDANTIC and INFO warning
level) are disabled, too, namely: \textit{constant value '{[}{]}',
out of range} (81); \textit{{[}left/right{]} shifting more than size
of object changed to zero} (116); \textit{unreachable code} (126);
\textit{integer overflow in expression} (165); \textit{unmatched \#pragma
save and \#pragma restore} (170); \textit{comparison of 'signed char'
with 'unsigned char' requires promotion to int} (185); \textit{ISO
C90 does not support flexible array members} (187); \textit{extended
stack by {[}number{]} bytes for compiler temp(s) :in function '{[}function~name{]}':~{[}{]}}
(114); \textit{function '{[}function name{]}', \# edges {[}number{]}
, \# nodes {[}number{]} , cyclomatic complexity {[}number{]}} (121).
\item \textbf{disable\_warning} <nnnn>\index{#pragma disable_warning@\#pragma disable\_warning}
- the compiler will not warn you anymore about warning number <nnnn>.
\item \textbf{nogcse}\index{#pragma nogcse@\#pragma nogcse} - will stop
global common subexpression elimination.
\item \textbf{noinduction}\index{#pragma noinduction@\#pragma noinduction}
- will stop loop induction optimizations.
\item \textbf{noinvariant}\index{#pragma noinvariant@\#pragma noinvariant}
- will not do loop invariant optimizations. For more details see Loop
Invariants in section\ref{subsec:Loop-Optimizations}.
\item \textbf{noiv}\index{#pragma noiv@\#pragma noiv} - Do not generate
interrupt\index{interrupt} vector table\index{interrupt vector table}
entries for all ISR functions defined after the pragma. This is useful
in cases where the interrupt vector table must be defined manually,
or when there is a secondary, manually defined interrupt vector table
(e.g. for the autovector feature of the Cypress EZ-USB FX2). More
elegantly this can be achieved by omitting the optional interrupt
number after the \emph{\_\_interrupt} keyword, see section \ref{subsec:Interrupt-Service-Routines}~about
interrupts.
\item \textbf{noloopreverse}\index{#pragma noloopreverse@\#pragma noloopreverse}
- Will not do loop reversal optimization
\item \textbf{nooverlay}\index{#pragma nooverlay@\#pragma nooverlay} -
the compiler will not overlay the parameters and local variables of
a function.
\item \textbf{stackauto}\index{#pragma stackauto@\#pragma stackauto}- See
option -\/-stack-auto\index{-/-stack-auto@-\/-stack-auto} and section
\ref{sec:Parameters-and-Local-Variables} Parameters and Local Variables.
\item \textbf{opt\_code\_speed} \index{#pragma opt_code_speed@\#pragma opt\_code\_speed}-
The compiler will optimize code generation towards fast code, possibly
at the expense of code size.
\item \textbf{opt\_code\_size} \index{#pragma opt_code_size@\#pragma opt\_code\_size}-
The compiler will optimize code generation towards compact code, possibly
at the expense of code speed. 
\item \textbf{opt\_code\_balanced} \index{#pragma opt_code_balanced@\#pragma opt\_code\_balanced}-
The compiler will attempt to generate code that is both compact and
fast, as long as meeting one goal is not a detriment to the other
(this is the default). 
\item \textbf{std\_sdcc89} \index{#pragma std_sdcc89@\#pragma std\_sdcc89}-
Generally follow the C89 standard, but allow SDCC features that conflict
with the standard.
\item \textbf{std\_c89} \index{#pragma std_c89@\#pragma std\_c89}- Follow
the C89 standard and disable SDCC features that conflict with the
standard.
\item \textbf{std\_sdcc99} \index{#pragma std_sdcc99@\#pragma std\_sdcc99}-
Generally follow the C99 standard, but allow SDCC features that conflict
with the standard.
\item \textbf{std\_c99} \index{#pragma std_c99@\#pragma std\_c99}- Follow
the C99 standard and disable SDCC features that conflict with the
standard.
\item \textbf{std\_c11} \index{#pragma std_c11@\#pragma std\_c11}- Follow
the C11 standard and disable SDCC features that conflict with the
standard.
\item \textbf{std\_sdcc11} \index{#pragma std_sdcc11@\#pragma std\_sdcc11}-
Generally follow the C11 standard, but allow SDCC features that conflict
with the standard.
\item \textbf{std\_c23}\index{#pragma std_c23@\#pragma std\_c23}- Follow
the C23 standard and disable SDCC features that conflict with the
standard (for backwards compatibility, \textbf{std\_c2x} still exists
as an alias).
\item \textbf{std\_sdcc23} \index{#pragma std_sdcc23@\#pragma std\_sdcc23}-
Generally follow the C23 standard, but allow SDCC features that conflict
with the standard.
\item \textbf{std\_c2}y\index{#pragma std_c2y@\#pragma std\_c2y}- Follow
the C2y standard and disable SDCC features that conflict with the
standard.
\item \textbf{std\_sdcc2y} \index{#pragma std_sdcc2y@\#pragma std\_sdcc2y}-
Generally follow the C2y standard, but allow SDCC features that conflict
with the standard.
\item \textbf{codeseg} <name>\index{#pragma codeseg@\#pragma codeseg}-
Use this name (max. 8 characters) for the code segment. See option
-\/-codeseg.
\item \textbf{constseg} <name>\index{#pragma constseg@\#pragma constseg}-
Use this name (max. 8 characters) for the const segment. See option
-\/-constseg.
\end{itemize}
The preprocessor\index{Preprocessor} SDCPP\index{sdcpp (preprocessor)}
supports the following \#pragma directives:
\begin{itemize}
\item \textbf{preproc\_asm}\index{#pragma preproc_asm@\#pragma preproc\_asm}
(+ | -) - switch the \_\_asm \_\_endasm block preprocessing on / off.
Default is on. Below is an example on how to use this pragma.
\end{itemize}
\begin{verse}
\texttt{\#pragma preproc\_asm -\index{#pragma preproc_asm@\#pragma preproc\_asm}}~\\
\texttt{/{*} this is a c code nop {*}/}~\\
\texttt{\#define NOP ;}~\\
\texttt{}~\\
\texttt{void foo (void)}~\\
\texttt{\{}~\\
\texttt{~~~...}~\\
\texttt{~~~while (-{}-i)}~\\
\texttt{~~~~~~NOP}~\\
\texttt{~~~...}~\\
\texttt{~~~\_\_asm}~\\
\texttt{~~~; this is an assembler nop instruction}~\\
\texttt{~~~; it is not preprocessed to ';' since the asm preprocessing
is disabled}~\\
\texttt{~~~NOP}~\\
\texttt{~~~\_\_endasm;}~\\
\texttt{~~~...}~\\
\texttt{\}}~\\

The pragma preproc\_asm should not be used to define multilines of
assembly code (even if it supports it), since this behavior is only
a side effect of sdcpp \_\_asm \_\_endasm implementation in combination
with pragma preproc\_asm and is not in conformance with the C standard.
This behavior might be changed in the future sdcpp versions. To define
multilines of assembly code you have to include each assembly line
into it's own \_\_asm \_\_endasm block. Below is an example for multiline
assembly defines.

\texttt{\#define Nop \_\_asm \textbackslash}~\\
\texttt{nop \textbackslash}~\\
\texttt{\_\_endasm}~\\
\texttt{}~\\
\texttt{\#define ThreeNops Nop; \textbackslash}~\\
\texttt{Nop; \textbackslash}~\\
\texttt{Nop}~\\
\texttt{}~\\
\texttt{void foo (void)}~\\
\texttt{\{}~\\
\texttt{~~~...}~\\
\texttt{~~~ThreeNops;}~\\
\texttt{~~~...}~\\
\texttt{\}}~\\
\end{verse}
\begin{itemize}
\item \textbf{sdcc\_hash}\index{#pragma sdcc_hash@\#pragma sdcc\_hash}
(+ | -) - \emph{Until SDCC 4.2.8:} Allow \textquotedbl naked\textquotedbl{}
hash in macro definition, for example:\\
\texttt{\#define DIR\_LO(x) \#(x \& 0xff)}\\
Default is off. Below is an example on how to use this pragma.
\end{itemize}
\begin{verse}
\texttt{\#pragma preproc\_asm +}~\\
\texttt{\#pragma sdcc\_hash +\index{#pragma sdcc_hash@\#pragma sdcc\_hash}}~\\
\texttt{}~\\
\texttt{\#define ROMCALL(x) \textbackslash}~\\
\texttt{~~~mov R6\_B3, \#(x \& 0xff) \textbackslash}~\\
\texttt{~~~mov R7\_B3, \#((x >\textcompwordmark > 8) \& 0xff)
\textbackslash}~\\
\texttt{~~~lcall \_\_romcall}~\\
\texttt{}~\\
\texttt{...}~\\
\texttt{\_\_asm}~\\
\texttt{ROMCALL(72)}~\\
\texttt{\_\_endasm;}~\\
\texttt{...}~\\
\end{verse}
Some of the pragmas are intended to be used to turn-on or off certain
optimizations which might cause the compiler to generate extra stack
and/or data space to store compiler generated temporary variables.
This usually happens in large functions. Pragma directives should
be used as shown in the following example, they are used to control
options and optimizations for a given function. 
\begin{verse}
\texttt{\#pragma save\index{#pragma save@\#pragma save} ~~~~~~~/{*}
save the current settings {*}/}~\\
\texttt{\#pragma nogcse\index{#pragma nogcse@\#pragma nogcse} ~~~~~/{*}
turnoff global subexpression elimination {*}/}~\\
\texttt{\#pragma noinduction\index{#pragma noinduction@\#pragma noinduction}
/{*} turn off induction optimizations {*}/}~\\
\texttt{int foo ()}~\\
\texttt{\{}~\\
\texttt{~ ~ ...}~\\
\texttt{~ ~ /{*} large code {*}/}~\\
\texttt{~ ~ ...}~\\
\texttt{\}}~\\
\texttt{\#pragma restore\index{#pragma restore@\#pragma restore}
/{*} turn the optimizations back on {*}/}
\end{verse}
The compiler will generate a warning message when extra space is allocated.
It is strongly recommended that the save and restore pragmas be used
when changing options for a function.

\section{Defines Created by the Compiler}

Besides defines from the C standards, the compiler creates the following
\#defines\index{#defines@\#defines}\index{Defines created by the compiler}:\\

\begin{tabular}{|>{\raggedright}p{3in}|>{\raggedright}p{3in}|}
\hline 
\textbf{\#define} & \textbf{Description}\tabularnewline
\hline 
\hline 
\_\_SDCC\index{SDCC!Defines!__SDCC (version macro)@\_\_SDCC (version macro)}\index{version macro} & Always defined. Version number string (e.g. SDCC\_3\_2\_0 for sdcc
3.2.0).\tabularnewline
\hline 
SDCC & OBSOLETE. WILL BE REMOVED IN THE FUTURE. CURRENTLY Only defined for
the mcs51 backend (and only if –std-cXX is not used). This macro has
been available since SDCC 2.5.6 and is the version number as an int
(ex. 256). PLEASE USE OTHER VERSION MACROS INSTEAD!\tabularnewline
\hline 
\_\_SDCC\_mcs51\index{SDCC!Defines!__SDCC_mcs51@\_\_SDCC\_mcs51}
or \_\_SDCC\_ds390\index{SDCC!Defines!__SDCC_ds390@\_\_SDCC\_ds390}
or \_\_SDCC\_z80\index{SDCC!Defines!__SDCC_z80@\_\_SDCC\_z80}, etc. & depending on the model used (e.g.: -mds390). Older versions used SDCC\_mcs51,
etc instead.\tabularnewline
\hline 
\_\_SDCC\_STACK\_AUTO\index{SDCC!Defines!SDCC_STACK_AUTO@SDCC\_STACK\_AUTO} & when \emph{-\/-stack-auto} option is used\tabularnewline
\hline 
\_\_SDCC\_MODEL\_SMALL\index{SDCC!Defines!SDCC_MODEL_SMALL@SDCC\_MODEL\_SMALL} & when \emph{-\/-model-small} is used\tabularnewline
\hline 
\_\_SDCC\_MODEL\_MEDIUM\index{SDCC!Defines!SDCC_MODEL_MEDIUM@SDCC\_MODEL\_MEDIUM} & when \emph{-\/-model-medium} is used\tabularnewline
\hline 
\_\_SDCC\_MODEL\_LARGE\index{SDCC!Defines!SDCC_MODEL_LARGE@SDCC\_MODEL\_LARGE} & when \emph{-\/-model-large} is used\tabularnewline
\hline 
\_\_SDCC\_MODEL\_HUGE\index{SDCC!Defines!SDCC_MODEL_LARGE@SDCC\_MODEL\_LARGE} & when \emph{-\/-model-huge} is used\tabularnewline
\hline 
\_\_SDCC\_USE\_XSTACK\index{SDCC!Defines!SDCC_USE_XSTACK@SDCC\_USE\_XSTACK} & when \emph{-\/-xstack} option is used\tabularnewline
\hline 
\_\_SDCC\_STACK\_TENBIT\index{SDCC!Defines!SDCC_STACK_TENBIT (ds390)@SDCC\_STACK\_TENBIT (ds390)} & when \emph{-mds390} is used\tabularnewline
\hline 
\_\_SDCC\_MODEL\_FLAT24\index{SDCC!Defines!SDCC_MODEL_FLAT24 (ds390)@SDCC\_MODEL\_FLAT24 (ds390)} & when \emph{-mds390} is used\tabularnewline
\hline 
\_\_SDCC\_VERSION\_MAJOR & Always defined. SDCC major version number. E.g. 3 for SDCC 3.5.0\tabularnewline
\hline 
\_\_SDCC\_VERSION\_MINOR & Always defined. SDCC minor version number. E.g. 5 for SDCC 3.5.0\tabularnewline
\hline 
\_\_SDCC\_VERSION\_PATCH & Always defined. SDCC patchlevel version number. E.g. 0 for SDCC 3.5.0\tabularnewline
\hline 
\_\_SDCC\_REVISION\index{SDCC!Defines!SDCC_REVISION (svn revision number)@SDCC\_REVISION (svn revision number)} & Always defined. SDCC svn revision number. Older versions of sdcc used
SDCC\_REVISION instead.\tabularnewline
\hline 
SDCC\_PARMS\_IN\_BANK1\index{SDCC!Defines!SDCC_PARMS_IN_BANK1@SDCC\_PARMS\_IN\_BANK1} & when \emph{-\/-parms-in-bank1} is used\tabularnewline
\hline 
\_\_SDCC\_ALL\_CALLEE\_SAVES\index{SDCC!Defines!SDCC_ALL_CALLEE_SAVES@SDCC\_ALL\_CALLEE\_SAVES} & when \emph{-\/-all-callee-saves} is used\tabularnewline
\hline 
\_\_SDCC\_FLOAT\_REENT\index{SDCC!Defines!SDCC_FLOAT_REENT@SDCC\_FLOAT\_REENT} & when \emph{-\/-float-reent} is used\tabularnewline
\hline 
\_\_SDCC\_INT\_LONG\_REENT\index{SDCC!Defines!SDCC_INT_LONG_REENT@SDCC\_INT\_LONG\_REENT} & when \emph{-\/-int-long-reent} is used\tabularnewline
\hline 
\_\_SDCC\_OPTIMIZE\_SPEED\index{SDCC!Defines!SDCC_OPTIMIZE_SPEED@SDCC\_OPTIMIZE\_SPEED} & when \emph{-\/-opt-code-speed} is used\tabularnewline
\hline 
\_\_SDCC\_OPTIMIZE\_SIZE\index{SDCC!Defines!SDCC_OPTIMIZE_SIZE@SDCC\_OPTIMIZE\_SIZE} & when \emph{-\/-opt-code-size} is used\tabularnewline
\hline 
\_\_SDCCCALL\index{SDCC!Defines!SDCCCALL} & Default ABI version for calling convention\tabularnewline
\hline 
\end{tabular}

\chapter{Notes on supported Processors}

\section{MCS51 variants\label{subsec:MCS51-variants}\index{MCS51 variants}}

MCS51 processors are available from many vendors and come in many
different flavours. While they might differ considerably in respect
to Special Function Registers the core MCS51 is usually not modified
or is kept compatible. 

\subsection{pdata access by SFR}

With the upcome of devices with internal xdata and flash memory devices
using port P2\index{P2 (mcs51 sfr)} as dedicated I/O port is becoming
more popular. Switching the high byte for \_\_pdata\index{__pdata (mcs51, ds390 named address space)@\_\_pdata (mcs51, ds390 named address space)}
access which was formerly done by port P2 is then achieved by a Special
Function Register\index{sfr}. In well-established MCS51 tradition
the address of this \emph{sfr} is where the chip designers decided
to put it. Needless to say that they didn't agree on a common name
either. So that the startup code can correctly initialize xdata variables,
you should define an sfr with the name \_XPAGE\texttt{\index{_XPAGE (mcs51)@\_XPAGE (mcs51)}}
at the appropriate location if the default, port P2, is not used for
this. Some examples are:
\begin{verse}
\texttt{\_\_sfr \_\_at (0x85) \_XPAGE; /{*} Ramtron VRS51 family a.k.a. MPAGE
{*}/}

\texttt{\_\_sfr \_\_at (0x92) \_XPAGE; /{*} Cypress EZ-USB family,
Texas Instruments (Chipcon) a.k.a. MPAGE {*}/}

\texttt{\_\_sfr \_\_at (0x91) \_XPAGE; /{*} Infineon (Siemens) C500
family a.k.a. XPAGE {*}/}

\texttt{\_\_sfr \_\_at (0xaf) \_XPAGE; /{*} some Silicon Labs (Cygnal)
chips a.k.a. EMI0CN {*}/}

\texttt{\_\_sfr \_\_at (0xaa) \_XPAGE; /{*} some Silicon Labs (Cygnal)
chips a.k.a. EMI0CN {*}/}
\end{verse}
There are also devices without anything resembling \_XPAGE, but luckily
they usually have dual data-pointers. For these devices a different
method can be used to correctly initialize xdata variables. A default
implementation is already in crtxinit.asm but it needs to be assembled
manually with DUAL\_DPTR set to 1.

For more exotic implementations further customizations may be needed.
See section \ref{subsec:MCS51-Startup-Code} for other possibilities.

\subsection{Other Features available by SFR}

Some MCS51 variants offer features like Dual DPTR\index{DPTR}, multiple
DPTR, decrementing DPTR, 16x16 Multiply. These are currently not used
for the MCS51 port. If you absolutely need them you can fall back
to inline assembly or submit a patch to SDCC.

\subsection{Bankswitching\label{subsec:Bankswitching}}

Bankswitching\index{Bankswitching} (a.k.a. code banking\index{code banking})
is a technique to increase the code space above the 64k limit of the
8051.

\subsubsection{Hardware}

\begin{tabular}{c|c|c|c}
\cline{2-4}
\multicolumn{1}{c|}{8000-FFFF} & bank1 & bank2 & \multicolumn{1}{c|}{bank3}\tabularnewline
\cline{2-4}
\multicolumn{1}{c|}{0000-7FFF} & common & \multicolumn{2}{c}{}\tabularnewline
\cline{2-2}
\multicolumn{4}{c}{SiLabs C8051F120 example}\tabularnewline
\end{tabular}\\
\\
Usually the hardware uses some sfr (an output port or an internal
sfr) to select a bank and put it in the banked area of the memory
map. The selected bank usually becomes active immediately upon assignment
to this sfr and when running inside a bank it will switch out this
code it is currently running. Therefor you cannot jump or call directly
from one bank to another and need to use a so-called trampoline in
the common area. For SDCC an example trampoline is in crtbank.asm
and you may need to change it to your 8051 derivative or schematic.
The presented code is written for the C8051F120.\\
\\
When calling a banked function SDCC will put the LSB of the functions
address in register R0, the MSB in R1 and the bank in R2 and then
call this trampoline \emph{\_\_sdcc\_banked\_call}. The current selected
bank is saved on the stack, the new bank is selected and an indirect
jump is made. When the banked function returns it jumps to \emph{\_\_sdcc\_banked\_ret}
which restores the previous bank and returns to the caller.

\subsubsection{Software}

When writing banked software using SDCC you need to use some special
keywords and options. You also need to take over a bit of work from
the linker.\\
\\
To create a function that can be called from another bank it requires
the keyword \emph{\_\_banked}\index{banked}. The caller must see
this in the prototype of the callee and the callee needs it for a
proper return. Called functions within the same bank as the caller
do not need the \emph{\_\_banked} keyword nor do functions in the
common area. Beware: SDCC does not know or check if functions are
in the same bank. This is your responsibility!\\
\\
Normally all functions you write end up in the segment CSEG. If you
want a function explicitly to reside in the common area put it in
segment HOME. This applies for instance to interrupt service routines
as they should not be banked.

Functions that need to be in a switched bank must be put in a named
segment. The name can be mostly anything up to eight characters (e.g.
BANK1). To do this you either use -\/-codeseg BANK1 (See \ref{lyx:-codeseg})
on the command line when compiling or \#pragma codeseg BANK1 (See
\ref{sec:Pragmas}) at the top of the C source file. The segment name
always applies to the whole source file and generated object so functions
for different banks need to be defined in different source files.\\
\\
When linking your objects you need to tell the linker where to put
your segments. To do this you use the following command line option
to SDCC: -Wl-b BANK1=0x18000 (See \ref{lyx:-Wl option}). This sets
the virtual start address of this segment. It sets the banknumber
to 0x01 and maps the bank to 0x8000 and up. The linker will not check
for overflows, again this is your responsibility.

\subsection{MCS51/DS390 Startup Code\label{subsec:MCS51-Startup-Code}}

The compiler triggers the linker to link certain initialization modules
from the runtime library\index{Runtime library} called crt<something>.
Only the necessary ones are linked, for instance crtxstack.asm (GSINIT1,
GSINIT5) is not linked unless the -\textbf{\/}-xstack option is used.
These modules are highly entangled by the use of special segments/areas,
but a common layout is shown below:
\begin{verse}
{\footnotesize\texttt{\textbf{(main.asm)}}}{\footnotesize\par}

{\footnotesize\texttt{~~~~~~~~.area HOME (CODE)}}~\\
{\footnotesize\texttt{\_\_interrupt\_vect:}}~\\
{\footnotesize\texttt{~~~~~~~~ljmp \_\_sdcc\_gsinit\_startup}}{\footnotesize\par}

{\footnotesize\texttt{\textbf{(crtstart.asm)}}}{\footnotesize\par}

{\footnotesize\texttt{~~~~~~~~.area GSINIT0 (CODE)}}~\\
{\footnotesize\texttt{\_\_sdcc\_gsinit\_startup::}}~\\
{\footnotesize\texttt{~~~~~~~~mov sp,\#\_\_start\_\_stack
- 1}}{\footnotesize\par}

{\footnotesize\texttt{\textbf{(crtxstack.asm)}}}{\footnotesize\par}

{\footnotesize\texttt{~~~~~~~~.area GSINIT1 (CODE)}}~\\
{\footnotesize\texttt{\_\_sdcc\_init\_xstack::}}~\\
{\footnotesize\texttt{; Need to initialize in GSINIT1 in case the
user's \_\_sdcc\_external\_startup uses the xstack.}}~\\
{\footnotesize\texttt{~~~~~~~~mov \_\_XPAGE,\#(\_\_start\_\_xstack
>\textcompwordmark > 8)}}~\\
{\footnotesize\texttt{~~~~~~~~mov \_spx,\#\_\_start\_\_xstack}}{\footnotesize\par}

{\footnotesize\texttt{\textbf{(crtstart.asm)}}}{\footnotesize\par}

{\footnotesize\texttt{~~~~~~~~.area GSINIT2 (CODE)}}~\\
{\footnotesize\texttt{~~~~~~~~lcall \_\_\_sdcc\_external\_startup}}~\\
{\footnotesize\texttt{~~~~~~~~mov a,dpl}}~\\
{\footnotesize\texttt{~~~~~~~~jz \_\_sdcc\_init\_data}}~\\
{\footnotesize\texttt{~~~~~~~~ljmp \_\_sdcc\_program\_startup}}~\\
{\footnotesize\texttt{\_\_sdcc\_init\_data:}}{\footnotesize\par}

{\footnotesize\texttt{\textbf{(crtxinit.asm)}}}{\footnotesize\par}

{\footnotesize\texttt{~~~~~~~~.area GSINIT3 (CODE)}}~\\
{\footnotesize\texttt{\_\_mcs51\_genXINIT::}}~\\
{\footnotesize\texttt{~~~~~~~~mov r1,\#l\_XINIT}}~\\
{\footnotesize\texttt{~~~~~~~~mov a,r1}}~\\
{\footnotesize\texttt{~~~~~~~~orl a,\#(l\_XINIT >\textcompwordmark >
8)}}~\\
{\footnotesize\texttt{~~~~~~~~jz 00003\$}}~\\
{\footnotesize\texttt{~~~~~~~~mov r2,\#((l\_XINIT+255) >\textcompwordmark >
8)}}~\\
{\footnotesize\texttt{~~~~~~~~mov dptr,\#s\_XINIT}}~\\
{\footnotesize\texttt{~~~~~~~~mov r0,\#s\_XISEG}}~\\
{\footnotesize\texttt{~~~~~~~~mov \_\_XPAGE,\#(s\_XISEG >\textcompwordmark >
8)}}~\\
{\footnotesize\texttt{00001\$:~clr a}}~\\
{\footnotesize\texttt{~~~~~~~~movc a,@a+dptr}}~\\
{\footnotesize\texttt{~~~~~~~~movx @r0,a}}~\\
{\footnotesize\texttt{~~~~~~~~inc dptr}}~\\
{\footnotesize\texttt{~~~~~~~~inc r0}}~\\
{\footnotesize\texttt{~~~~~~~~cjne r0,\#0,00002\$}}~\\
{\footnotesize\texttt{~~~~~~~~inc \_\_XPAGE}}~\\
{\footnotesize\texttt{00002\$:~djnz r1,00001\$}}~\\
{\footnotesize\texttt{~~~~~~~~djnz r2,00001\$}}~\\
{\footnotesize\texttt{~~~~~~~~mov \_\_XPAGE,\#0xFF}}~\\
{\footnotesize\texttt{00003\$:}}{\footnotesize\par}

{\footnotesize\texttt{\textbf{(crtclear.asm)}}}{\footnotesize\par}

{\footnotesize\texttt{~~~~~~~~.area GSINIT4 (CODE)}}~\\
{\footnotesize\texttt{\_\_mcs51\_genRAMCLEAR::}}~\\
{\footnotesize\texttt{~~~~~~~~clr a}}~\\
{\footnotesize\texttt{~~~~~~~~mov r0,\#(l\_IRAM-1)}}~\\
{\footnotesize\texttt{00004\$:~mov @r0,a}}~\\
{\footnotesize\texttt{~~~~~~~~djnz r0,00004\$}}~\\
{\footnotesize\texttt{; \_mcs51\_genRAMCLEAR() end}}{\footnotesize\par}

{\footnotesize\texttt{\textbf{(crtxclear.asm)}}}{\footnotesize\par}

{\footnotesize\texttt{~~~~~~~~.area GSINIT4 (CODE)}}~\\
{\footnotesize\texttt{\_\_mcs51\_genXRAMCLEAR::}}~\\
{\footnotesize\texttt{~~~~~~~~mov r0,\#l\_PSEG}}~\\
{\footnotesize\texttt{~~~~~~~~mov a,r0}}~\\
{\footnotesize\texttt{~~~~~~~~orl a,\#(l\_PSEG >\textcompwordmark >
8)}}~\\
{\footnotesize\texttt{~~~~~~~~jz 00006\$}}~\\
{\footnotesize\texttt{~~~~~~~~mov r1,\#s\_PSEG}}~\\
{\footnotesize\texttt{~~~~~~~~mov \_\_XPAGE,\#(s\_PSEG >\textcompwordmark >
8)}}~\\
{\footnotesize\texttt{~~~~~~~~clr a}}~\\
{\footnotesize\texttt{00005\$:~movx @r1,a}}~\\
{\footnotesize\texttt{~~~~~~~~inc r1}}~\\
{\footnotesize\texttt{~~~~~~~~djnz r0,00005\$}}~\\
{\footnotesize\texttt{00006\$:}}~\\
{\footnotesize\texttt{~~~~~~~~mov r0,\#l\_XSEG}}~\\
{\footnotesize\texttt{~~~~~~~~mov a,r0}}~\\
{\footnotesize\texttt{~~~~~~~~orl a,\#(l\_XSEG >\textcompwordmark >
8)}}~\\
{\footnotesize\texttt{~~~~~~~~jz 00008\$}}~\\
{\footnotesize\texttt{~~~~~~~~mov r1,\#((l\_XSEG + 255) >\textcompwordmark >
8)}}~\\
{\footnotesize\texttt{~~~~~~~~mov dptr,\#s\_XSEG}}~\\
{\footnotesize\texttt{~~~~~~~~clr a}}~\\
{\footnotesize\texttt{00007\$:~movx @dptr,a}}~\\
{\footnotesize\texttt{~~~~~~~~inc dptr}}~\\
{\footnotesize\texttt{~~~~~~~~djnz r0,00007\$}}~\\
{\footnotesize\texttt{~~~~~~~~djnz r1,00007\$}}~\\
{\footnotesize\texttt{00008\$:}}{\footnotesize\par}

{\footnotesize\texttt{\textbf{(crtxstack.asm)}}}{\footnotesize\par}

{\footnotesize\texttt{~~~~~~~~.area GSINIT5 (CODE)}}~\\
{\footnotesize\texttt{; Need to initialize in GSINIT5 because \_\_mcs51\_genXINIT
modifies \_\_XPAGE}}~\\
{\footnotesize\texttt{; and \_\_mcs51\_genRAMCLEAR modifies \_spx.}}~\\
{\footnotesize\texttt{~~~~~~~~mov \_\_XPAGE,\#(\_\_start\_\_xstack
>\textcompwordmark > 8)}}~\\
{\footnotesize\texttt{~~~~~~~~mov \_spx,\#\_\_start\_\_xstack}}{\footnotesize\par}

{\footnotesize\texttt{\textbf{(application modules)}}}{\footnotesize\par}

{\footnotesize\texttt{~~~~~~~~.area GSINIT (CODE)}}{\footnotesize\par}

{\footnotesize\texttt{\textbf{(main.asm)}}}{\footnotesize\par}

{\footnotesize\texttt{~~~~~~~~.area GSFINAL (CODE)}}~\\
{\footnotesize\texttt{~~~~~~~~ljmp \_\_sdcc\_program\_startup}}~\\
{\footnotesize\texttt{;-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-}}~\\
{\footnotesize\texttt{; Home}}~\\
{\footnotesize\texttt{;-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-{}-}}~\\
{\footnotesize\texttt{~~~~~~~~.area HOME (CODE)}}~\\
{\footnotesize\texttt{~~~~~~~~.area CSEG (CODE)}}~\\
{\footnotesize\texttt{\_\_sdcc\_program\_startup:}}~\\
{\footnotesize\texttt{~~~~~~~~lcall \_main}}~\\
{\footnotesize\texttt{; return from main will lock up}}~\\
{\footnotesize\texttt{~~~~~~~~sjmp .}}{\footnotesize\par}
\end{verse}
On some mcs51 variants \_\_xdata\index{__xdata (mcs51, ds390 named address space@\_\_xdata (mcs51, ds390 named address space}
memory has to be explicitly enabled before it can be accessed or if
the watchdog\index{watchdog} needs to be disabled, this is the place
to do it. The startup code clears all internal data memory, 256 bytes
by default, but from 0 to n-1 if \emph{-\/-iram-size\index{-/-iram-size <Value>@-\/-iram-size <Value>}
<n>} is used. (recommended for Chipcon CC1010).

See also the compiler option \emph{-\/-no-xinit}-\emph{opt}\index{-/-no-xinit-opt@-\/-no-xinit-opt}
and section \ref{subsec:MCS51-variants} about MCS51-variants.\\

While these initialization modules are meant as generic startup code
there might be the need for customization. Let's assume the return
value of \emph{\_\_sdcc\_external\_startup()} in \emph{crtstart.asm}
should not be checked (or \emph{\_\_sdcc\_external\_startup()} should
not be called at all). The recommended way would be to copy \emph{crtstart.asm}
(f.e. from \url{http://svn.code.sf.net/p/sdcc/code/trunk/sdcc/device/lib/mcs51/crtstart.asm})
into the source directory, adapt it there, then assemble it with \emph{sdas8051
-plosgff}\footnote{''-plosgff'' are the assembler options used in \url{http://sdcc.svn.sourceforge.net/viewvc/sdcc/trunk/sdcc/device/lib/mcs51/Makefile.in?view=markup }}\emph{
crtstart.asm} and when linking your project explicitly specify \emph{crtstart.rel}.
As a bonus a listing of the relocated object file \emph{crtstart.rst}
is generated.

\subsection{Interfacing with Assembler Code\index{Assembler routines}}

\subsubsection{Global Registers used for Parameter Passing\index{Parameter passing}}

The compiler always uses the global registers \emph{DPL, DPH\index{DPTR, DPH, DPL}\index{DPTR},
B\index{B (mcs51, ds390 register)}} and \emph{ACC\index{ACC (mcs51, ds390 register)}}
to pass the first (non-bit, non-struct) parameter to a function, and
also to pass the return value \index{return value}of function; according
to the following scheme: one byte return value in \emph{DPL}, two
byte value in \emph{DPL} (LSB) and \emph{DPH} (MSB). three byte values
(generic pointers) in \emph{DPH}, \emph{DPL} and \emph{B}, and four
byte values in \emph{DPH}, \emph{DPL}, \emph{B} and \emph{ACC}. Generic
pointers\index{generic pointer} contain type of accessed memory in
\emph{B}: \textbf{0x00} – xdata/far, \textbf{0x40} – idata/near –
, \textbf{0x60} – pdata, \textbf{0x80} – code.

Further such parameters (and all struct parameters, as well as the
bit parameters from the 9th onwards) are either allocated on the stack
(for reentrant routines or if -\/-stack-auto is used) or in data/xdata
memory (depending on the memory model).

The first 8 bit parameters are passed in a virtual register called
'bits' in bit-addressable space for reentrant functions or allocated
directly in bit memory otherwise.

Functions (with two or more parameters or bit parameters) that are
called through function pointers\index{function pointers} must therefor
be reentrant so the compiler knows how to pass the parameters.

\subsubsection{Register usage}

Unless the called function is declared as \texttt{\_naked}\index{naked},
or the -\/-callee-saves\index{-/-callee-saves@-\/-callee-saves}/-\/-all-callee-saves
command line option or the corresponding callee\_saves pragma are
used, the caller will save the registers (\emph{R0-R7}) around the
call, so the called function can destroy they content freely.

If the called function is not declared as \texttt{\_naked}, the caller
will swap register banks around the call, if caller and callee use
different register banks (having them defined by the \texttt{\_\_using}
modifier). 

The called function can also use \emph{DPL}, \emph{DPH}, \emph{B}
and \emph{ACC} observing that they are used for parameter/return value
passing.

\subsubsection{Assembler Routine (non-reentrant)}

In the following example\index{reentrant}\index{Assembler routines (non-reentrant)}
the function c\_func calls an assembler routine asm\_func, which takes
two parameters\index{function parameter}.
\begin{verse}
\texttt{extern int asm\_func(unsigned char, unsigned char);}~\\
\texttt{}~\\
\texttt{int c\_func (unsigned char i, unsigned char j)}~\\
\texttt{\{}~\\
\texttt{~~~~return asm\_func(i,j);}~\\
\texttt{\}}~\\
\texttt{}~\\
\texttt{int main()}~\\
\texttt{\{}~\\
\texttt{~~~~return c\_func(10,9);}~\\
\texttt{\}}
\end{verse}
The corresponding assembler function is:
\begin{verse}
\texttt{~~~~~~~~.globl \_asm\_func\_PARM\_2}~\\
\texttt{~~~~~~~~.globl \_asm\_func}~\\
\texttt{~~~~~~~~.area OSEG}~\\
\texttt{\_asm\_func\_PARM\_2:}~\\
\texttt{~~~~~~~~.ds    1}~\\
\texttt{~~~~~~~~.area CSEG}~\\
\texttt{\_asm\_func:}~\\
\texttt{~~~~~~~~mov~~~~a,dpl}~\\
\texttt{~~~~~~~~add~~~~a,\_asm\_func\_PARM\_2}~\\
\texttt{~~~~~~~~mov~~~~dpl,a}~\\
\texttt{~~~~~~~~mov~~~~dph\index{DPTR, DPH, DPL},\#0x00}~\\
\texttt{~~~~~~~~ret}
\end{verse}
The parameter naming convention is \_<function\_name>\_PARM\_<n>,
where n is the parameter number starting from 1, and counting from
the left. The first parameter is passed in \emph{DPH}, \emph{DPL},
\emph{B} and \emph{ACC} according to the description above. The variable
name for the second parameter will be \_<function\_name>\_PARM\_2.\\
\\
Assemble the assembler routine with the following command:\\
\\
\textsf{\textbf{sdas8051 -losg asmfunc.asm}}\\
\textsf{\textbf{}}\\
Then compile and link the assembler routine to the C source file with
the following command:\\
\\
\textsf{\textbf{sdcc cfunc.c asmfunc.rel}}

\subsubsection{Assembler Routine (reentrant)}

In this case\index{reentrant}\index{Assembler routines (reentrant)}
the second parameter\index{function parameter} onwards will be passed
on the stack, the parameters are pushed from right to left i.e. before
the call the second leftmost parameter will be on the top of the stack
(the leftmost parameter is passed in registers). Here is an example:
\begin{verse}
\texttt{extern int asm\_func(unsigned char, unsigned char, unsigned
char) reentrant;}~\\
\texttt{}~\\
\texttt{int c\_func (unsigned char i, unsigned char j, unsigned char
k) reentrant }~\\
\texttt{\{}~\\
\texttt{~~~~return asm\_func(i,j,k);}~\\
\texttt{\}}~\\
\texttt{}~\\
\texttt{int main()}~\\
\texttt{\{}~\\
\texttt{~~~~return c\_func(10,9,8);}~\\
\texttt{\}}
\end{verse}
The corresponding (unoptimized) assembler routine is:
\begin{verse}
\texttt{.globl \_asm\_func}~\\
\texttt{\_asm\_func:}~\\
\texttt{~~~~push~\_bp}~\\
\texttt{~~~~mov~~\_bp,sp~~~~~~;stack contains: \_bp, return
address, second parameter, third parameter}~\\
\texttt{~~~~mov~~r2,dpl}~\\
\texttt{~~~~mov~~a,\_bp}~\\
\texttt{~~~~add~~a,\#0xfd~~~~~;calculate pointer to the
second parameter}~\\
\texttt{~~~~mov~~r0,a}~\\
\texttt{~~~~mov~~a,\_bp}~\\
\texttt{~~~~add~~a,\#0xfc~~~~~;calculate pointer to the
rightmost parameter}~\\
\texttt{~~~~mov~~r1,a}~\\
\texttt{~~~~mov~~a,@r0}~\\
\texttt{~~~~add~~a,@r1}~\\
\texttt{~~~~add~~a,r2~~~~~~~~;calculate the result (=
sum of all three parameters)}~\\
\texttt{~~~~mov~~dpl,a~~~~~~~;return value goes into
dptr (cast into int)}~\\
\texttt{~~~~mov~~dph,\#0x00}~\\
\texttt{~~~~mov~~sp,\_bp}~\\
\texttt{~~~~pop~~\_bp}~\\
\texttt{~~~~ret}
\end{verse}
The compiling and linking procedure remains the same, however note
the extra entry \& exit linkage required for the assembler code, \_bp
is the stack frame pointer and is used to compute the offset into
the stack for parameters and local variables.

\section{DS400 port}

The DS80C400\index{DS80C400}\index{DS400} microcontroller has a
rich set of peripherals. In its built-in ROM library it includes functions
to access some of the features, among them is a TCP stack with IP4
and IP6 support. Library headers (currently in beta status) and other
files are provided at {\footnotesize\url{ftp://ftp.dalsemi.com/pub/tini/ds80c400/c_libraries/sdcc/index.html}. }{\footnotesize\par}

\section{The Z80, Z180, Rabbit 2000, Rabbit 2000A, Rabbit 3000A, SM83 (GameBoy),
eZ80, TLCS-90 and R800 ports}

SDCC can target the Z80\index{Z80}, Z180, eZ80 in Z80 mode, Rabbit
2000, Rabbit 2000A, Rabbit 3000A and LR35902, the Sharp SM83 (used
.e.g in the Nintendo GameBoy) sm83\index{sm83 (GameBoy Z80)}.

When a frame pointer is used, it resides in IX. Register A, B, C,
D, E, H, L and IY are used as a temporary registers for holding variables.

When enabling optimizations using \code{-{}-opt-code} size and a
sufficiently high value for \code{-{}-max-allocs-per-node} SDCC typically
generates much better code for these architectures than many other
compilers. A comparison of compilers for these architecture can be
found at \url{http://sdcc.sourceforge.net/wiki/index.php/Z80_code_size}.

\subsection{Startup Code}

On the Z80\index{Z80} the startup code is inserted by linking with
crt0.rel which is generated from sdcc/device/lib/z80/crt0.s. If you
need a different startup code you can use the compiler option \emph{-}\textbf{\/}\emph{-no-std-crt0}\index{-/-no-std-crt0@-\/-no-std-crt0}
and provide your own crt0.rel. When using a custom crt0.rel it needs
to be listed first when linking.

\subsection{Rabbit ports}

SDCC has three Rabbit-supporting ports: r2k for the Rabbit 2000, r2ka
for the Rabbit 2000A, 2000B, 2000C and 3000, r3ka for the Rabbit 3000A,
4000 and 6000. Some Rabbits support different memory types (Rabbit
4000 and later), different memory access modes (Rabbit 5000 and later),
different instruction modes (Rabbit 4000 and later). All SDCC ports
assume 8-bit memories, 8-bit memory access mode, 00/default instruction
set mode (the code generated is also compatible with 10 and 01 instruction
set mode, but not 11/enhanced instruction set mode).

\subsubsection{Port choice}

\begin{tabular}{|c|c|c|c|c|c|c|c|c|c|}
\hline 
Ports vs. Device & R2K & R2kK & R2KB & R2KC & R3K & R3KA & R4K & R5K & R6K\tabularnewline
\hline 
\hline 
r2k & Y & y & y & y & y & y & y & N & y\tabularnewline
\hline 
r2ka & n & Y & Y & Y & y & y & y & N & y\tabularnewline
\hline 
r3ka & N & N & N & N & N & Y & Y & N & Y\tabularnewline
\hline 
\end{tabular}

Legend:

Y - The code this port generates is the best for this CPU.

y - The code this port generates will work on this CPU.

N - The code this port generates will not work on this CPU.

n - The code this port generates will typically not work on this CPU.

There are multiple wait state bugs present in some of the the Rabbits.
The difference between the r2k and r2ka port is additional wait state
bug workarounds. If all memory used has zero wait states, code from
the r2ka backend can be safely run on the original Rabbit 2000.

The r2k and r2ka port assume that the whole stack has the same number
of wait states (code from the r2k and r2ka ports can fail is the stack
spans memories with a different amount of wait states).

The Rabbit 2000 has some wait state bugs that SDCC does not work around.
These bugs result in the number of wait states used being one less
than configured for some instructions. The workaround has to be supplied
by the user, by configuring all memories that do use wait states to
use on additional wait state.

For all Rabbit ports, SDCC assumes that all data memory is at least
as fast (i.e. does not need more wait states) as all code memory.
Code where this is not the case (e.g. code in fast Flash writing into
slow battery-backed SRAM) will have to be written in assembler by
hand.

\subsubsection{Rabbit hardware bugs}

\begin{tabular}{|l|c|c|c|c|c|c|c|c|c|}
\hline 
Bug & R2K & R2KA & R2KB & R2KC & R3K & R3KA & R4K & R5K & R6K\tabularnewline
\hline 
\hline 
ioi / ioe prefix bug & x &  &  &  &  &  &  &  & \tabularnewline
\hline 
ddcb / fdcb wait state bug & U &  &  &  &  &  &  &  & \tabularnewline
\hline 
conditional jump wait state bug & U &  &  &  &  &  &  &  & \tabularnewline
\hline 
ldir / lddr wait state bug & U &  &  &  &  &  &  &  & \tabularnewline
\hline 
mul wait state bug & w &  &  &  &  &  &  &  & \tabularnewline
\hline 
ldir / lddr split bug &  & S &  &  &  &  &  &  & \tabularnewline
\hline 
new ldir / lddr wait state bug & w & w & w & w & w &  &  &  & \tabularnewline
\hline 
16-bit mode alignment bug &  &  &  &  &  &  &  & X & \tabularnewline
\hline 
ioi / ioe bit bug &  &  &  &  &  &  &  & x & \tabularnewline
\hline 
ret cc bug &  &  &  &  &  &  &  & X & \tabularnewline
\hline 
rmw wait state bug & W & W & W & W & W & W & W & W & \tabularnewline
\hline 
16-bit vs. 8-bit wait state bug &  &  &  &  &  &  & W &  & \tabularnewline
\hline 
dma vs stack prot. bug &  &  &  &  &  &  & X &  & \tabularnewline
\hline 
16-bit dma vs. ldir / lddr / etc. bug &  &  &  &  &  &  & X &  & \tabularnewline
\hline 
\end{tabular}

Legend:

x s w u - bug present, worked around by SDCC.

X S W U - bug present, not worked around by SDCC.

w W u U - wait state bug, only relevant when the Rabbit is configured
to have wait states for some memory.

s S - instruction / data split bug, only relevant when instruction
/ data split is enabled, which is currently not supported by SDCC.

u U - bug can be worked around by the user by configuring memory that
needs wait states to use one additional wait state.

The 16-bit mode alignment bug only affects 16-bit mode, which is not
currently supported by SDCC.

The rmw wait state bug is only relevant when executing fast code writing
to slow memory, such as code in fast RAM writing to slow battery-backed
SRAM.

The 16-bit vs. 8-bit wait state bug is only relevant when the target
system uses both 16-bit and 8-bit memories for code, and the 8-bit
memory requires wait states.

The 16-bit dma vs. ldir / lddr / etc. bug is only relevant when using
DMA and the target system uses 16-bit memory for code. Since SDCC
uses the block move instructions like ldir, lddr, etc. without applying
a workaround, this means that code execution and DMA may then not
happen at the same time. A possible user workaround is to not use
DMA when using 16-bit memory for code. Among all Rabbit 4000-based
RCM and BL modules, only the RCM4000 and the RCM4010 use 16-bit memories.

There are no documented Rabbit 6000 bugs, but Rabbit 6000 documentation
in general is lacking compared to the other Rabbits.

\subsection{Z80, Z180, Z80N and R800 calling conventions}

The current default is the SDCC calling convention, version 1. Using
the command-line option –sdcccall 0, the default can be changed to
version 0. There are three other calling conventions supported, which
can be specified using the keywords \_\_smallc, \_\_z88dk\_fastcall
and \_\_z88dk\_callee. They are primarily intended for compatibility
with libraries written for other compilers. For \_\_z88dk\_fastcall,
there may be only one parameter of at most 32 bits, which is passed
the same way as the return value of \_\_sdcccall(0). For \_\_z88dk\_callee,
the stack is not adjusted for stack parameters the parameters after
the call (thus the callee has to do this instead). \_\_z88dk\_callee
can be combined with \_\_smallc, \_\_sdcccall(0) or \_\_sdcccall(1).

\subsubsection{Z80 SDCC calling convention, version 1}

This calling convention can be chosen per function via \_\_sdcccall(1).
8-bit return values are passed in a, 16-bit values in de, 24-bit values
in lde, 32-bit values in hlde. Larger return values (as well as struct
and union independent of their size) are passed in memory in a location
specified by the caller through a hidden pointer argument.

For functions that have variable arguments: All parameters are passed
on the stack. The stack is not adjusted for the parameters by the
callee (thus the caller has to do this instead).

\includegraphics{z80-arguments}

For Functions that do not have variable arguments: the first parameter
is passed in a if it has 8 bits. If it has 16 bits it is passed in
hl. If it has 32 bits, it is passed in hlde. If the first parameter
is in a, and the second has 8 bits, it is passed in l; if the first
is passed in a or hl, and the second has 16 bits, it is passed in
de; all other parameters are passed on the stack, right-to-left. Independent
of their size, struct / union parameters and all following parameters
are always passed on the stack.

\includegraphics{z80-stack-cleanup}

If \_\_z88dk\_callee is not used, after the call, the stack parameters
are cleaned up by the caller, with the following exceptions: functions
that do not have variable arguments and return void or a type of at
most 16 bits, or have both a first parameter of type float and a return
value of type float.

\subsubsection{Z80 SDCC calling convention, version 0}

This calling convention can be chosen per function via \_\_sdcccall(0).
All parameters are passed on the stack, right-to-left. 8-bit return
values are passed in l, 16-bit values in hl, 24-bit values in ehl,
32-bit values in dehl. Except for the SM83, where 8-bit values are
passed in e, 16-bit values in de, 32-bit values in hlde. Larger return
values (as well as struct and union independent of their size) are
passed in a memory in a location specified by the caller through a
hidden pointer argument. Unless \_\_z88dk\_callee is used, all stack
parameters are cleaned up by the caller.

\subsection{Rabbit 2000, Rabbit 2000A, Rabbit 3000A, eZ80 and TLCS-90 calling
conventions}

The current default is the Rabbit calling convetion desribed here,
version 1. Using the command-line option –sdcccall 8, the default
can be changed to version 0 of the Z80 calling convention, described
above. There are four other calling conventions supported, which can
be specified using the keywords \_\_smallc, \_\_z88dk\_fastcall and
\_\_z88dk\_callee. They are primarily intended for compatibility with
libraries written for other compilers. For \_\_z88dk\_fastcall, there
may be only one parameter of at most 32 bits, which is passed the
same way as the return value. For \_\_z88dk\_callee, the stack is
not adjusted for stack parameters the parameters after the call (thus
the callee has to do this instead). \_\_z88dk\_callee can be combined
with \_\_smallc, \_\_sdcccall(0) or \_\_sdcccall(1).

\subsubsection{Rabbit SDCC calling convention, version 1}

This calling convention can be chosen per function via \_\_sdcccall(1).
8-bit return values are passed in a, 16-bit values in hl, 24-bit values
in lde, 32-bit values in hlde. Larger return values (as well as struct
and union independent of their size) are passed in memory in a location
specified by the caller through a hidden pointer argument.

For functions that have variable arguments: All parameters are passed
on the stack. The stack is not adjusted for the parameters by the
callee (thus the caller has to do this instead).

\includegraphics{r3ka-arguments}

For Functions that do not have variable arguments: the first parameter
is passed in a if it has 8 bits. If it has 16 bits it is passed in
hl. If it has 32 bits, it is passed in hlde. If the first parameter
is in a, and the second has 8 bits, it is passed in l; if the first
is in hl or hlde, and the second has 8 bits, it is passed in a; if
the first is in a, and the second has 16 bits, it is passed in hl;
all other parameters are passed on the stack, right-to-left. Independent
of their size, struct / union parameters and all following parameters
are always passed on the stack.

\includegraphics{z80-stack-cleanup}

If \_\_z88dk\_callee is not used, after the call, the stack parameters
are cleaned up by the caller, with the following exceptions: functions
that do not have variable arguments and return void or a type of at
most 16 bits, or have both a first parameter of type float and a return
value of type float.

\subsection{SM83 calling conventions}

The current default is the SDCC calling convention, version 1. Using
the command-line option –sdcccall 0, the default can be changed to
version 0.

\subsubsection{SM83 SDCC calling convention, version 1}

This calling convention can be chosen per function via \_\_sdcccall(1).

8-bit return values are passed in a, 16-bit values in bc, 32-bit values
in debc. Larger return values (as well as struct and union independent
of their size) are passed in memory in a location specified by the
caller through a hidden pointer argument.

For functions that have variable arguments: All parameters are passed
on the stack. The stack is not adjusted for the parameters by the
callee (thus the caller has to do this instead).

\includegraphics{sm83-arguments}

For Functions that do not have variable arguments: the first parameter
is passed in a if it has 8 bits. If it has 16 bits it is passed in
de. If it has 32 bits, it is passed in debc. If the first parameter
is in a, and the second has 8 bits, it is passed in e; if the first
is in bc or debc, and the second has 8 bits, it is passed in a; if
the first is passed in a, and the second has 16 bits, it is passed
in bc; if the first is passed in de, and the second has 16 bits, it
is passed in bc; all other parameters are passed on the stack, right-to-left.
Independent of their size, struct / union parameters and all following
parameters are always passed on the stack. The stack is adjusted by
the callee (thus explicitly specifying \_\_z88dk\_callee does not
make a difference), unless the functionhas variable arguments.

\subsubsection{SM83 SDCC calling convention, version 0}

This calling convention can be chosen per function via \_\_sdcccall(0).
8-bit return values are passed in e, 16-bit values in de, 32-bit values
in hlde. Larger return values (as well as struct and union independent
of their size) are passed in memory in a location specified by the
caller through a hidden pointer argument. All parameters are passed
on the stack. The stack is not adjusted for the parameters by the
callee (thus the caller has to do this instead), unless \_\_z88dk\_callee
is specified. \_\_sdcccall(0) can be combined with \_\_z88dk\_callee.

\subsection{Small-C calling convention}

Functions declared as \_\_smallc are called using the Small-C calling
convention (passing arguments on-stack left-to-right, 1 byte arguments
are passed as 2 bytes, with the value in the lower byte). 8-bit return
values are passed in a, 16-bit values in de, 32-bit values in hlde.
Larger return values (as well as struct and union independent of their
size) are passed in memory in a location specified by the caller through
a hidden pointer argument. This way assembler routines originally
written for Small-C or code generated by Small-C can be called from
SDCC. Currently variable arguments are not yet supported (neither
on the caller nor on the callee side).

\subsection{Complex instructions}

The Z80 and some derivatives support complex instructions, such as
ldir, cpir, ... . SDCC only emits these instructions for functions
in the standard library. Thus, e.g. copying one array into another
is more efficient when using memcpy() than by using a a user-written
loop.

Depending on the target, code generation options and the parameters
to the call, SDCC emits ldir for memcpy(), ldir or lsidr for memset(),
ldi for strcpy(), ldi for strncpy(). Other library functions use the
complex instructions as well, but for those, function calls are generated.

\subsection{Unsafe reads}

Usually, Z80-based systems (except for the SM83 and TLCS-90) have
separate I/O and memory spaces, and any normal memory location can
be read without side-effects. For such systems, the option –allow-unsafe-reads
can be used to enable some extra optimizations that rely on this.

\subsection{Z80 banked calls}

Banked calls are supported via \_\_banked. Banked calls are done via
a trampoline (\_\_sdcc\_bcall if -{}-legacy-banking is specified,
\_\_sdcc\_bcall\_abc for z88dk\_fastcall, \_\_sdcc\_bcall\_ehl for
other calls). Default trampolines are provided in the library. The
default trampolines calls user supplied helper functions set\_bank
and get\_bank that set the current bank to the value in register a,
or return the current bank in register a.

For banked functions, the calling convention is slightly different:
the stack is always cleared up by the caller. Unless \_\_z88dk\_fastcall
is used, all parameters are passed on the stack.

\section{The HC08 and S08 ports}

The port to the Freescale/Motorola HC08\index{HC08} and S08 does
not yet generate code as compact as that generated by some non-free
compilers. A comparison of compilers for these architecture can be
found at \url{http://sdcc.sourceforge.net/wiki/index.php/Hc08_code_size}.

\subsection{Startup Code}

The HC08\index{HC08} startup code follows the same scheme as the
MCS51 startup code.

\section{The STM8 port}

\subsection{Calling conventions}

By default, the SDCC calling convention, version 1 is used. Using
the option –sdcccall 0, the default can be changed to version 0.

Arguments are passed on the stack right-to-left. Return values are
in a (8 bit), x (16 bit), xyl (24 bit), xy (32 bit) or use a hidden
extra pointer parameter pointing to the location (anything wider than
32 bit, and all struct / union).

\subsubsection{SDCC calling convention, version 1}

\includegraphics{stm8-arguments}

For functions that have variable arguments, all parameters are passed
on the stack. For other functions, if the first parameter has 8 or
16 bits, it is passed in a or x. If the first parameter is passed
in a, and the second has 16 bits, the second is passed in x. If the
first parameter is passed in x, and the second has 8 bits, the second
is passed in a. All other parameters are passed on the stack. Independent
of their size, struct / union parameters and all following parameters
are always passed on the stack. If \_\_z88dk\_callee is specified,
the stack is always adjusted by the callee. Otherwise, for the large
memory model, the stack is always adjusted by the caller. For the
medium memory model the stack is adjusted by the caller, with the
following exceptions: functions that do not have variable arguments
and return void or a type of at most 16 bits, or have both a first
parameter of type float and a return value of type float.

\subsubsection{SDCC calling convention, version 0}

This calling convention can be chosen per function via \_\_sdcccall(0)
(e.g. for compatibility with functions written in assembler for use
with older versions of SDCC). All parameters are passed on the stack.
The stack is not adjusted for the parameters by the callee (thus the
caller has to do this instead), unless \_\_z88dk\_callee is specified.

\subsubsection{Raisonance calling convention}

For compatibility with the \foreignlanguage{british}{Raisonance} STM8
compiler, the \_\_raisonance calling convention is supported. If the
first parameter is 8 or 16 bits, it is passed in a or x. If the first
parameter is 8 bits, and the second 16 bits, the second is passed
in x. If the first parameter is 16 bits, and the second is 8 bits,
the second is passed in a. All other parameters are passed on the
stack. If the return value is 8 bits, it is passed in a. If it is
16 bits, it is passed in x. Raisonance passes larger return values
in pseudoregisters, which is not supported by SDCC.

\subsubsection{IAR calling convention}

For compatibility with the IAR STM8 compiler, the \_\_iar calling
convention is supported. The first 8-bit parameter is passed in a,
the first 16-bit parameter in x, the second 16-bit parameter in y.
Further parameters of up to 32 bits are passed in pseudoregisters,
which is not supported by SDCC. All other parameters are passed on
the stack. If the return value is 8 bits, it is passed in a. If it
is 16 bits, it is passed in x. IAR passes larger return values in
pseudoregisters, which is not supported by SDCC.

\subsubsection{Cosmic calling convention}

For compatibility with the Cosmic STM8 compiler, the \_\_cosmic calling
convention is supported. If the first parameter is 8 or 16 bits, it
is passed in a or x. If the return value is 8 bits, it is passed in
a. If it is 16 bits, it is passed in x. Cosmic passes larger return
values in pseudoregisters, which is not supported by SDCC. Even for
the medium memory model, \_\_cosmic functions use a 24-bit return
address in their stack frame, and are called using callf.

\section{The PIC14\index{PIC14} port}

The PIC14 port adds support for Microchip\index{Microchip}$^{\text{TM}}$
PIC\index{PIC14}$^{\text{TM}}$ MCUs with 14 bit wide instructions.
This port is not yet mature and still lacks many features. However,
it can work for simple code.

\noindent Currently supported devices include:

\medskip{}

10F320, 10F322, 10LF320, 10LF322

12F609, 12F615, 12F617, 12F629, 12F635, 12F675, 12F683

12F752

12HV752

16C62, 16C63A, 16C65B

16C71, 16C72, 16C73B, 16C74B

16C432, 16C433

16C554, 16C557, 16C558

16C620, 16C620A, 16C621, 16C621A, 16C622, 16C622A

16C710, 16C711, 16C715, 16C717, 16C745, 16C765, 16C770, 16C771, 16C773,
16C774, 16C781, 16C782

16C925, 16C926 

16CR73, 16CR74, 16CR76, 16CR77

16CR620A

16F72 ,16F73, 16F74, 16F76, 16F77

16F84, 16F84A, 16F87, 16F88

16F610, 16F616, 16F627, 16F627A, 16F628, 16F628A, 16F630, 16F631,
16F636, 16F639, 16F648A

16F676, 16F677, 16F684, 16F685, 16F687, 16F688, 16F689, 16F690

16F707, 16F716, 16F720, 16F721, 16F722, 16F722A, 16F723, 16F723A,
16F724, 16F726, 16F727

16F737, 16F747, 16F753, 16F767, 16F777, 16F785

16F818, 16F819, 16F870, 16F871, 16F872, 16F873, 16F873A, 16F874, 16F874A,
16F876, 16F876A

16F877, 16F877A, 16F882, 16F883, 16F884, 16F886, 16F887

16F913, 16F914, 16F916, 16F917, 16F946

16LF74, 16LF76, 16LF77

16LF84, 16LF84A, 16LF87, 16LF88

16LF627, 16LF627A, 16LF628, 16LF628A, 16LF648A

16LF707, 16LF720, 16LF721, 16LF722, 16LF722A, 16LF723, 16LF723A, 16LF724,
16LF726, 16LF727 

16LF747, 16LF767, 16LF777

16LF818, 16LF819, 16LF870, 16LF871, 16LF872, 16LF873, 16LF873A, 16LF874,
16LF874A

16LF876, 16LF876A, 16LF877, 16LF877A

16HV610, 16HV616, 16HV753, 16HV785

\medskip{}

\noindent\begin{flushleft}
Supported devices with enhanced cores:
\par\end{flushleft}

\medskip{}

12F1501, 12F1571, 12F1572, 12F1612, 12F1822, 12F1840

12LF1501, 12LF1552, 12LF1571, 12LF1572, 12LF1612, 12LF1822, 12LF1840,
12LF1840T39A, 12LF1840T48A

16F1454, 16F1455, 16F1458, 16F1459

16F1503, 16F1507, 16F1508, 16F1509, 16F1512, 16F1513, 16F1516, 16F1517,
16F1518, 16F1519

16F1526, 16F1527, 16F1574, 16F1575, 16F1578, 16F1579

16F1613, 16F1614, 16F1615, 16F1618, 16F1619

16F1703, 16F1704, 16F1705, 16F1707, 16F1708, 16F1709, 16F1713, 16F1716,
16F1717, 16F1718, 16F1719

16F1764, 16F1765, 16F1768, 16F1769, 16F1773, 16F1776, 16F1777, 16F1778,
16F1779

16F1782, 16F1783, 16F1784, 16F1786, 16F1787, 16F1788, 16F1789

16F1823, 16F1824, 16F1825, 16F1826, 16F1827, 16F1828, 16F1829, 16F1829LIN,
16F1847

16F1933, 16F1934, 16F1936, 16F1937, 16F1938, 16F1939, 16F1946, 16F1947

16F18313, 16F18323, 16F18324, 16F18325, 16F18344, 16F18345,

16F18855, 16F18875

16LF1454, 16LF1455, 16LF1458, 16LF1459

16LF1503, 16LF1507, 16LF1508, 16LF1509, 16LF1512, 16LF1513, 16LF1516,
16LF1517, 16LF1518, 16LF1519,

16LF1526, 16LF1527 

16LF1554, 16LF1559, 16LF1566, 16LF1567, 16LF1574, 16LF1575, 16LF1578,
16LF1579

16LF1613, 16LF1614, 16LF1615, 16LF1618, 16LF1619

16LF1703, 16LF1704, 16LF1705, 16LF1707, 16LF1708, 16LF1709, 16LF1713,
16LF1716, 16LF1717, 16LF1718, 16LF1719 

16LF1764, 16LF1765, 16LF1768, 16LF1769, 16LF1773, 16LF1776, 16LF1777,
16LF1778, 16LF1779

16LF1782, 16LF1783, 16LF1784, 16LF1786, 16LF1787, 16LF1788, 16LF1789,

16LF1823, 16LF1824, 16LF1824T39A

16LF1825, 16LF1826, 16LF1827, 16LF1828, 16LF1829, 16LF1847

16LF1902, 16LF1903, 16LF1904, 16LF1906, 16LF1907

16LF1933, 16LF1934, 16LF1936, 16LF1937, 16LF1938, 16LF1939, 16LF1946,
16LF1947

16LF18313, 16LF18323, 16LF18324, 16LF18325, 16LF18344, 16LF18345

16LF18855, 16LF18875

\medskip{}

\noindent An up-to-date list of currently supported devices can be
obtained via \texttt{sdcc -mpic14 -phelp foo.c} (foo.c must exist...).

\subsection{PIC Code Pages\index{code page (pic14)} and Memory Banks\index{Memory bank (pic14)}}

The linker organizes allocation for the code page and RAM banks. It
does not have intimate knowledge of the code flow. It will put all
the code section of a single .asm file into a single code page. In
order to make use of multiple code pages, separate asm files must
be used. The compiler assigns all \emph{static} functions of a single
.c file into the same code page.\\
\\
To get the best results, follow these guidelines:
\begin{enumerate}
\item Make local functions static, as non static functions require code
page selection overhead.\\
Due to the way SDCC handles functions, place called functions prior
to calling functions in the file wherever possible: Otherwise SDCC
will insert unnecessary pagesel directives around the call, believing
that the called function is externally defined.
\item For devices that have multiple code pages it is more efficient to
use the same number of files as pages: Use up to 4 separate .c files
for the 16F877, but only 2 files for the 16F874. This way the linker
can put the code for each file into different code pages and there
will be less page selection overhead.
\item And as for any 8 bit micro (especially for PIC14 as they have a very
simple instruction set), use `unsigned char' wherever possible instead
of `int'.
\end{enumerate}

\subsection{Adding New Devices to the Port }

Adding support for a new 14\,bit PIC MCU requires the following steps:
\begin{enumerate}
\item Create a new device description.\\
Each device is described in two files: pic16f{*}.h and pic16f{*}.c.
These files primarily define SFRs, structs to access their bits, and
symbolic configuration options. Both files can be generated from gputils'
.inc files using the perl script \texttt{support/scripts/inc2h.pl}.
This file also contains further instructions on how to proceed.
\item Copy the .h file into SDCC's include path and either add the .c file
to your project or copy it to \texttt{device/lib/pic/libdev}. Afterwards,
rebuild and install the libraries.
\item Edit pic14devices.txt in SDCC's include path (\texttt{device/include/pic/}
in the source tree or \texttt{/usr/local/share/sdcc/include/pic} after
installation).\\
You need to add a device specification here to make the memory layout
(code banks, RAM, aliased memory regions, ...) known to the compiler.
Probably you can copy and modify an existing entry. The file format
is documented at the top of the file.
\end{enumerate}

\subsection{Interrupt Code}

For the interrupt function, use the keyword \emph{\_\_interrupt}\index{PIC14!interrupt}
with level number of 0 (PIC14 only has 1 interrupt so this number
is only there to avoid a syntax error - it ought to be fixed). E.g.:
\begin{verse}
\texttt{void Intr(void) \_\_interrupt (0)}~\\
\texttt{\{}~\\
\texttt{~~T0IF = 0; /{*} Clear timer interrupt {*}/}~\\
\texttt{\}}
\end{verse}

\subsection{Configuration Bits}

Configuration bits (also known as fuses) can be configured using `\texttt{\_\_code}'
and `\texttt{\_\_at}' modifiers. Possible options should be ANDed
and can be found in your processor header file. Example for PIC16F88:
\begin{lyxcode}
\#include~<pic16f88.h>~//Contains~config~addresses~and~options~\\
\#include~<stdint.h>~//Needed~for~uint16\_t~\\
~\\
static~\_\_code~uint16\_t~\_\_at~(\_CONFIG1)~configword1~=~\_INTRC\_IO~\&~\\
~~\_CP\_ALL~\&~\_WDT\_OFF~\&~{[}...{]};~\\
static~\_\_code~uint16\_t~\_\_at~(\_CONFIG2)~configword2~=~{[}...{]};
\end{lyxcode}
Although data type is ignored if the address (\texttt{\_\_at()}) refers
to a config word location, using a type large enough for the configuration
word (\texttt{uint16\_t} in this case) is recommended to prevent changes
in the compiler (implicit, early range check and enforcement) from
breaking the definition.\\
\\
If your processor header file doesn't contain config addresses you
can declare it manually or use a literal address:
\begin{lyxcode}
static~\_\_code~uint16\_t~\_\_at~(0x2007)~configword1~=~\_INTRC\_IO~\&~\\
~~\_CP\_ALL~\&~\_WDT\_OFF~\&~{[}...{]};
\end{lyxcode}

\subsection{Linking and Assembling}

For assembling you can use either GPUTILS'\index{gputils (pic tools)}
gpasm.exe or MPLAB's mpasmwin.exe. GPUTILS are available from \url{http://sourceforge.net/projects/gputils}.
For linking you can use either GPUTILS' gplink or MPLAB's mplink.exe.
If you use MPLAB and an interrupt function then the linker script
file vectors section will need to be enlarged to link with mplink.\\
\\
Pic device specific header and c source files are automatically generated
from MPLAB include files, which are published by Microchip with a
special requirement that they are only to be used with authentic Microchip
devices. This reqirement prevents to publish generated header and
c source files under the GPL compatible license, so they are located
in non-free directory (see section \ref{subsec:Search-Paths}). In
order to include them in include and library search paths, the \textbf{-\/-use-non-free\index{-/-use-non-free@-\/-use-non-free}}
command line option should be defined.\\
\\
NOTE: the compiled code, which use non-free pic device specific libraries,
is not GPL compatible!\\
\\
Here is a \texttt{Makefile} using GPUTILS:
\begin{verse}
\texttt{.c.o:}~\\
\texttt{~~~~~~~~sdcc -V -{}-use-non-free -mpic14 -p16f877
-c \$<}~\\
\texttt{}~\\
\texttt{\$(PRJ).hex: \$(OBJS)}~\\
\texttt{~~~~~~~~gplink -m -s \$(PRJ).lkr -o \$(PRJ).hex \$(OBJS)
libsdcc.lib}
\end{verse}
Here is a \texttt{Makefile} using MPLAB:
\begin{verse}
\texttt{.c.o: }~\\
\texttt{~~~~~~~~sdcc -S -V -{}-use-non-free -mpic14 -p16f877
\$<}~\\
\texttt{~~~~~~~~mpasmwin /q /o \${*}.asm}~\\
\texttt{}~\\
\texttt{\$(PRJ).hex: \$(OBJS)}~\\
\texttt{~~~~~~~~mplink /v \$(PRJ).lkr /m \$(PRJ).map /o \$(PRJ).hex
\$(OBJS) libsdcc.lib}
\end{verse}
Please note that indentations within a \texttt{Makefile} have to be
done with a tabulator character.

\subsection{Command-Line Options}

Besides the switches common to all SDCC backends, the PIC14 port accepts
the following options (for an updated list see sdcc -\/-help):
\begin{description}
\item [{-\/-debug-xtra\index{PIC14!Options!-/-debug-extra@-\/-debug-extra}}] emit
debug info in assembly output
\item [{-\/-no-pcode-opt\index{PIC14!Options!-/-no-pcode-opt@-\/-no-pcode-opt}}] disable
(slightly faulty) optimization on pCode
\item [{-\/-stack-loc\index{PIC14!Options!-/-stack-loc@-\/-stack-loc}}] sets
the lowest address of the argument passing stack (defaults to a suitably
large shared databank to reduce BANKSEL overhead)
\item [{-\/-stack-size\index{PIC14!Options!-/-stack-size@-\/-stack-size}}] sets
the size if the argument passing stack (default: 16, minimum: 4)
\item [{-\/-use-non-free\index{PIC14!Options!-/-use-non-free@-\/-use-non-free}}] make
non-free device headers and libraries available in the compiler's
search paths (implicit -I and -L options)
\item [{-\/-no-extended-instructions}] forbid use of the extended instruction
set (e.g., ADDFSR)
\end{description}

\subsection{Environment Variables}

The PIC14 port recognizes the following environment variables:
\begin{description}
\item [{SDCC\_PIC14\_SPLIT\_LOCALS\index{PIC14!Environment variables!SDCC_PIC14_SPLIT_LOCALS@SDCC\_PIC14\_SPLIT\_LOCALS}\index{SDCC!Environment variables!SDCC_PIC14_SPLIT_LOCALS@SDCC\_PIC14\_SPLIT\_LOCALS}}] If
set and not empty, sdcc will allocate each temporary register (the
ones called r0xNNNN) in a section of its own. By default (if this
variable is unset), sdcc tries to cluster registers in sections in
order to reduce the BANKSEL overhead when accessing them.
\end{description}

\subsection{The Library}

The PIC14 library currently only contains support routines required
by the compiler to implement multiplication, division, and floating
point support. No libc-like replacement is available at the moment,
though many of the common sdcc library sources (in \texttt{device/lib})
should also compile with the PIC14 port.

\subsubsection{Enhanced cores}

SDCC/PIC14 has experimental support for devices with the enhanced
14-bit cores (such as pic12f1822). Due to differences in required
code, the libraries provided with SDCC (\texttt{libm.lib} and \texttt{libsdcc.lib})
are now provided in two variants: \texttt{libm.lib} and \texttt{libsdcc.lib}
are compiled for the regular, non-enhanced devices. \texttt{libme.lib}
and \texttt{libsdcce.lib} (note the trailing '\texttt{e}') are compiled
for enhanced devices. When linking manually, make sure to select the
proper variant!

When SDCC is used to invoke the linker, SDCC will automatically select
the \texttt{libsdcc.lib}-variant suitable for the target device. However,
no such magic has been conjured up for \texttt{libm.lib}!

\subsubsection{Accessing bits of special function registers}

Individual bits within SFRs can be accessed either using \texttt{<sfrname>bits.<bitname>}
or using a shorthand \texttt{<bitname>}, which is defined in the respective
device header for all \texttt{<bitname>}s. In order to avoid polluting
the global namespace with the names of all the bits, you can \texttt{\#define
NO\_BIT\_DEFINES} before inclusion of the device header file.

\subsubsection{Naming of special function registers\label{subsec:Naming-of-special}}

If \texttt{NO\_BIT\_DEFINES} is used, individual bits of the SFRs
can be accessed as \texttt{<sfrname>bits.<bitname>}. With the 3.1.0
release, the previously used \texttt{<sfrname>\_bits.<bitname>} (note
the underscore) is deprecated. This was done to align the naming conventions
with the PIC16 port and competing compiler vendors. To avoid polluting
the global namespace with the legacy names, you can prevent their
definition using \texttt{\#define NO\_LEGACY\_NAMES} prior to the
inclusion of the device header.

You \texttt{\textbf{must}} also \texttt{\#define NO\_BIT\_DEFINES}
in order to access SFRs as \texttt{<sfrname>bits.<bitname>}, otherwise
\texttt{<bitname>} will expand to \texttt{<sfrname>bits.<bitname>},
yielding the undefined expression \texttt{<sfrname>bits.<sfrname>bits.<bitname>}.

\subsubsection{error: missing definition for symbol ``\_\_gptrget1''}

The PIC14 port uses library routines to provide more complex operations
like multiplication, division/modulus and (generic) pointer dereferencing.
In order to add these routines to your project, you must link with
PIC14's \texttt{libsdcc.lib}. For single source file projects this
is done automatically, more complex projects must add \texttt{libsdcc.lib}
to the linker's arguments. Make sure you also add an include path
for the library (using the -I switch to the linker)!

\subsubsection{Processor mismatch in file ``XXX''.}

This warning can usually be ignored due to the very good compatibility
amongst 14\,bit PIC\index{PIC14} devices.

You might also consider recompiling the library for your specific
device by changing the ARCH=p16f877 (default target) entry in \texttt{device/lib/pic/Makefile.in}
and \texttt{device/lib/pic/Makefile} to reflect your device. This
might even improve performance for smaller devices as unnecessary
BANKSELs might be removed.

\subsection{Known Bugs}

\subsubsection{Function arguments}

Functions with variable argument lists (like printf) are not yet supported.
Similarly, taking the address of the first argument passed into a
function does not work: It is currently passed in WREG and has no
address...

\subsubsection{Regression tests fail}

Though the small subset of regression tests in src/regression passes,
SDCC regression test suite does not, indicating that there are still
major bugs in the port. However, many smaller projects have successfully
used SDCC in the past...

\section{The PIC16\index{PIC16} port}

The PIC16 port adds support for Microchip\index{Microchip}$^{\text{TM}}$
PIC\index{PIC}$^{\text{TM}}$ MCUs with 16 bit wide instructions.
This port is not yet mature and still lacks many features. However,
it can work for simple code. Currently this family of microcontrollers
contains the PIC18Fxxx and PIC18Fxxxx; devices supported by the port
include:

\medskip{}

18F13K22 18F13K50

18F14K22 18F14K50

18F23K20 18F23K22

18F24J10 18F24J11 18F24J50 18F24K20 18F24K22 18F24K50

18F25J10 18F25J11 18F25J50 18F25K20 18F25K22 18F25K50 18F25K80

18F26J11 18F26J13 18F26J50 18F26J53 18F26K20 18F26K22 18F26K80

18F27J13 18F27J53

18F43K20 18F43K22

18F44J10 18F44J11 18F44J50 18F44K20 18F44K22

18F45J10 18F45J11 18F45J50 18F45K20 18F45K22 18F45K50 18F45K80

18F46J11 18F46J13 18F46J50 18F46J53 18F46K20 18F46K22 18F46K80

18F47J13 18F47J53

18F63J11 18F63J90

18F64J11 18F64J90

18F65J10 18F65J11 18F65J15 18F65J50 18F65J90 18F65J94 18F65K22 18F65K80
18F65K90

18F66J10 18F66J11 18F66J15 18F66J16 18F66J50 18F66J55 18F66J60 18F66J65

18F66J90 18F66J93 18F66J94 18F66J99 18F66K22 18F66K80 18F66K90

18F67J10 18F67J11 18F67J50 18F67J60 18F67J90 18F67J93 18F67J94 18F67K22
18F67K90

18F83J11 18F83J90

18F84J11 18F84J90

18F85J10 18F85J11 18F85J15 18F85J50 18F85J90 18F85J94 18F85K22 18F85K90

18F86J10 18F86J11 18F86J15 18F86J16 18F86J50 18F86J55 18F86J60 18F86J65

18F86J72 18F86J90 18F86J93 18F86J94 18F86J99 18F86K22 18F86K90

18F87J10 18F87J11 18F87J50 18F87J60 18F87J72 18F87J90 18F87J93 18F87J94
18F87K22 18F87K90

18F95J94 18F96J60 18F96J65 18F96J94 18F96J99

18F97J60 18F97J94

18F242 18F248 18F252 18F258

18F442 18F448 18F452 18F458

18F1220 18F1230

18F1320 18F1330

18F2220 18F2221

18F2320 18F2321 18F2331

18F2410 18F2420 18F2423 18F2431 18F2439 18F2450 18F2455 18F2458 18F2480

18F2510 18F2515 18F2520 18F2523 18F2525 18F2539 18F2550 18F2553 18F2580
18F2585

18F2610 18F2620 18F2680 18F2682 18F2685

18F4220 18F4221

18F4320 18F4321 18F4331

18F4410 18F4420 18F4423 18F4431 18F4439 18F4450 18F4455 18F4458 18F4480

18F4510 18F4515 18F4520 18F4523 18F4525 18F4539 18F4550 18F4553 18F4580
18F4585

18F4610 18F4620 18F4680 18F4682 18F4685

18F6310 18F6390 18F6393

18F6410 18F6490 18F6493

18F6520 18F6525 18F6527 18F6585

18F6620 18F6621 18F6622 18F6627 18F6628 18F6680

18F6720 18F6722 18F6723

18F8310 18F8390 18F8393

18F8410 18F8490 18F8493

18F8520 18F8525 18F8527 18F8585

18F8620 18F8621 18F8622 18F8627 18F8628 18F8680

18F8720 18F8722 18F8723

18LF13K22 18LF13K50

18LF14K22 18LF14K50

18LF23K22 18LF24J10 18LF24J11 18LF24J50 18LF24K22 18LF24K50

18LF25J10 18LF25J11 18LF25J50 18LF25K22 18LF25K50 18LF25K80

18LF26J11 18LF26J13 18LF26J50 18LF26J53 18LF26K22 18LF26K80

18LF27J13 18LF27J53

18LF43K22

18LF44J10 18LF44J11 18LF44J50 18LF44K22

18LF45J10 18LF45J11 18LF45J50 18LF45K22 18LF45K50 18LF45K80

18LF46J11 18LF46J13 18LF46J50 18LF46J53 18LF46K22 18LF46K80

18LF47J13 18LF47J53

18LF65K80

18LF66K80

18LF242 18LF248 18LF252 18LF258

18LF442 18LF448 18LF452 18LF458

18LF1220 18LF1230

18LF1320 18LF1330

18LF2220 18LF2221

18LF2320 18LF2321 18LF2331

18LF2410 18LF2420 18LF2423 18LF2431 18LF2439 18LF2450 18LF2455 18LF2458
18LF2480

18LF2510 18LF2515 18LF2520 18LF2523 18LF2525 18LF2539 18LF2550 18LF2553
18LF2580 18LF2585

18LF2610 18LF2620 18LF2680 18LF2682 18LF2685

18LF4220 18LF4221

18LF4320 18LF4321 18LF4331

18LF4410 18LF4420 18LF4423 18LF4431 18LF4439 18LF4450 18LF4455 18LF4458
18LF4480

18LF4510 18LF4515 18LF4520 18LF4523 18LF4525 18LF4539 18LF4550 18LF4553
18LF4580 18LF4585

18LF4610 18LF4620 18LF4680 18LF4682 18LF4685

18LF6310 18LF6390 18LF6393

18LF6410 18LF6490 18LF6493

18LF6520 18LF6525 18LF6527 18LF6585

18LF6620 18LF6621 18LF6622 18LF6627 18LF6628 18LF6680

18LF6720 18LF6722 18LF6723

18LF8310 18LF8390 18LF8393

18LF8410 18LF8490 18LF8493

18LF8520 18LF8525 18LF8527 18LF8585

18LF8620 18LF8621 18LF8622 18LF8627 18LF8628 18LF8680

18LF8720 18LF8722 18LF8723 

\medskip{}

\noindent An up-to-date list of supported devices is also available
via '\texttt{sdcc -mpic16 -plist}'.

\subsection{Global Options}

PIC16 port supports the standard command line arguments as supposed,
with the exception of certain cases that will be mentioned in the
following list:
\begin{description}
\item [{-\/-callee-saves\index{PIC16!Options!-/-callee-saves@-\/-callee-saves}}] See
-\/-all-callee-saves
\item [{-\/-use-non-free\index{PIC16!Options!-/-use-non-free@-\/-use-non-free}}] Make
non-free device headers and libraries available in the compiler's
search paths (implicit -I and -L options).
\end{description}

\subsection{Port Specific Options\index{Options PIC16}}

The port specific options appear after the global options in the sdcc
-\/-help output.

\subsubsection{Code Generation Options}

These options influence the generated assembler code.
\begin{description}
\item [{-\/-pstack-model={[}model{]}}] Used in conjunction with the command
above. Defines the stack model to be used, valid stack models are:

\begin{lyxlist}{00.00.0000}
\item [{\emph{small}}] Selects small stack model. 8 bit stack and frame
pointers. Supports 256 bytes stack size.
\item [{\emph{large}}] Selects large stack model. 16 bit stack and frame
pointers. Supports 65536 bytes stack size.
\end{lyxlist}
\item [{-\/-pno-banksel}] Do not generate BANKSEL assembler directives.
\item [{-\/-extended}] Enable extended instruction set/literal offset
addressing mode. Use with care!
\end{description}

\subsubsection{Optimization Options}
\begin{description}
\item [{-\/-obanksel=n}] Set optimization level for inserting BANKSELs.\\

\begin{lyxlist}{00.00.0000}
\item [{0}] no optimization
\item [{1}] checks previous used register and if it is the same then does
not emit BANKSEL, accounts only for labels.
\item [{2}] tries to check the location of (even different) symbols and
removes BANKSELs if they are in the same bank. \\
\emph{Important: There might be problems if the linker script has
data sections across bank borders!}
\end{lyxlist}
\item [{-\/-denable-peeps}] Force the usage of peepholes. Use with care.
\item [{-\/-no-optimize-goto}] Do not use (conditional) BRA instead of
GOTO.
\item [{-\/-optimize-cmp}] Try to optimize some compares.
\item [{-\/-optimize-df}] Analyze the dataflow of the generated code and
improve it.
\end{description}

\subsubsection{Assembling Options}
\begin{description}
\item [{-\/-asm=}] Sets the full path and name of an external assembler
to call.
\item [{-\/-mplab-comp}] MPLAB\index{PIC16!MPLAB} compatibility option.
Currently only suppresses special gpasm directives.
\end{description}

\subsubsection{Linking Options}
\begin{description}
\item [{-\/-link=}] Sets the full path and name of an external linker
to call.
\item [{-\/-preplace-udata-with={[}kword{]}}] Replaces the default udata
keyword for allocating unitialized data variables with {[}kword{]}.
Valid keywords are: \textquotedbl udata\_acs\textquotedbl , \textquotedbl udata\_shr\textquotedbl ,
\textquotedbl udata\_ovr\textquotedbl .
\item [{-\/-ivt-loc=n}] Place the interrupt vector table at address \emph{n}.
Useful for bootloaders.
\item [{-\/-nodefaultlibs}] Do not link default libraries when linking.
\item [{-\/-use-crt=}] Use a custom run-time module instead of the default
(crt0i).
\item [{-\/-no-crt}] Don't link the default run-time modules
\end{description}

\subsubsection{Debugging Options}

Debugging options enable extra debugging information in the output
files.
\begin{description}
\item [{-\/-debug-xtra}] Similar to -\/-debug\index{-/-debug@-\/-debug},
but dumps more information.
\item [{-\/-debug-ralloc}] Force register allocator to dump <source>.d
file with debugging information. <source> is the name of the file
being compiled.
\item [{-\/-pcode-verbose}] Enable pcode debugging information in translation.
\item [{-\/-calltree}] Dump call tree in .calltree file.
\item [{-\/-gstack}] Trace push/pops for stack pointer overflow.
\end{description}

\subsection{Environment Variables}

There is a number of environmental variables that can be used when
running SDCC to enable certain optimizations or force a specific program
behaviour. these variables are primarily for debugging purposes so
they can be enabled/disabled at will.

Currently there is only two such variables available:
\begin{description}
\item [{OPTIMIZE\_BITFIELD\_POINTER\_GET\index{PIC16!Environment variables!OPTIMIZE_BITFIELD_POINTER_GET@OPTIMIZE\_BITFIELD\_POINTER\_GET}\index{SDCC!Environment variables!OPTIMIZE_BITFIELD_POINTER_GET (PIC16)@OPTIMIZE\_BITFIELD\_POINTER\_GET (PIC16)}}] When
this variable exists, reading of structure bit-fields is optimized
by directly loading FSR0 with the address of the bit-field structure.
Normally SDCC will cast the bit-field structure to a bit-field pointer
and then load FSR0. This step saves data ram and code space for functions
that make heavy use of bit-fields. (i.e., 80 bytes of code space are
saved when compiling malloc.c with this option). 
\item [{NO\_REG\_OPT\index{PIC16!Environment variables!NO_REG_OPT@NO\_REG\_OPT}\index{SDCC!Environment variables!NO_REG_OPT@NO\_REG\_OPT}}] Do
not perform pCode registers optimization. This should be used for
debugging purposes. If bugs in the pcode optimizer are found, users
can benefit from temporarily disabling the optimizer until the bug
is fixed.
\end{description}

\subsection{Preprocessor Macros\index{Preprocessor!PIC16 Macros}}

PIC16\index{PIC16} port defines the following preprocessor macros
while translating a source.

\begin{center}
\begin{tabular}{|c|c|}
\hline 
Macro & Description\tabularnewline
\hline 
\hline 
\_\_SDCC\_pic16\index{SDCC!Defines!__SDCC_pic16@\_\_SDCC\_pic16} & Port identification\tabularnewline
\hline 
pic18fxxxx\index{PIC16!Defines!pic18fxxxx} & MCU Identification. \emph{xxxx} is the microcontrol identification
number, i.e. 452, 6620, etc\tabularnewline
\hline 
\_\/\_18Fxxxx\index{PIC16!Defines!__pic18fxxxx@\_\_pic18fxxxx} & MCU Identification (same as above)\tabularnewline
\hline 
STACK\_MODEL\_nnn\index{PIC16!Defines!STACK_MODEL_nnn@STACK\_MODEL\_nnn} & nnn = SMALL or LARGE respectively according to the stack model used\tabularnewline
\hline 
\end{tabular}
\par\end{center}

\noindent In addition the following macros are defined when calling
assembler:

\begin{center}
\begin{tabular}{|c|c|}
\hline 
Macro & Description\tabularnewline
\hline 
\hline 
\_\_18Fxxxx & MCU Identification. \emph{xxxx} is the microcontrol identification
number, i.e. 452, 6620, etc\tabularnewline
\hline 
\_\_SDCC\_MODEL\_nnn & nnn = SMALL or LARGE respectively according to the memory model used
for SDCC\tabularnewline
\hline 
STACK\_MODEL\_nnn & nnn = SMALL or LARGE respectively according to the stack model used\tabularnewline
\hline 
\end{tabular}
\par\end{center}

\subsection{Directories}

PIC16\index{PIC16} port uses the following directories for searching
header files and libraries.\\

\begin{center}
\begin{tabular}{|c|c|c|c|}
\hline 
Directory & Description & Target & Command prefix\tabularnewline
\hline 
\hline 
PREFIX/sdcc/include/pic16 & PIC16 specific headers & Compiler & -I\tabularnewline
\hline 
PREFIX/sdcc/lib/pic16 & PIC16 specific libraries & Linker & -L\tabularnewline
\hline 
\end{tabular}
\par\end{center}

If the \textbf{-\/-use-non-free\index{-/-use-non-free@-\/-use-non-free}}
command line option is specified, non-free directories are searched:\\

\begin{center}
\begin{tabular}{|c|c|c|c|}
\hline 
Directory & Description & Target & Command prefix\tabularnewline
\hline 
\hline 
PREFIX/sdcc/non-free/include/pic16 & PIC16 specific non-free headers & Compiler & -I\tabularnewline
\hline 
PREFIX/sdcc/non-free/lib/pic16 & PIC16 specific non-free libraries & Linker & -L\tabularnewline
\hline 
\end{tabular}
\par\end{center}

\subsection{Pragmas\label{subsec:PIC16_Pragmas}}

The PIC16\index{PIC16} port currently supports the following pragmas:
\begin{description}
\item [{stack\index{PIC16!Pragmas!#pragma stack@\#pragma stack}}] This
forces the code generator to initialize the stack \& frame pointers
at a specific address. This is an ad hoc solution for cases where
no STACK directive is available in the linker script or gplink is
not instructed to create a stack section.\\
The stack pragma should be used only once in a project. Multiple pragmas
may result in indeterminate behaviour of the program.\footnote{The old format (ie. \#pragma stack 0x5ff) is deprecated and will cause
the stack pointer to cross page boundaries (or even exceed the available
data RAM) and crash the program. Make sure that stack does not cross
page boundaries when using the SMALL stack model.}\\
The format is as follows:
\end{description}
\begin{lyxcode}
\#pragma~stack~bottom\_address~{[}stack\_size{]}~\\
\end{lyxcode}
\emph{bottom\_address} is the lower bound of the stack section. The
stack pointer initially will point at address (bottom\_address+stack\_size-1).
\begin{lyxcode}
Example:

/{*}~initializes~stack~of~100~bytes~at~RAM~address~0x200~{*}/

\#pragma~stack~0x200~100
\end{lyxcode}
If the stack\_size field is omitted then a stack is created with the
default size of 64. This size might be enough for most programs, but
its not enough for operations with deep function nesting or excessive
stack usage.
\begin{description}
\item [{code\index{PIC16!Pragmas!#pragma code@\#pragma code}}] Force a
function to a static FLASH address.
\end{description}
\begin{lyxcode}
Example:

/{*}~place~function~test\_func~at~0x4000~{*}/

\#pragma~code~test\_func~0x4000

\end{lyxcode}
\begin{description}
\item [{library\index{PIC16!Pragmas!#pragma library@\#pragma library}}] instructs
the linker to use a library module.\\
Usage:
\end{description}
\begin{lyxcode}
\#pragma~library~module\_name
\end{lyxcode}
\emph{module\_name} can be any library or object file (including its
path). Note that there are four reserved keywords which have special
meaning. These are:

\begin{center}
\begin{tabular}{|c|p{0.2\paperwidth}|l|}
\hline 
Keyword & Description & Module to link\tabularnewline
\hline 
\hline 
\textbf{ignore} & ignore all library pragmas & \emph{(none)}\tabularnewline
\hline 
\textbf{c} & link the C library & \emph{libc18f}.lib\tabularnewline
\hline 
\textbf{math} & link the Math libarary & \emph{libm18f}.lib\tabularnewline
\hline 
\textbf{io} & link the I/O library & \emph{libio18f{*}}.lib\tabularnewline
\hline 
\textbf{debug} & link the debug library & \emph{libdebug}.lib\tabularnewline
\hline 
\end{tabular}\\
{*} is the device number, i.e. 452 for PIC18F452 MCU.
\par\end{center}

\noindent This feature allows for linking with specific libraries
without having to explicit name them in the command line. Note that
the \noun{ignore} keyword will reject all modules specified by the
library pragma.
\begin{description}
\item [{udata\index{PIC16!Pragmas!#pragma udata@\#pragma udata}}] The
pragma udata instructs the compiler to emit code so that linker will
place a variable at a specific memory bank.
\end{description}
\begin{lyxcode}
Example:

/{*}~places~variable~foo~at~bank2~{*}/

\#pragma~udata~bank2~foo

char~foo;
\end{lyxcode}
In order for this pragma to work extra SECTION directives should be
added in the .lkr script. In the following example a sample .lkr file
is shown:
\begin{lyxcode}

//~Sample~linker~script~for~the~PIC18F452~processor

LIBPATH~.

CODEPAGE~~~NAME=vectors~~~~START=0x0~~~~~~~~~~~~END=0x29~~~~~~~~~~~PROTECTED

CODEPAGE~~~NAME=page~~~~~~~START=0x2A~~~~~~~~~~~END=0x7FFF

CODEPAGE~~~NAME=idlocs~~~~~START=0x200000~~~~~~~END=0x200007~~~~~~~PROTECTED

CODEPAGE~~~NAME=config~~~~~START=0x300000~~~~~~~END=0x30000D~~~~~~~PROTECTED

CODEPAGE~~~NAME=devid~~~~~~START=0x3FFFFE~~~~~~~END=0x3FFFFF~~~~~~~PROTECTED

CODEPAGE~~~NAME=eedata~~~~~START=0xF00000~~~~~~~END=0xF000FF~~~~~~~PROTECTED

ACCESSBANK~NAME=accessram~~START=0x0~~~~~~~~~~~~END=0x7F

DATABANK~~~NAME=gpr0~~~~~~~START=0x80~~~~~~~~~~~END=0xFF

DATABANK~~~NAME=gpr1~~~~~~~START=0x100~~~~~~~~~~END=0x1FF

DATABANK~~~NAME=gpr2~~~~~~~START=0x200~~~~~~~~~~END=0x2FF

DATABANK~~~NAME=gpr3~~~~~~~START=0x300~~~~~~~~~~END=0x3FF

DATABANK~~~NAME=gpr4~~~~~~~START=0x400~~~~~~~~~~END=0x4FF

DATABANK~~~NAME=gpr5~~~~~~~START=0x500~~~~~~~~~~END=0x5FF

ACCESSBANK~NAME=accesssfr~~START=0xF80~~~~~~~~~~END=0xFFF~~~~~~~~~~PROTECTED

SECTION~~~~NAME=CONFIG~~~~~ROM=config

SECTION~~~~NAME=bank0~~~~~~RAM=gpr0~~~~~~~\#~these~SECTION~directives

SECTION~~~~NAME=bank1~~~~~~RAM=gpr1~~~~~~~\#~should~be~added~to~link

SECTION~~~~NAME=bank2~~~~~~RAM=gpr2~~~~~~~\#~section~name~'bank?'~with

SECTION~~~~NAME=bank3~~~~~~RAM=gpr3~~~~~~~\#~a~specific~DATABANK~name

SECTION~~~~NAME=bank4~~~~~~RAM=gpr4

SECTION~~~~NAME=bank5~~~~~~RAM=gpr5
\end{lyxcode}
The linker will recognise the section name set in the pragma statement
and will position the variable at the memory bank set with the RAM
field at the SECTION line in the linker script file.
\begin{description}
\item [{config\index{PIC16!Pragmas!#pragma config@\#pragma config}}] The
pragma config instructs the compiler to emit config directive.\\
The format is as follows:
\end{description}
\begin{lyxcode}
\#pragma~config~setting=value~{[},~setting=value{]}

\end{lyxcode}
Multiple settings may be defined on a single line, separated by commas.
Settings for a single configuration byte may also be defined on separate
lines. 
\begin{lyxcode}
Example:

\#pragma~config~CP0=OFF,OSCS=ON,OSC=LP,BOR=ON,BORV=25,WDT=ON,WDTPS=128,CCP2MUX=ON

\#pragma~config~STVR=ON~
\end{lyxcode}

\subsection{Header Files and Libraries\label{subsec:PIC16_Header-Files-and-Libraries}}

Pic device specific header and c source files are automatically generated
from MPLAB include files, which are published by Microchip with a
special requirement that they are only to be used with authentic Microchip
devices. This requirement prevents to publish generated header and
c source files under the GPL compatible license, so they are located
in the non-free directory (see section \ref{subsec:Search-Paths}).
In order to include them in include and library search paths, the
\textbf{-\/-use-non-free\index{-/-use-non-free@-\/-use-non-free}}
command line option should be defined.\\
\\
NOTE: the compiled code, which use non-free pic device specific libraries,
is not GPL compatible!

\subsection{Header Files\label{subsec:PIC16_Header-Files}}

There is one main header file\index{PIC16!Header files} that can
be included to the source files using the pic16\index{PIC16} port.
That file is the \textbf{pic18fregs.h}. This header file contains
the definitions for the processor special registers, so it is necessary
if the source accesses them. It can be included by adding the following
line in the beginning of the file:
\begin{lyxcode}
\#include~<pic18fregs.h>
\end{lyxcode}
The specific microcontroller is selected within the pic18fregs.h automatically,
so the same source can be used with a variety of devices.

\subsection{Libraries\label{subsec:pic16Libraries}}

The libraries\index{PIC16!Libraries} that PIC16\index{PIC16} port
depends on are the microcontroller device libraries which contain
the symbol definitions for the microcontroller special function registers.
These libraries have the format pic18fxxxx.lib, where \emph{xxxx}
is the microcontroller identification number. The specific library
is selected automatically by the compiler at link stage according
to the selected device.

\noindent Libraries are created with gplib which is part of the gputils
package \url{http://sourceforge.net/projects/gputils}.

\subsubsection*{Building the libraries}

Before using SDCC/pic16 there are some libraries that need to be compiled.
This process is done automatically if gputils are found at SDCC's
compile time. Should you require to rebuild the pic16 libraries manually
(e.g. in order to enable output of float values\index{printf()!PIC16 Floating point support}
via \texttt{printf()}, see below), these are the steps required to
do so under Linux or Mac OS X (cygwin might work as well, but is untested):
\begin{lyxcode}
cd~device/lib/pic16

./configure.gnu

cd~..

make~model-pic16

su~-c~'make~install'~~~~~\#~install~the~libraries,~you~need~the~root~password

cd~../..
\end{lyxcode}
If you need to install the headers too, do:
\begin{lyxcode}
cd~device/include

su~-c~'make~install'~~~~~\#~install~the~headers,~you~need~the~root~password
\end{lyxcode}

\subsubsection*{Output of float values via printf()}

The library is normally built without support for displaying float
values, only <NO FLOAT>\index{<NO FLOAT>}\index{printf()!PIC16 floating point support}
will appear instead of the value. To change this, rebuild the library
as stated above, but call \texttt{./configure.gnu -{}-enable-floats
}instead of just \texttt{./configure.gnu}. Also make sure that at
least \texttt{libc/stdio/vfprintf.c} is actually recompiled, e.g.
by \texttt{touch}ing it after the \texttt{configure} run or deleting
its \texttt{.o} file.

The more common approach of compiling \texttt{vfprintf.c} manually
with \texttt{-DUSE\_FLOATS=1} should also work, but is untested.

\subsection{Adding New Devices to the Port}

Adding support for a new 16\,bit PIC MCU requires the following steps:
\begin{enumerate}
\item Create picDEVICE.c and picDEVICE.h from pDEVICE.inc using\\
\texttt{perl /path/to/sdcc/support/scripts/inc2h-pic16.pl \textbackslash}~\\
\texttt{/path/to/gputils/header/pDEVICE.inc}
\item \texttt{mv picDEVICE.h /path/to/sdcc/device/non-free/include/pic16}
\item \texttt{mv picDEVICE.c /path/to/sdcc/device/non-free/lib/pic16/libdev}
\item Either

\begin{enumerate}
\item add the new device to \texttt{/path/to/sdcc/device/lib/pic16/libio/{*}.ignore}
to suppress building any of the I/O libraries for the new device\footnote{In fact, the \texttt{.ignore} files are only used when auto-generating
\texttt{Makefile.am} using the \texttt{.../libio/mkmk.sh} script.}, or
\item add the device (family) to \texttt{/path/to/sdcc/support/scripts/pic18fam-h-gen.pl}
to assign I/O styles, run the \texttt{pic18fam-h-gen.pl} script to
generate \texttt{pic18fam.h.gen}, replace your existing \texttt{pic18fam.h}
with the generated file, and (if required) implement new I/O styles
in \texttt{/path/to/sdcc/device/include/pic16/\{adc,i2c,usart\}.h}
and \texttt{/path/to/sdcc/device/lib/pic16/libio/{*}/{*}.}
\end{enumerate}
\item Edit \texttt{/path/to/sdcc/device/include/pic16/pic18fregs.h}\\
The file format is self-explanatory, just add\\
\texttt{\#elif defined(picDEVICE)}~\\
\texttt{\#\ \ include <picDEVICE.h>}\\
at the right place (keep the file sorted, please).
\item Edit \texttt{/path/to/sdcc/device/include/pic16devices.txt}~\\
Copy and modify an existing entry or create a new one and insert it
at the correct place (keep the file sorted, please).
\item \texttt{( cd /path/to/sdcc/device/non-free/lib/pic16 \&\& sh update.sh
)}
\item Recompile the pic16 libraries as described in \ref{subsec:pic16Libraries}
or just configure and build sdcc again from scratch (recommended).
\end{enumerate}

\subsection{Memory Models}

The following memory models are supported by the PIC16 port:
\begin{itemize}
\item small model
\item large model
\end{itemize}
Memory model affects the default size of pointers within the source.
The sizes are shown in the next table:

\begin{center}
\begin{tabular}{|c||c|c|}
\hline 
Pointer sizes according to memory model & small model & large model\tabularnewline
\hline 
\hline 
code pointers & \multicolumn{1}{c|}{16-bits} & 24-bits\tabularnewline
\hline 
data pointers & \multicolumn{1}{c|}{16-bits} & 16-bits\tabularnewline
\hline 
\end{tabular}
\par\end{center}

It is advisable that all sources within a project are compiled with
the same memory model. If one wants to override the default memory
model, this can be done by declaring a pointer as \textbf{far} or
\textbf{near}. Far selects large memory model's pointers, while near
selects small memory model's pointers.

The standard device libraries (see \ref{subsec:PIC16_Header-Files})
contain no reference to pointers, so they can be used with both memory
models.

\subsection{Stack}

The stack\index{PIC16!stack} implementation for the PIC16 port uses
two indirect registers, FSR1 and FSR2.
\begin{description}
\item [{FSR1}] is assigned as stack pointer
\item [{FSR2}] is assigned as frame pointer
\end{description}
The following stack models are supported by the PIC16 port
\begin{itemize}
\item \noun{small} model
\item \noun{large} model
\end{itemize}
\noun{Small} model means that only the FSRxL byte is used to access
stack and frame, while \emph{\noun{large}} uses both FSRxL and FSRxH
registers. The following table shows the stack/frame pointers sizes
according to stack model and the maximum space they can address:

\begin{center}
\begin{tabular}{|c||c|c|}
\hline 
Stack \& Frame pointer sizes according to stack model & small & large\tabularnewline
\hline 
\hline 
Stack pointer FSR1 & 8-bits & 16-bits\tabularnewline
\hline 
Frame pointer FSR2 & 8-bits & 16-bits\tabularnewline
\hline 
\end{tabular}
\par\end{center}

\noindent\noun{Large }stack model is currently not working properly
throughout the code generator. So its use is not advised. Also there
are some other points that need special care:
\begin{enumerate}
\item Do not create stack sections with size more than one physical bank
(that is 256 bytes)
\item Stack sections should no cross physical bank limits (i.e. \#pragma
stack 0x50 0x100)
\end{enumerate}
These limitations are caused by the fact that only FSRxL is modified
when using SMALL stack model, so no more than 256 bytes of stack can
be used. This problem will disappear after LARGE model is fully implemented.

\subsection{Functions}

In addition to the standard SDCC function keywords, PIC16\index{PIC16}
port makes available two more:
\begin{description}
\item [{\_\_wparam\index{PIC16!wparam}}] Use the WREG to pass one byte
of the first function argument. This improves speed but you may not
use this for functions with arguments that are called via function
pointers, otherwise the first byte of the first parameter will get
lost. Usage:
\end{description}
\begin{lyxcode}
void~func\_wparam(int~a)~\_\_wparam

\{

~~~~/{*}~WREG~hold~the~lower~part~of~a~{*}/

~~~~/{*}~the~high~part~of~a~is~stored~in~FSR2+2~(or~+3~for~large~stack~model)~{*}/

...

\}
\end{lyxcode}
\begin{description}
\item [{\_\_shadowregs\index{PIC16!shadowregs}}] When entering/exiting
an ISR, it is possible to take advantage of the PIC18F hardware shadow
registers which hold the values of WREG, STATUS and BSR registers.
This can be done by adding the keyword \emph{\_\_shadowregs} before
the \emph{\_\_interrupt} keyword in the function's header.
\end{description}
\begin{lyxcode}
void~isr\_shadow(void)~\_\_shadowregs~\_\_interrupt~(1)

\{

...

\}
\end{lyxcode}
\emph{\_\_shadowregs} instructs the code generator not to store/restore
WREG, STATUS, BSR when entering/exiting the ISR.

\subsection{Function return values}

Return values from functions are placed to the appropriate registers
following a modified Microchip policy optimized for SDCC. The following
table shows these registers:

\begin{center}
\begin{tabular}{|c|c|}
\hline 
size & destination register\tabularnewline
\hline 
\hline 
8 bits & WREG\tabularnewline
\hline 
16 bits & PRODL:WREG\tabularnewline
\hline 
24 bits & PRODH:PRODL:WREG\tabularnewline
\hline 
32 bits & FSR0L:PRODH:PRODL:WREG\tabularnewline
\hline 
>32 bits & on stack, FSR0 points to the beginning\tabularnewline
\hline 
\end{tabular}
\par\end{center}

\subsection{Interrupts}

An interrupt\index{PIC16!interrupt} service routine (ISR) is declared
using the \emph{\_\_interrupt} keyword.
\begin{lyxcode}
void~isr(void)~\_\_interrupt~\emph{(n)}

\{

...

\}
\end{lyxcode}
\emph{n} is the interrupt number, which for PIC18F devices can be:

\begin{center}
\begin{tabular}{|c|c|c|}
\hline 
\emph{n} & Interrupt Vector & Interrupt Vector Address\tabularnewline
\hline 
\hline 
0 & RESET vector & 0x000000\tabularnewline
\hline 
1 & HIGH priority interrupts & 0x000008\tabularnewline
\hline 
2 & LOW priority interrupts & 0x000018\tabularnewline
\hline 
\end{tabular}
\par\end{center}

When generating assembly code for ISR the code generator places a
\noun{goto }instruction at the \emph{Interrupt Vector Address} which
points at the generated ISR. This single GOTO instruction is part
of an automatically generated \emph{interrupt entry point} function.
The actual ISR code is placed as normally would in the code space.
Upon interrupt request, the GOTO instruction is executed which jumps
to the ISR code. When declaring interrupt functions as \_naked this
GOTO instruction is \textbf{not} generated. The whole interrupt functions
is therefore placed at the Interrupt Vector Address of the specific
interrupt. This is not a problem for the LOW priority interrupts,
but it is a problem for the RESET and the HIGH priority interrupts
because code may be written at the next interrupt's vector address
and cause indeterminate program behaviour if that interrupt is raised.\footnote{This is not a problem when
\begin{enumerate}
\item this is a HIGH interrupt ISR and LOW interrupts are \emph{disabled}
or not used.
\item when the ISR is small enough not to reach the next interrupt's vector
address.
\end{enumerate}
}

\emph{n} may be omitted. This way a function is generated similar
to an ISR, but it is not assigned to any interrupt.

When entering an interrupt, currently the PIC16\index{PIC16} port
automatically saves the following registers:
\begin{itemize}
\item WREG
\item STATUS
\item BSR
\item PROD (PRODL and PRODH)
\item FSR0 (FSR0L and FSR0H)
\end{itemize}
These registers are restored upon return from the interrupt routine.\footnote{NOTE that when the \_naked attribute is specified for an interrupt
routine, then NO registers are stored or restored.}

\subsection{Generic Pointers}

Generic pointers are implemented in PIC16 port as 3-byte (24-bit)
types. There are 3 types of generic pointers currently implemented
data, code and eeprom pointers. They are differentiated by the value
of the 7th and 6th bits of the upper byte:

\begin{center}
\begin{tabular}{|c|c|c|cl|}
\hline 
pointer type & 7th bit & 6th bit & rest of the pointer & description\tabularnewline
\hline 
\hline 
data  & 1 & 0 & \texttt{\textsl{\emph{uuuuuu uuuuxxxx xxxxxxxx}}} & a 12-bit data pointer in data RAM memory\tabularnewline
\hline 
code & 0 & 0 & \texttt{\textsl{\emph{uxxxxx xxxxxxxx xxxxxxxx}}} & a 21-bit code pointer in FLASH memory\tabularnewline
\hline 
eeprom & 0 & 1 & \texttt{\textsl{\emph{uuuuuu uuuuuuxx xxxxxxxx}}} & a 10-bit eeprom pointer in EEPROM memory\tabularnewline
\hline 
(unimplemented) & 1 & 1 & \texttt{\textsl{\emph{xxxxxx xxxxxxxx xxxxxxxx}}} & unimplemented pointer type\tabularnewline
\hline 
\end{tabular}
\par\end{center}

\noindent Generic pointer are read and written with a set of library
functions which read/write 1, 2, 3, 4 bytes.

\subsection{Configuration Bits}

Configuration bits (also known as fuses) can be configured using one
of two methods:
\begin{itemize}
\item using \#pragma config (see section \ref{subsec:PIC16_Pragmas}), which
is a preferred method for the new code. Example:
\end{itemize}
\begin{lyxcode}
\#pragma~config~CP0=OFF,OSCS=ON,OSC=LP,BOR=ON,BORV=25,WDT=ON,WDTPS=128,CCP2MUX=ON

\#pragma~config~STVR=ON
\end{lyxcode}
\begin{itemize}
\item using `\texttt{\_\_code}' and `\texttt{\_\_at}' modifiers. This method
is deprecated. Possible options should be ANDed and can be found in
your processor header file. Example for PIC18F2550:
\end{itemize}
\begin{lyxcode}
\#include~<pic18fregs.h>~//Contains~config~addresses~and~options~\\
~\\
static~\_\_code~char~\_\_at(\_\_CONFIG1L)~configword1l~=~\\
~~\_USBPLL\_CLOCK\_SRC\_FROM\_96MHZ\_PLL\_2\_1L~\&

~~\_PLLDIV\_NO\_DIVIDE\_\_4MHZ\_INPUT\_\_1L~\&~{[}...{]};~\\
static~\_\_code~char~\_\_at(\_\_CONFIG1H)~configword1h~=~{[}...{]};~\\
static~\_\_code~char~\_\_at(\_\_CONFIG2L)~configword2l~=~{[}...{]};~\\
//More~configuration~words
\end{lyxcode}
Mixing both methods is not allowed and throws an error message ''mixing
\_\_CONFIG and CONFIG directives''.

\subsection{PIC16 C Libraries}

\subsubsection{Standard I/O Streams}

In the \emph{stdio.h} the type FILE is defined as:
\begin{lyxcode}
typedef~char~{*}~FILE;
\end{lyxcode}
This type is the stream type implemented I/O in the PIC18F devices.
Also the standard input and output streams are declared in stdio.h:
\begin{lyxcode}
extern~FILE~{*}~stdin;

extern~FILE~{*}~stdout;
\end{lyxcode}
The FILE type is actually a generic pointer which defines one more
type of generic pointers, the \emph{stream} pointer. This new type
has the format:

\begin{center}
\begin{tabular}{|c|c|c|c|c|cl|}
\hline 
pointer type & <7:6> & <5> & <4> & <3:0> & rest of the pointer & descrption\tabularnewline
\hline 
\hline 
stream & 00 & 1 & 0 & nnnn & \texttt{\textsl{\emph{uuuuuuuu uuuuuuuu}}} & upper byte high nubble is 0x2n, the rest are zeroes\tabularnewline
\hline 
\end{tabular}
\par\end{center}

\noindent Currently implemented there are 3 types of streams defined:

\begin{center}
\begin{tabular}{|c|c|c|c|}
\hline 
stream type & value & module & description\tabularnewline
\hline 
\hline 
STREAM\_USART & \texttt{0x200000UL} & USART & Writes/Reads characters via the USART peripheral\tabularnewline
\hline 
STREAM\_MSSP & \texttt{0x210000UL} & MSSP & Writes/Reads characters via the MSSP peripheral\tabularnewline
\hline 
STREAM\_USER & \texttt{0x2f0000UL} & (none) & Writes/Reads characters via used defined functions\tabularnewline
\hline 
\end{tabular}
\par\end{center}

\noindent The stream identifiers are declared as macros in the stdio.h
header.

\noindent In the libc library there exist the functions that are used
to write to each of the above streams. These are
\begin{description}
\item [{\_\/\_stream\_usart\_putchar}] writes a character at the USART
stream
\item [{\_\/\_stream\_mssp\_putchar}] writes a character at the MSSP stream
\item [{putchar}] dummy function. This writes a character to a user specified
manner.
\end{description}
In order to increase performance \emph{putchar} is declared in stdio.h
as having its parameter in WREG (it has the \emph{\_\_wparam} keyword).
In stdio.h exists the macro PUTCHAR(arg) that defines the putchar
function in a user-friendly way. \emph{arg} is the name of the variable
that holds the character to print. An example follows:
\begin{lyxcode}
\#include~<pic18fregs.h>~\\
\#include~<stdio.h>~\\
~\\
PUTCHAR(~c~)

\{

~~~~PORTA~=~c;~~~~/{*}~dump~character~c~to~PORTA~{*}/

\}~\\
~\\
void~main(void)

\{

~~~~stdout~=~STREAM\_USER;~~~~/{*}~this~is~not~necessary,~since~stdout~points

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{*}~by~default~to~STREAM\_USER~{*}/

~~~~printf~(''This~is~a~printf~test\textbackslash n'');

\}

\end{lyxcode}

\subsubsection{Printing functions}

PIC16 contains an implementation of the printf-family\index{printf()!PIC16}
of functions. There exist the following functions:
\begin{lyxcode}
extern~unsigned~int~sprintf(char~{*}buf,~char~{*}fmt,~...);

extern~unsigned~int~vsprintf(char~{*}buf,~char~{*}fmt,~va\_list~ap);

extern~unsigned~int~printf(char~{*}fmt,~...);

extern~unsigned~int~vprintf(char~{*}fmt,~va\_lista~ap);

extern~unsigned~int~fprintf(FILE~{*}fp,~char~{*}fmt,~...);

extern~unsigned~int~vfprintf(FILE~{*}fp,~char~{*}fmt,~va\_list~ap);
\end{lyxcode}
For sprintf and vsprintf \emph{buf} should normally be a data pointer
where the resulting string will be placed. No range checking is done
so the user should allocate the necessary buffer. For fprintf and
vfprintf \emph{fp} should be a stream pointer (i.e. stdout, STREAM\_MSSP,
etc...).

\subsubsection{Signals}

The PIC18F family of microcontrollers supports a number of interrupt
sources. A list of these interrupts is shown in the following table:

\begin{center}
\begin{tabular}{|l|c||l|c|}
\hline 
signal name & description & signal name & description\tabularnewline
\hline 
\hline 
SIG\_RB & \multicolumn{1}{c||}{PORTB change interrupt} & SIG\_EE & EEPROM/FLASH write complete interrupt\tabularnewline
\hline 
SIG\_INT0 & INT0 external interrupt & SIG\_BCOL & Bus collision interrupt\tabularnewline
\hline 
SIG\_INT1 & INT1 external interrupt & SIG\_LVD & Low voltage detect interrupt\tabularnewline
\hline 
SIG\_INT2 & INT2 external interrupt & SIG\_PSP & Parallel slave port interrupt\tabularnewline
\hline 
SIG\_CCP1 & CCP1 module interrupt & SIG\_AD & AD convertion complete interrupt\tabularnewline
\hline 
SIG\_CCP2 & CCP2 module interrupt & SIG\_RC & USART receive interrupt\tabularnewline
\hline 
SIG\_TMR0 & TMR0 overflow interrupt & SIG\_TX & USART transmit interrupt\tabularnewline
\hline 
SIG\_TMR1 & TMR1 overflow interrupt & SIG\_MSSP & SSP receive/transmit interrupt\tabularnewline
\hline 
SIG\_TMR2 & TMR2 matches PR2 interrupt &  & \tabularnewline
\hline 
SIG\_TMR3 & TMR3 overflow interrupt &  & \tabularnewline
\hline 
\end{tabular}
\par\end{center}

\noindent The prototypes for these names are defined in the header
file \emph{signal.h}.

\noindent In order to simplify signal handling, a number of macros
is provided:
\begin{lyxlist}{00.00.0000}
\item [{DEF\_INTHIGH(name)}] begin the definition of the interrupt dispatch
table for high priority interrupts. \emph{name} is the function name
to use.
\item [{DEF\_INTLOW(name)}] begin the definition of the interrupt dispatch
table for low priority interrupt. \emph{name} is the function name
to use.
\item [{DEF\_HANDLER(sig,handler)}] define a handler for signal \emph{sig.}
\item [{END\_DEF}] end the declaration of the dispatch table.
\end{lyxlist}
Additionally there are two more macros to simplify the declaration
of the signal handler:
\begin{lyxlist}{00.00.0000}
\item [{SIGHANDLER(handler)}] this declares the function prototype for
the \emph{handler} function.
\item [{SIGHANDLERNAKED(handler)}] same as SIGHANDLER() but declares a
naked function.
\end{lyxlist}
An example of using the macros above is shown below:
\begin{lyxcode}
\#include~<pic18fregs.h>

\#include~<signal.h>~\\
~\\
DEF\_INTHIGH(high\_int)

DEF\_HANDLER(SIG\_TMR0,~\_tmr0\_handler)

DEF\_HANDLER(SIG\_BCOL,~\_bcol\_handler)

END\_DEF~\\
~\\
SIGHANDLER(\_tmr0\_handler)

\{

~~/{*}~action~to~be~taken~when~timer~0~overflows~{*}/

\}~\\
~\\
SIGHANDLERNAKED(\_bcol\_handler)

\{

~~\_\_asm

~~~~/{*}~action~to~be~taken~when~bus~collision~occurs~{*}/

~~~~retfie

~\_\_endasm;

\}
\end{lyxcode}
\textbf{NOTES:} Special care should be taken when using the above
scheme:
\begin{itemize}
\item do not place a colon (;) at the end of the DEF\_{*} and END\_DEF macros.
\item when declaring SIGHANDLERNAKED handler never forget to use \emph{retfie}
for proper returning.
\end{itemize}

\subsection{PIC16 Port – Tips}

Here you can find some general tips for compiling programs with SDCC/pic16.

\subsubsection{Stack size}

The default stack\index{PIC16!stack} size (that is 64 bytes) probably
is enough for many programs. One must take care that when there are
many levels of function nesting, or there is excessive usage of stack,
its size should be extended. An example of such a case is the printf/sprintf
family of functions. If you encounter problems like not being able
to print integers, then you need to set the stack size around the
maximum (256 for small stack model). The following diagram shows what
happens when calling printf to print an integer:
\begin{lyxcode}
printf~()~-{}->~ltoa~()~-{}->~ultoa~()~-{}->~divschar~()
\end{lyxcode}
It is should be understood that stack is easily consumed when calling
complicated functions. Using command line arguments like -\/-fomit-frame-pointer
might reduce stack usage by not creating unnecessary stack frames.
Other ways to reduce stack usage may exist.

\subsection{Known Bugs}

\subsubsection{Extended Instruction Set}

The PIC16 port emits code which is incompatible with the extended
instruction set available with many newer devices. Make sure to always
explicitly disable it, usually using:
\begin{itemize}
\item \texttt{\#pragma config XINST=OFF}
\end{itemize}
or deprecated:
\begin{itemize}
\item \texttt{static \_\_code char \_\_at(\_\_CONFIG4L) conf4l = /{*} more
flags \& {*}/ \_XINST\_OFF\_4L;}
\end{itemize}
\noindent Some devices (namely 18f2455, 18f2550, 18f4455, and 18f4550)
use \_ENHCPU\_OFF\_4L instead of \_XINST\_OFF\_4L.

\subsubsection{Regression Tests}

The PIC16 port currently passes most but not all of the tests in SDCC's
regression test\index{Regression test (PIC16)} suite (see section
\ref{sec:Quality-control}), thus no automatic regression tests are
currently performed for the PIC16 target.

\section{The MOS6502 port}

The mos6502\index{MOS6502} port can target the original MOS Technology
NMOS 6502 , and the CMOS Rockwell/WDC 65C02 with enhanched instruction
set. 

\subsection{Startup Code}

On the MOS6502\index{MOS6502} the startup code is inserted by linking
with crt0.rel which is generated from sdcc/device/lib/mos6502/crt0.s.
If you need a different startup code you can use the compiler option
\emph{-}\textbf{\/}\emph{-no-std-crt0}\index{-/-no-std-crt0@-\/-no-std-crt0}
and provide your own crt0.rel. When using a custom crt0.rel it needs
to be listed first when linking.

\subsection{Hooking up interrupts}

ISR can be written in C using SDCC. However, to hook interrupts is
necessary to customize crt0.asm and have the interrupt vectors point
to the C functions.

\subsection{Reentrancy}

Due to the very limited stack space, the MOS6502 port by default generates
non-reentrant code. Re-entrant functions should be declared using
the \_\_reentrant keyword. Alternatively the entire program can be
compiled using –stack-auto. On the MOS6502 re-entrant code is, in
general, much less efficient.

\subsection{Code and Data placement}

The compiler can pass segment location to the linker. On the MOS6502
the following switches are supported:

–code-loc: start address of the code segment

–data-loc: start address of the zero page

–xram-loc: start address of the data segment

\chapter{Debugging}

There are several approaches to debugging your code. This chapter
is meant to show your options and to give detail on some of them:\\
\\
When writing your code:
\begin{itemize}
\item write your code with debugging in mind (avoid duplicating code, put
conceptually similar variables into structs, use structured code,
have strategic points within your code where all variables are consistent,
...)
\item run a syntax-checking tool like splint\index{splint (syntax checking tool)}\index{lint (syntax checking tool)}
(see -\/-more-pedantic \ref{lyx:more-pedantic-SPLINT}) over the
code.
\item for the high level code use a C-compiler (like f.e. GCC) to compile
run and debug the code on your host. See (see -\/-more-pedantic \ref{lyx:more-pedantic-SPLINT})
on how to handle syntax extensions like \_\_xdata, \_\_at(), ... 
\item use another C-compiler to compile code for your target. Always an
option but not recommended:) And not very likely to help you. If you
seriously consider walking this path you should at least occasionally
check portability of your code. Most commercial compiler vendors will
offer an evaluation version so you can test compile your code or snippets
of your code.
\end{itemize}
Debugging on a simulator:
\begin{itemize}
\item there is a separate section about SDCDB (section \ref{cha:Debugging-with-SDCDB})
below.
\item or (8051 specific) use a free open source/commercial simulator which
interfaces to the AOMF\index{AOMF, AOMF51} file (see \ref{OMF file})
optionally generated by SDCC.
\end{itemize}
Debugging On-target: 
\begin{itemize}
\item use a MCU port pin to serially output debug data to the RS232 port
of your host. You'll probably want some level shifting device typically
involving a MAX232 or similar IC. If the hardware serial port of the
MCU is not available search for 'Software UART' in your favourite
search machine.
\item use an on-target monitor. In this context a monitor is a small program
which usually accepts commands via a serial line and allows to set
program counter, to single step through a program and read/write memory
locations. For the 8051 good examples of monitors are paulmon and
cmon51 (see section \ref{sec:Related-open-source-tools}).
\item toggle MCU port pins at strategic points within your code and use
an oscilloscope. A \emph{digital oscilloscope}\index{Oscilloscope}
with deep trace memory is really helpful especially if you have to
debug a realtime application. If you need to monitor more pins than
your oscilloscope provides you can sometimes get away with a small
R-2R network. On a single channel oscilloscope you could for example
monitor 2 push-pull driven pins by connecting one via a 10~k$\Omega$
resistor and the other one by a 5~k$\Omega$ resistor to the oscilloscope
probe (check output drive capability of the pins you want to monitor).
If you need to monitor many more pins a \emph{logic analyzer} will
be handy.
\item use an ICE (\emph{i}n \emph{c}ircuit \emph{e}mulator\index{ICE (in circuit emulator)}).
Usually very expensive. And very nice to have too. And usually locks
you (for years...) to the devices the ICE can emulate. 
\item use a remote debugger. In most 8-bit systems the symbol information
is not available on the target, and a complete debugger is too bulky
for the target system. Therefore usually a debugger on the host system
connects to an on-target debugging stub which accepts only primitive
commands. \\
Terms to enter into your favourite search engine could be 'remote
debugging', 'gdb stub' or 'inferior debugger'. (is there one?)
\item use an on target hardware debugger. Some of the more modern MCUs include
hardware support for setting break points and monitoring/changing
variables by using dedicated hardware pins. This facility doesn't
require additional code to run on the target and \emph{usually} doesn't
affect runtime behaviour until a breakpoint is hit. For the mcs51
most hardware debuggers use the AOMF\index{AOMF, AOMF51} file (see
\ref{OMF file}) as input file. 
\end{itemize}
Last not least:
\begin{itemize}
\item if you are not familiar with any of the following terms you're likely
to run into problems rather sooner than later: \emph{volatile}, \emph{atomic},
\emph{memory map}, \emph{overlay}. As an embedded programmer you \emph{have}
to know them so why not look them up \emph{before} you have problems?)
\item tell someone else about your problem (actually this is a surprisingly
effective means to hunt down the bug even if the listener is not familiar
with your environment). As 'failure to communicate' is probably one
of the job-induced deformations of an embedded programmer this is
highly encouraged.
\end{itemize}

\section{Debugging with SDCDB\label{cha:Debugging-with-SDCDB}\index{SDCDB (debugger)} }

SDCC is distributed with a source level debugger\index{Debugger}.
The debugger uses a command line interface, the command repertoire
of the debugger has been kept as close to gdb\index{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 during configuration.
The debugger allows you debug BOTH at the C source and at the ASM
source level.

\subsection{Compiling for Debugging}

The -\/-debug\index{-/-debug@-\/-debug} option must be specified
for all files for which debug information is to be generated. The
compiler generates a .adb file for each of these files. The linker
creates the .cdb\index{<file>.cdb} file from the .adb\index{<file>.adb}
files and the address information. This .cdb is used by the debugger.

\subsection{How the Debugger Works}

When the -\/-debug option is specified the compiler generates extra
symbol information some of which are put into the assembler source
and some are put into the .adb file. Then the linker creates the .cdb
file from the individual .adb files with the address information for
the symbols. The debugger reads the symbolic information generated
by the compiler \& the address information generated by the linker.
It uses the SIMULATOR (Daniel's S51) to execute the program, the program
execution is controlled by the debugger. When a command is issued
for the debugger, it translates it into appropriate commands for the
simulator. (Currently SDCDM only connects to the simulator but \emph{newcdb}
at \url{http://ec2drv.sourceforge.net/} is an effort to connect directly
to the hardware.) 

\subsection{Starting the Debugger SDCDB}

The debugger can be started using the following command line. (Assume
the file you are debugging has the file name foo).\\
\\
\textsf{\textbf{sdcdb foo}}\\
\\
The debugger will look for the following files.
\begin{itemize}
\item foo.c - the source file.
\item foo.cdb - the debugger symbol information file.
\item foo.ihx - the Intel hex format\index{Intel hex format} object file.
\end{itemize}

\subsection{SDCDB Command Line Options}
\begin{itemize}
\item -\/-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 \& ihx files. The items in the directory
list must be separated 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. 
\item -cd <directory> - change to the <directory>.
\item -fullname - used by GUI front ends.
\item -cpu <cpu-type> - this argument is passed to the simulator please
see the simulator docs for details.
\item -X <Clock frequency > this options is passed to the simulator please
see the simulator docs for details.
\item -s <serial port file> passed to simulator see the simulator docs for
details.
\item -S <serial in,out> passed to simulator see the simulator docs for
details.
\item -k <port number> passed to simulator see the simulator docs for details.
\end{itemize}

\subsection{SDCDB Debugger Commands}

As mentioned earlier the command interface for the debugger has been
deliberately kept as close the GNU debugger gdb, as possible. This
will help the integration with existing graphical user interfaces
(like ddd, xxgdb or xemacs) existing for the GNU debugger. If you
use a graphical user interface for the debugger you can skip this
section.

\subsubsection*{break {[}line | file:line | function | file:function{]}}

Set breakpoint at specified line or function:\\
\\
\textsf{\textbf{sdcdb>break 100 }}\\
\textsf{\textbf{sdcdb>break foo.c:100}}\\
\textsf{\textbf{sdcdb>break funcfoo}}\\
\textsf{\textbf{sdcdb>break foo.c:funcfoo}}

\subsubsection*{clear {[}line | file:line | function | file:function {]}}

Clear breakpoint at specified line or function:\\
\\
\textsf{\textbf{sdcdb>clear 100}}\\
\textsf{\textbf{sdcdb>clear foo.c:100}}\\
\textsf{\textbf{sdcdb>clear funcfoo}}\\
\textsf{\textbf{sdcdb>clear foo.c:funcfoo}}

\subsubsection*{continue}

Continue program being debugged, after breakpoint.

\subsubsection*{finish}

Execute till the end of the current function.

\subsubsection*{delete {[}n{]}}

Delete breakpoint number 'n'. If used without any option clear ALL
user defined break points.

\subsubsection*{info {[}break | stack | frame | registers {]}}
\begin{itemize}
\item info break - list all breakpoints
\item info stack - show the function call stack.
\item info frame - show information about the current execution frame.
\item info registers - show content of all registers.
\end{itemize}

\subsubsection*{step}

Step program until it reaches a different source line. Note: pressing
<return> repeats the last command.

\subsubsection*{next}

Step program, proceeding through subroutine calls.

\subsubsection*{run}

Start debugged program.

\subsubsection*{ptype variable }

Print type information of the variable.

\subsubsection*{print variable}

print value of variable.

\subsubsection*{file filename}

load the given file name. Note this is an alternate method of loading
file for debugging.

\subsubsection*{frame}

print information about current frame.

\subsubsection*{set srcmode}

Toggle between C source \& assembly source.

\subsubsection*{! simulator command}

Send the string following '!' to the simulator, the simulator response
is displayed. Note the debugger does not interpret the command being
sent to the simulator, so if a command like 'go' is sent the debugger
can loose its execution context and may display incorrect values.

\subsubsection*{quit}

\textquotedbl Watch me now. Iam going Down. My name is Bobby Brown\textquotedbl{}

\subsection{Interfacing SDCDB with DDD}

The \emph{p}ortable \emph{n}etwork \emph{g}raphics File {\footnotesize\url{http://sdcc.sourceforge.net/wiki_images/ddd_example.png}}
shows a screenshot of a debugging session with DDD\index{DDD (debugger)}
(Unix only) on a simulated 8032. The debugging session might not run
as smoothly as the screenshot suggests. The debugger allows setting
of breakpoints, displaying and changing variables, single stepping
through C and assembler code. \\
The source was compiled with \textsf{\textbf{}}\\
\textsf{\textbf{}}\\
\textsf{\textbf{sdcc -}}\/\textsf{\textbf{-debug ddd\_example.c}}
\textsf{\textbf{}}\\
\\
and DDD was invoked with \textsf{\textbf{}}\\
\textsf{\textbf{}}\\
\textsf{\textbf{ddd -debugger \textquotedbl sdcdb -cpu 8032 ddd\_example\textquotedbl}}


\subsection{Interfacing SDCDB with XEmacs\index{XEmacs}\index{Emacs}}

Two files (in emacs lisp) are provided for the interfacing with XEmacs,
sdcdb.el and sdcdbsrc.el. These two files can be found in the \$(prefix)/bin
directory after the installation is complete. These files need to
be loaded into XEmacs for the interface to work. This can be done
at XEmacs startup time by inserting the following into your '.xemacs'
file (which can be found in your HOME directory): \\
\\
\texttt{(load-file sdcdbsrc.el)}\\
\\
.xemacs is a lisp file so the () around the command is REQUIRED. The
files can also be loaded dynamically while XEmacs is running, set
the environment variable 'EMACSLOADPATH' to the installation bin directory
(<installdir>/bin), then enter the following command ESC-x load-file
sdcdbsrc. To start the interface enter the following command:\\
\\
\textsf{\textbf{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. The variables
are listed below, these values maybe changed as required.
\begin{itemize}
\item sdcdbsrc-cpu-type '51
\item sdcdbsrc-frequency '11059200
\item sdcdbsrc-serial nil
\end{itemize}
The following is a list of key mapping for the debugger interface.

~\texttt{}~\\
\texttt{;;~Current Listing ::}~\\
\texttt{;;key~~~~~~~~~~~~~~binding~~~~~~~~~~~~~~~~~~~~~~Comment}~\\
\texttt{;;-{}-{}-~~~~~~~~~~~~~~-{}-{}-{}-{}-{}-{}-~~~~~~~~~~~~~~~~~~~~~~-{}-{}-{}-{}-{}-{}-}~\\
\texttt{;; }~\\
\texttt{;;~n~~~~~~~~~~~~~~~sdcdb-next-from-src~~~~~~~~~~SDCDB
next command}~\\
\texttt{;;~b~~~~~~~~~~~~~~~sdcdb-back-from-src~~~~~~~~~~SDCDB
back command}~\\
\texttt{;;~c~~~~~~~~~~~~~~~sdcdb-cont-from-src~~~~~~~~~~SDCDB
continue command}~\\
\texttt{;;~s~~~~~~~~~~~~~~~sdcdb-step-from-src~~~~~~~~~~SDCDB
step command}~\\
\texttt{;;~?~~~~~~~~~~~~~~~sdcdb-whatis-c-sexp~~~~~~~~~~SDCDB
ptypecommand for data at}~\\
\texttt{;;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~buffer
point}~\\
\texttt{;;~x~~~~~~~~~~~~~~~sdcdbsrc-delete~~~~~~~~~~~~~~SDCDB
Delete all breakpoints if no arg}~\\
\texttt{;;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~given
or delete arg (C-u arg x)}~\\
\texttt{;;~m~~~~~~~~~~~~~~~sdcdbsrc-frame~~~~~~~~~~~~~~~SDCDB
Display current frame if no arg,}~\\
\texttt{;;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~given
or display frame arg}~\\
\texttt{;;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~buffer
point}~\\
\texttt{;;~!~~~~~~~~~~~~~~~sdcdbsrc-goto-sdcdb~~~~~~~~~~Goto
the SDCDB output buffer}~\\
\texttt{;;~p~~~~~~~~~~~~~~~sdcdb-print-c-sexp~~~~~~~~~~~SDCDB
print command for data at}~\\
\texttt{;;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~buffer
point}~\\
\texttt{;;~g~~~~~~~~~~~~~~~sdcdbsrc-goto-sdcdb~~~~~~~~~~Goto
the SDCDB output buffer}~\\
\texttt{;;~t~~~~~~~~~~~~~~~sdcdbsrc-mode~~~~~~~~~~~~~~~~Toggles
Sdcdbsrc mode (turns it off)}~\\
\texttt{;;}~\\
\texttt{;;~C-c~C-f~~~~~~~~~sdcdb-finish-from-src~~~~~~~~SDCDB
finish command}~\\
\texttt{;;}~\\
\texttt{;;~C-x~SPC~~~~~~~~~sdcdb-break~~~~~~~~~~~~~~~~~~Set
break for line with point}~\\
\texttt{;;~ESC~t~~~~~~~~~~~sdcdbsrc-mode~~~~~~~~~~~~~~~~Toggle
Sdcdbsrc mode}~\\
\texttt{;;~ESC~m~~~~~~~~~~~sdcdbsrc-srcmode~~~~~~~~~~~~~Toggle
list mode}~\\
\texttt{;;}

\section{Debugging with other debuggers (e.g. GDB): ELF / DWARF}

For some ports, SDCC can create ELF binaries with DWARF debug information.
This can e.g. be used for on-target debugging on STM8 using OpenOCD
and GDB. To do so, compile with –debug –out-fmt-elf. Note that –out-fmt-elf
needs to be specified both when compiling (to generate the debug info
in DWARF rather than CDB format) and linking (to get an ELF binary
instead of Intel Hex).

\chapter{TIPS}

Here are a few guidelines that will help the compiler generate more
efficient code, some of the tips are specific to this compiler others
are generally good programming practice.
\begin{itemize}
\item Use the smallest data type to represent your data-value. If it is
known in advance that the value is going to be less than 256 then
use an 'unsigned char' instead of a 'short' or 'int'. Please note,
that ANSI C requires both signed and unsigned chars to be promoted
to 'signed int'\index{promotion to signed int}\marginpar{\textbf{~!}}
before doing any operation. This promotion\index{type promotion}\label{type promotion}
can be omitted, if the result is the same. The effect of the promotion
rules together with the sign-extension is often surprising:

\begin{verse}
\texttt{unsigned char uc = 0xfe;}~\\
\texttt{if (uc {*} uc < 0) /{*} this is true! {*}/}~\\
\texttt{\{}~\\
\texttt{~~~~....}~\\
\texttt{\}}
\end{verse}
\texttt{uc {*} uc} is evaluated as \texttt{(int) uc {*} (int) uc =
(int) 0xfe {*} (int) 0xfe = (int) 0xfc04 = -1024}.\\
Another one:
\begin{verse}
\texttt{(unsigned char) -12 / (signed char) -3 = ...}
\end{verse}
No, the result is not 4:
\begin{verse}
\texttt{(int) (unsigned char) -12 / (int) (signed char) -3 =}~\\
\texttt{(int) (unsigned char) 0xf4 / (int) (signed char) 0xfd =}~\\
\texttt{(int) 0x00f4 / (int) 0xfffd =}~\\
\texttt{(int) 0x00f4 / (int) 0xfffd =}~\\
\texttt{(int) 244 / (int) -3 =}~\\
\texttt{(int) -81 = (int) 0xffaf;}
\end{verse}
Don't complain, that gcc gives you a different result. gcc uses 32
bit ints, while SDCC uses 16 bit ints. Therefore the results are different.\\
From ''comp.lang.c FAQ'':
\begin{quote}
\emph{If well-defined overflow characteristics are important and negative
values are not, or if you want to steer clear of sign-extension problems
when manipulating bits or bytes, use one of the corresponding unsigned
types. (Beware when mixing signed and unsigned values in expressions,
though.)}\\
\emph{Although character types (especially unsigned char) can be used
as \textquotedbl tiny\textquotedbl{} integers, doing so is sometimes
more trouble than it's worth, due to unpredictable sign extension
and increased code size.}
\end{quote}
\item Use unsigned when it is known in advance that the value is not going
to be negative. This helps especially if you are doing division or
multiplication, bit-shifting or are using an array index.
\item NEVER jump into a LOOP.
\item Declare the variables to be local\index{local variables} whenever
possible, especially loop control variables (induction).
\item Have a look at the assembly listing to get a ''feeling'' for the
code generation.
\end{itemize}

\section{Porting code from or to other compilers\label{sec:Porting-code-to-other-compilers}}
\begin{itemize}
\item check whether endianness\index{Endianness} of the compilers differs
and adapt where needed.
\item check the device specific header files\index{Header files}\index{Include files}
for compiler specific syntax. Eventually include the file <compiler.h\index{compiler.h (include file)}>
\url{http://svn.code.sf.net/p/sdcc/code/trunk/sdcc/device/include/mcs51/compiler.h}
to allow using common header files. (see f.e. cc2510fx.h \url{http://svn.code.sf.net/p/sdcc/code/trunk/sdcc/device/include/mcs51/cc2510fx.h}).
\item check whether the startup code contains the correct initialization
(watchdog\index{watchdog}, peripherals).
\item check whether the sizes of short, int, long match.
\item check if some 16 or 32 bit hardware registers require a specific addressing
order (least significant or most significant byte first) and adapt
if needed (\emph{first} and \emph{last} relate to time and not to
lower/upper memory location here, so this is \emph{not} the same as
endianness).
\item check whether the keyword \emph{volatile\index{volatile}} is used
where needed. The compilers might differ in their optimization characteristics
(as different versions of the same compiler might also use more clever
optimizations this is good idea anyway). See section \ref{subsec:Common-interrupt-pitfall-volatile}.
\item check that the compilers are not told to suppress warnings.
\item check and convert compiler specific extensions (interrupts, memory
areas, pragmas etc.).
\item check for differences in type promotion. Especially check for math
operations on \texttt{char} or \texttt{unsigned char} variables. For
the sake of C99 compatibility SDCC will probably promote these to
\texttt{int} more often than other compilers. Eventually insert explicit
casts to \texttt{(char)} or \texttt{(unsigned char)}. Also check that
the \textasciitilde ~operator\index{ Operator@\textasciitilde{} Operator}
is not used on \texttt{bit\index{bit}} variables, use the !~operator
instead. See sections \ref{type promotion} and \ref{sec:Compatibility-with-previous}.
\item check the assembly code generated for interrupt routines (f.e. for
calls to possibly non-reentrant library functions).
\item check whether timing loops result in proper timing (or preferably
consider a rewrite of the code with timer based delays instead).
\item check for differences in printf parameters\index{printf()!parameters}
(some compilers push (va\_arg\index{vararg, va_arg@vararg, va\_arg})
char variables as \texttt{int} others push them as \texttt{char}.
See section \ref{sec:Compatibility-with-previous}). Provide a putchar()\index{printf()!putchar()}
function if needed.
\item check the resulting memory map\index{Memory map}. Usage of different
memory spaces: code, stack, data (for mcs51/ds390 additionally idata,
pdata, xdata). Eventually check if unexpected library functions are
included.
\end{itemize}

\section{Tools\index{Tools} included in the distribution}
\begin{flushleft}
\begin{tabular}{|l|l|l|}
\hline 
\textbf{Name} & \textbf{Purpose} & \textbf{Directory}\tabularnewline
\hline 
\hline 
as2gbmap.py & sdas map to rrgb map and no\$gmb sym file format converter & sdcc/support/scripts\tabularnewline
\hline 
cinc2h.pl & gpasm inc to c header file converter & sdcc/support/scripts\tabularnewline
\hline 
gen\_known\_bugs.pl & generate knownbugs.html & sdcc/support/scripts\tabularnewline
\hline 
keil2sdcc.pl & Keil header \index{Header files}\index{Include files} to SDCC header
file converter & sdcc/support/scripts\tabularnewline
\hline 
makebin & Intel Hex to binary and GameBoy binay format converter & sdcc/bin\tabularnewline
\hline 
mcs51-disasm.pl & disassembler to the mcs51 instructions contained hex files & sdcc/support/scripts\tabularnewline
\hline 
mh2h.c & header file conversion & sdcc/support/scripts\tabularnewline
\hline 
optimize\_pic16devices.pl & optimizes or unoptimizes the pic16devices.txt file & sdcc/support/scripts\tabularnewline
\hline 
packihx & Intel Hex packer \index{packihx (tool)} & sdcc/bin\tabularnewline
\hline 
pic14-header-parser.pl & helper to realization of peripheral-handling (PIC14) & sdcc/support/scripts\tabularnewline
\hline 
pic16-header-parser.pl & helper to realization of peripheral-handling (PIC16) & sdcc/support/scripts\tabularnewline
\hline 
pic16fam-h-gen.pl & helper to realization of peripheral-handling (PIC14) & sdcc/support/scripts\tabularnewline
\hline 
pic18fam-h-gen.pl & helper to realization of peripheral-handling (PIC16) & sdcc/support/scripts\tabularnewline
\hline 
repack\_release.sh & repack sdcc to release package & sdcc/support/scripts\tabularnewline
\hline 
sdas390 & assembler & sdcc/bin\tabularnewline
\hline 
sdas6808 & assembler & sdcc/bin\tabularnewline
\hline 
sdas6500 & assembler & sdcc/bin\tabularnewline
\hline 
sdas8051 & assembler & sdcc/bin\tabularnewline
\hline 
sdasgb & assembler & sdcc/bin\tabularnewline
\hline 
sdasz80 & assembler & sdcc/bin\tabularnewline
\hline 
sdcc\_cygwin\_mingw32 & cross compile the sdcc with mingw32 under Cygwin & sdcc/support/scripts\tabularnewline
\hline 
sdcc\_mingw32 & cross compile the sdcc with mingw32 & sdcc/support/scripts\tabularnewline
\hline 
SDCDB & simulator & sdcc/bin\tabularnewline
\hline 
sdld & linker & sdcc/bin\tabularnewline
\hline 
sdld6808 & linker & sdcc/bin\tabularnewline
\hline 
sdldgb & linker & sdcc/bin\tabularnewline
\hline 
sdldz80 & linker & sdcc/bin\tabularnewline
\hline 
uCsim\index{uCsim} & simulator for various architectures & sdcc/sim/ucsim\tabularnewline
\hline 
\end{tabular}
\par\end{flushleft}

\section{Documentation\index{Documentation} included in the distribution}
\begin{flushleft}
\begin{tabular}{|p{0.4\columnwidth}|p{0.6\columnwidth}|}
\hline 
\textbf{Subject / Title} & \textbf{Filename / Where to get}\tabularnewline
\hline 
\hline 
SDCC Compiler User Guide & You're reading it right now \emph{~~~\hfill{}online at:}\newline
\url{http://sdcc.sourceforge.net/doc/sdccman.pdf}\tabularnewline
\hline 
Changelog of SDCC & sdcc/Changelog \emph{~~~\hfill{}online at:}\newline
\url{http://svn.code.sf.net/p/sdcc/code/trunk/sdcc/ChangeLog}\tabularnewline
\hline 
ASXXXX\index{sdas (sdasgb, sdas6808, sdas8051, sdasz80)}\index{Assembler documentation}
Assemblers and\newline
ASLINK\index{sdld}\index{Linker documentation} Relocating Linker & sdcc/sdas/doc/asmlnk.txt \emph{~~~\hfill{}online at:}\newline
\url{http://svn.code.sf.net/p/sdcc/code/trunk/sdcc/sdas/doc/asmlnk.txt}\tabularnewline
\hline 
SDCC regression test\index{Regression test} & test\_suite\_spec\emph{~~~\hfill{}online at:}\newline
\url{http://sdcc.sourceforge.net/wiki/index.php/Proposed_Test_Suite_Design}\tabularnewline
\hline 
Various notes & sdcc/doc/{*} \emph{~~~\hfill{}online at:}\newline
\url{http://svn.code.sf.net/p/sdcc/code/trunk/sdcc/doc/}\tabularnewline
\hline 
Notes on debugging with SDCDB\index{SDCDB (debugger)} & sdcc/debugger/README \emph{~~~\hfill{}online at}:\newline
\url{http://svn.code.sf.net/p/sdcc/code/trunk/sdcc/debugger/README}\tabularnewline
\hline 
uCsim\index{uCsim} Software simulator for microcontrollers & sdcc/sim/ucsim/doc/index.html \emph{~~~\hfill{}online at:}\newline
\url{http://svn.code.sf.net/p/sdcc/code/trunk/sdcc/sim/ucsim/doc/index.html}\tabularnewline
\hline 
Temporary notes on the pic16\index{PIC16} port & sdcc/src/pic16/NOTES \emph{~~~\hfill{}online at:}\newline
\url{http://svn.code.sf.net/p/sdcc/code/trunk/sdcc/src/pic16/NOTES}\tabularnewline
\hline 
SDCC internal documentation (debugging file format)

 & sdcc/doc/cdbfileformat.pdf \emph{~~~\hfill{}online at:}\newline
\url{http://sdcc.sourceforge.net/wiki/index.php/CDB_File_Format}\tabularnewline
\hline 
\end{tabular}
\par\end{flushleft}

\section{Communication online at SourceForge}

\begin{tabular}{|>{\raggedright}p{0.3\columnwidth}|>{\raggedright}p{0.3\columnwidth}|>{\raggedright}p{0.4\columnwidth}|}
\hline 
\textbf{Subject / Title} & \textbf{Note} & \textbf{Link}\tabularnewline
\hline 
\hline 
wiki\index{wiki}\index{Communication!wiki} &  & \url{http://sdcc.sourceforge.net/wiki/}\tabularnewline
\hline 
sdcc-user mailing list\index{mailing list}\index{Communication!Mailing lists} & around 650 subscribers mid 2009 & \url{https://lists.sourceforge.net/mailman/listinfo/sdcc-user}\tabularnewline
\hline 
sdcc-devel mailing list &  & \url{https://lists.sourceforge.net/mailman/listinfo/sdcc-devel}\tabularnewline
\hline 
help forum\index{Communication!Forums} & similar scope as sdcc-user mailing list & \url{http://sourceforge.net/p/sdcc/discussion/1865}\tabularnewline
\hline 
open discussion forum &  & \url{http://sourceforge.net/p/sdcc/discussion/1864}\tabularnewline
\hline 
trackers (bug tracker, feature requests, patches, support requests,
webdocs)\index{Communication!Trackers} &  & \url{http://sourceforge.net/p/sdcc/_list/tickets}\tabularnewline
\hline 
rss feed\index{RSS feed}\index{Communication!RSS feed} & stay tuned with most (not all) sdcc activities & \url{http://sourceforge.net/export/rss2_keepsake.php?group_id=599}\tabularnewline
\hline 
\end{tabular}

With a sourceforge account you can ''monitor''\index{Communication!Monitor}
forums and trackers, so that you automatically receive mail on changes.
You can digg out earlier communication by using the search function
\url{http://sourceforge.net/search/?group_id=599}.

\section{Related open source tools\label{sec:Related-open-source-tools}\index{Related tools}}
\begin{flushleft}
\begin{tabular}{|>{\raggedright}p{0.2\columnwidth}|p{0.3\columnwidth}|>{\raggedright}p{0.5\columnwidth}|}
\hline 
\textbf{Name} & \textbf{Purpose} & \textbf{Where to get}\tabularnewline
\hline 
\hline 
gpsim\index{gpsim (pic simulator)} & PIC simulator & \url{http://www.dattalo.com/gnupic/gpsim.html}\tabularnewline
\hline 
gputils\index{gputils (pic tools)} & GNU PIC utilities & \url{http://sourceforge.net/projects/gputils}\tabularnewline
\hline 
flP5 & PIC programmer & \url{http://freshmeat.net/projects/flp5/}\tabularnewline
\hline 
ec2drv/newcdb & Tools for Silicon Laboratories JTAG debug adapter, partly based on
SDCDB (Unix only) & \url{http://sourceforge.net/projects/ec2drv}\tabularnewline
\hline 
indent\index{indent (source formatting tool)} & Formats C source - Master of the white spaces & \url{http://directory.fsf.org/GNU/indent.html}\tabularnewline
\hline 
srecord\index{srecord (bin, hex, ... tool)} & Object file conversion, checksumming, ... & \url{http://sourceforge.net/projects/srecord}\tabularnewline
\hline 
objdump\index{objdump (tool)} & Object file conversion, ... & Part of binutils (should be there anyway)\tabularnewline
\hline 
cmon51 & 8051 monitor (hex up-/download, single step, disassemble) & \url{http://sourceforge.net/projects/cmon51}\tabularnewline
\hline 
doxygen\index{doxygen (source documentation tool)} & Source code documentation system & \url{http://www.doxygen.org}\tabularnewline
\hline 
kdevelop & IDE (has anyone tried integrating SDCC \& SDCDB? Unix only) & \url{http://www.kdevelop.org}\tabularnewline
\hline 
paulmon & 8051 monitor (hex up-/download, single step, disassemble) & \url{http://www.pjrc.com/tech/8051/paulmon2.html}\tabularnewline
\hline 
splint\index{splint (syntax checking tool)} & Statically checks c sources (see \ref{lyx:more-pedantic-SPLINT}) & \url{http://www.splint.org}\tabularnewline
\hline 
ddd\index{DDD (debugger)} & Debugger, serves nicely as GUI to SDCDB\index{SDCDB (debugger)} (Unix
only) & \url{http://www.gnu.org/software/ddd/}\tabularnewline
\hline 
d52\index{d52}\index{d52 (disassembler)} & Disassembler, can count instruction cycles\index{instruction cycles (count)},
use with options -pnd & \url{http://www.8052.com/users/disasm/}\tabularnewline
\hline 
cmake\index{cmake} & Cross platform build system, generates Makefiles\index{Makefile}
and project workspaces\index{project workspace} & \url{http://www.cmake.org} and a dedicated wiki entry: \url{http://www.cmake.org/Wiki/CmakeSdcc}\tabularnewline
\hline 
\end{tabular}
\par\end{flushleft}

\section{Related documentation / recommended reading}
\begin{flushleft}
\begin{tabular}{|>{\raggedright}p{0.2\columnwidth}|>{\raggedright}p{0.3\columnwidth}|>{\raggedright}p{0.5\columnwidth}|}
\hline 
\textbf{Name} & \textbf{Subject / Title} & \textbf{Where to get}\tabularnewline
\hline 
\hline 
c-refcard.pdf & C Reference Card\index{C Reference card}, 2 pages & \url{http://refcards.com/refcards/c/index.html}\tabularnewline
\hline 
c-faq & C-FAQ\index{C FAQ} & \url{http://www.c-faq.com}\tabularnewline
\hline 
ISO/IEC 9899:TC2 & ''C-Standard'' & {\footnotesize\url{http://www.open-std.org/jtc1/sc22/wg14/www/standards.html\#9899}}\tabularnewline
\hline 
ISO/IEC DTR 18037 & ''Extensions for Embedded C'' & {\footnotesize\url{http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1021.pdf}}\tabularnewline
\hline 
 & Latest datasheet of target CPU & vendor\tabularnewline
\hline 
 & Revision history of datasheet & vendor\tabularnewline
\hline 
\end{tabular}
\par\end{flushleft}

\section{Application notes specifically for SDCC}

SDCC makes no claims about the completeness of this list and about
up-to-dateness or correctness of the application notes\index{Application notes}.

\begin{flushleft}
{\footnotesize{}%
\begin{tabular}{|p{0.17\columnwidth}|p{0.27\columnwidth}|p{0.56\columnwidth}|}
\hline 
{\footnotesize\textbf{Vendor}} & {\footnotesize\textbf{Subject / Title}} & {\footnotesize\textbf{Where to get}}\tabularnewline
\hline 
\hline 
{\footnotesize Maxim / Dallas} & {\footnotesize Using the SDCC Compiler for the DS80C400\index{DS80C400}} & {\footnotesize\url{http://pdfserv.maxim-ic.com/en/an/AN3346.pdf}}\tabularnewline
\hline 
{\footnotesize Maxim / Dallas} & \multicolumn{1}{>{\raggedright}p{0.3\linewidth}|}{{\footnotesize Using the Free SDCC C Compiler to Develop Firmware for
the DS89C420/430/440/450\index{DS89C4x0} Family of Microcontrollers}} & {\footnotesize\url{http://pdfserv.maxim-ic.com/en/an/AN3477.pdf}}\tabularnewline
\hline 
{\footnotesize Silicon Laboratories / Cygnal} & {\footnotesize Integrating SDCC 8051 Tools Into The Silicon Labs IDE\index{IDE}} & {\footnotesize\url{http://www.silabs.com/public/documents/tpub_doc/anote/Microcontrollers/en/an198.pdf}}\tabularnewline
\hline 
{\footnotesize Ramtron / Goal Semiconductor} & {\footnotesize Interfacing SDCC to Syn and Textpad} & {\footnotesize\url{http://www.ramtron.com/doc/Products/Microcontroller/Support_Tools.asp}}\tabularnewline
\hline 
{\footnotesize Ramtron / Goal Semiconductor} & {\footnotesize Installing and Configuring SDCC and Crimson Editor } & {\footnotesize\url{http://www.ramtron.com/doc/Products/Microcontroller/Support_Tools.asp}}\tabularnewline
\hline 
{\footnotesize Texas Instruments} & {\footnotesize MSC12xx Programming with SDCC} & {\footnotesize\url{http://focus.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=sbaa109&fileType=pdf}}\tabularnewline
\hline 
\end{tabular}}{\footnotesize\par}
\par\end{flushleft}

\section{Some Questions}

Some questions answered, some pointers given - it might be time to
in turn ask \emph{you} some questions: 
\begin{itemize}
\item can you solve your project with the selected microcontroller? Would
you find out early or rather late that your target is too small/slow/whatever?
Can you switch to a slightly better device if it doesn't fit?
\item should you solve the problem with an 8 bit CPU? Or would a 16/32 bit
CPU and/or another programming language be more adequate? Would an
operating system on the target device help?
\item if you solved the problem, will the marketing department be happy?
\item if the marketing department is happy, will customers be happy?
\item if you're the project manager, marketing department and maybe even
the customer in one person, have you tried to see the project from
the outside?
\item is the project done if you think it is done? Or is just that other
interface/protocol/feature/configuration/option missing? How about
website, manual(s), internationali(z|s)ation, packaging, labels, 2nd
source for components, electromagnetic compatability/interference,
documentation for production, production test software, update mechanism,
patent issues?
\item is your project adequately positioned in that magic triangle: fame,
fortune, fun?
\end{itemize}
Maybe not all answers to these questions are known and some answers
may even be \emph{no}, nevertheless knowing these questions may help
you to avoid burnout\footnote{burnout is bad for electronic devices, programmers and motorcycle
tyres}. Chances are you didn't want to hear some of them...

\chapter{Support\index{Support}}

SDCC has grown to be a large project. The compiler alone (without
the preprocessor, assembler and linker) is well over 150,000 lines
of code (blank stripped). The open source nature of this project is
a key to its continued growth and support. You gain the benefit and
support of many active software developers and end users. Is SDCC
perfect? No, that's why we need your help. The developers take pride
in fixing reported bugs. You can help by reporting the bugs and helping
other SDCC users. There are lots of ways to contribute, and we encourage
you to take part in making SDCC a great software package. 

The SDCC project is hosted on the SDCC SourceForge site at \url{http://sourceforge.net/projects/sdcc}.
You'll find the complete set of mailing lists\index{Mailing list(s)},
forums, bug reporting system, patch submission\index{Patch submission}
system, wiki, rss-feed, download\index{download} area and Subversion
code repository\index{Subversion code repository} there.

\section{Reporting Bugs\index{Bug reporting}\index{Reporting bugs}\index{Communication!Bug report}}

The recommended way of reporting bugs is using the infrastructure
of the SourceForge site. You can follow the status of bug reports
there and have an overview about the known bugs.

Bug reports are automatically forwarded to the developer mailing list
and will be fixed ASAP. When reporting a bug, it is very useful to
include a small test program (the smaller the better) which reproduces
the problem. If you can isolate the problem by looking at the generated
assembly code, this can be very helpful. Compiling your program with
the -\/-dumpall\index{-/-dumpall@-\/-dumpall} option can sometimes
be useful in locating optimization problems. When reporting a bug
please make sure you:
\begin{enumerate}
\item Attach the code you are compiling with SDCC. 
\item Specify the exact command you use to run SDCC, or attach your Makefile. 
\item Specify the SDCC version (type \textquotedbl\textsf{\textbf{sdcc
-v}}\textquotedbl ), your platform, and operating system. 
\item Provide an exact copy of any error message or incorrect output. 
\item Put something meaningful in the subject of your message.
\end{enumerate}
Please attempt to include these 5 important parts, as applicable,
in all requests for support or when reporting any problems or bugs
with SDCC. Though this will make your message lengthy, it will greatly
improve your chance that SDCC users and developers will be able to
help you. Some SDCC developers are frustrated by bug reports without
code provided that they can use to reproduce and ultimately fix the
problem, so please be sure to provide sample code if you are reporting
a bug! 

Please have a short check that you are using a recent version of SDCC
and the bug is not yet known. This is the link for reporting bugs:
\url{http://sourceforge.net/p/sdcc/bugs/}. With SDCC on average having
more than 200 downloads\index{download} on SourceForge per day\footnote{220 daily downloads on average Jan-Sept 2006 and about 150 daily downloads
between 2002 and 2005. This does not include other methods of distribution.} there must be some users. So it's not exactly easy to find a new
bug. If you find one we need it: \emph{reporting bugs is good}.

\section{Requesting Features\label{subsec:Requesting-Features}\index{Feature request}\index{Requesting features}\index{Communication!Feature request}}

Like bug reports feature requests are forwarded to the developer mailing
list. This is the link for requesting features: \url{http://sourceforge.net/p/sdcc/feature-requests/}.

\section{Submitting patches\index{Communication!Patch submission}}

Like bug reports contributed patches are forwarded to the developer
mailing list. This is the link for submitting patches\index{Patch submission}:
\url{http://sourceforge.net/p/sdcc/patches/}.

You need to specify some parameters to the \texttt{diff} command for
the patches to be useful. If you modified more than one file a patch
created f.e. with \textsf{\textbf{''diff -Naur unmodified\_directory
modified\_directory >my\_changes.patch''}} will be fine, otherwise
\textsf{\textbf{''diff -u sourcefile.c.orig sourcefile.c >my\_changes.patch''}}
will do.

\section{Getting Help}

These links should take you directly to the Mailing lists \url{http://sourceforge.net/p/sdcc/mailman/sdcc-user/}\footnote{Traffic on sdcc-devel and sdcc-user is about 100 mails/month each
not counting automated messages (mid 2003)} and the Forums \url{http://sourceforge.net/p/sdcc/discussion/},
lists\index{Mailing list(s)}\index{Communication!Mailing lists}
and forums are archived and searchable so if you are lucky someone
already had a similar problem. While mails to the lists themselves
are delivered promptly their web front end on SourceForge sometimes
shows a severe time lag (up to several weeks), if you're seriously
using SDCC please consider subscribing to the lists.

\section{ChangeLog}

You can follow the status of the Subversion version\index{version}
of SDCC by watching the Changelog\index{Changelog} in the Subversion
repository{\footnotesize{} \url{http://svn.code.sf.net/p/sdcc/code/trunk/sdcc/ChangeLog}.}{\footnotesize\par}

\section{Subversion Source Code Repository}

The output of \textsf{\textbf{sdcc -}}\textbf{\/}\textsf{\textbf{-version}}
or the filenames of the snapshot versions of SDCC include date and
its Subversion\index{Subversion code repository} number. Subversion
allows to download the source of recent or previous versions \url{http://sourceforge.net/p/sdcc/code/8805/tree/}
(by number or by date).

\section{Release policy\index{Release policy}}

Starting with version 2.4.0 SDCC in 2004 uses a time-based release
schedule with one official release usually during the first half of
the year.

The last digit of an official release is zero. Additionally there
are daily snapshots available at \url{http://sdcc.sourceforge.net/snap.php},
and you can always build the very last version from the source code
available at Sourceforge \url{http://sdcc.sourceforge.net/snap.php\#Source}.
The SDCC Wiki\index{wiki}\index{SDCC Wiki} at \url{http://sdcc.sourceforge.net/wiki/}
also holds some information about past and future releases.

\section{Quality control\label{sec:Quality-control}\index{Quality control}}

The compiler is passed through \textit{daily} snapshot build compile
and build checks. The so called \textit{regression tests}\index{Regression test}
check that SDCC itself compiles flawlessly on several host platforms
(i386, Opteron, 64 bit Alpha, ppc64, Mac OS X on ppc and i386, Solaris
on Sparc) and checks the quality of the code generated by SDCC by
running the code for several target platforms through simulators.
The regression test suite comprises about 1000 files which expand
to more than 1500 test cases which include about 7000 tests. A large
number of tests from the GCC test suite is included in this. The results
of these tests are published daily on SDCC's snapshot page (click
on the red or green symbols on the right side of \url{http://sdcc.sourceforge.net/snap.php}).

You'll find the test code in the directory \textit{sdcc/support/regression}.
You can run these tests manually by running \textsf{make} in this
directory (or f.e. \textsf{\textbf{''make test-mcs51''}} if you
don't want to run the complete tests). The test code might also be
interesting if you want to look for examples\index{Examples} checking
corner cases of SDCC or if you plan to submit patches\index{Patch submission}.

The PIC14 port uses a different set of regression tests \index{Regression test (PIC14)},
you'll find them in the directory \textit{sdcc/src/regression}.

\section{Examples\index{Examples}}

You'll find some small examples in the directory \emph{sdcc/device/examples/.}
More examples and libraries are available at \emph{The SDCC Open Knowledge
Resource \url{http://sdccokr.dl9sec.de/}} web site or at \url{http://www.pjrc.com/tech/8051/}.


\section{Use of SDCC in Education}

In short: \emph{highly} encouraged\footnote{the phrase \textquotedbl use in education\textquotedbl{} might evoke
the association \textquotedbl\emph{only} fit for use in education\textquotedbl .
This connotation is not intended but nevertheless risked as the licensing
of SDCC makes it difficult to offer educational discounts}. If your rationales are to:
\begin{enumerate}
\item give students a chance to understand the \emph{complete} steps of
code generation
\item have a curriculum that can be extended for years. Then you could use
an FPGA board as target and your curriculum will seamlessly extend
from logic synthesis (http://www.opencores.org \url{opencores.org},
Oregano \url{http://www.oregano.at/ip/ip01.htm}), over assembly programming,
to C to FPGA compilers (FPGAC \url{http://sourceforge.net/projects/fpgac/})
and to C.
\item be able to insert excursions about skills like using a revision control
system, submitting/applying patches, using a type-setting (as opposed
to word-processing) engine \LyX /\LaTeX , using SourceForge \url{http://sourceforge.net/},
following some netiquette \url{http://en.wikipedia.org/wiki/Netiquette},
understanding BSD/LGPL/GPL/Proprietary licensing, growth models of
Open Source Software, CPU simulation, compiler regression tests\index{Regression test}.
\\
And if there should be a shortage of ideas then you can always point
students to the ever-growing feature request list \url{http://sourceforge.net/p/sdcc/feature-requests/}.
\item not tie students to a specific host platform and instead allow them
to use a host platform of \emph{their} choice (among them Alpha, i386,
i386\_64, Mac OS X, Mips, Sparc, Windows and eventually OLPC \url{http://www.laptop.org})
\item not encourage students to use illegal copies of educational software
\item be immune to licensing/availability/price changes of the chosen tool
chain
\item be able to change to a new target platform without having to adopt
a new tool chain
\item have complete control over and insight into the tool chain
\item make your students aware about the pros and cons of open source software
development
\item give back to the public as you are probably at least partially publicly
funded
\item give students a chance to publicly prove their skills and to possibly
see a world wide impact
\end{enumerate}
then SDCC is probably among the first choices. Well, probably SDCC
might be the only choice.

\chapter{SDCC Technical Data}

\section{Optimizations\index{Optimizations}}

SDCC performs a host of standard optimizations in addition to some
MCU specific optimizations. 

\subsection{Sub-expression Elimination\index{Subexpression elimination}}

The compiler does local and \emph{g}lobal \emph{c}ommon \emph{s}ubexpression
\emph{e}limination, e.g.: 
\begin{verse}
\texttt{i = x + y + 1;}~\\
\texttt{j = x + y;}
\end{verse}
will be translated to
\begin{verse}
\texttt{iTemp = x + y;}~\\
\texttt{i = iTemp + 1;}~\\
\texttt{j = iTemp;}
\end{verse}
Some subexpressions are not as obvious as the above example, e.g.:
\begin{verse}
\texttt{a->b{[}i{]}.c = 10;}~\\
\texttt{a->b{[}i{]}.d = 11;}
\end{verse}
In this case the address arithmetic a->b{[}i{]} will be computed only
once; the equivalent code in C would be.
\begin{verse}
\texttt{iTemp = a->b{[}i{]};}~\\
\texttt{iTemp.c = 10;}~\\
\texttt{iTemp.d = 11;}
\end{verse}
The compiler will try to keep these temporary variables in registers.

\subsection{Dead-Code Elimination\index{Dead-code elimination}}
\begin{verse}
\texttt{int global;}~\\
\texttt{}~\\
\texttt{void f () \{}~\\
\texttt{~~int i;}~\\
\texttt{~~i = 1; ~~~~~/{*} dead store {*}/}~\\
\texttt{~~global = 1;~/{*} dead store {*}/}~\\
\texttt{~~global = 2;}~\\
\texttt{~~return;}~\\
\texttt{~~global = 3;~/{*} unreachable {*}/}~\\
\texttt{\}}
\end{verse}
will be changed to
\begin{verse}
\texttt{int global;}~\\
\texttt{}~\\
\texttt{void f () \{}~\\
\texttt{~~global = 2; }~\\
\texttt{\}}
\end{verse}

\subsection{Copy-Propagation\index{Copy propagation}}
\begin{verse}
\texttt{int f() \{}~\\
\texttt{~~int i, j;}~\\
\texttt{~~i = 10;}~\\
\texttt{~~j = i;}~\\
\texttt{~~return j;}~\\
\texttt{\}}
\end{verse}
will be changed to 
\begin{verse}
\texttt{int f() \{}~\\
\texttt{~~int i, j;}~\\
\texttt{~~i = 10;}~\\
\texttt{~~j = 10;}~\\
\texttt{~~return 10;}~\\
\texttt{\}}
\end{verse}
Note: the dead stores created by this copy propagation will be eliminated
by dead-code elimination.

\subsection{Loop Optimizations\index{Loop optimization}\label{subsec:Loop-Optimizations}}

Two types of loop optimizations are done by SDCC \emph{loop invariant}
lifting and \emph{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\index{Register allocation}, loop induction
optimization causes an increase in register pressure, which may cause
unwanted spilling of other temporary variables into the stack\index{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 using \#pragma~noinduction\index{#pragma noinduction@\#pragma noinduction}.\\
\\
Loop Invariant:
\begin{verse}
\texttt{for (i = 0 ; i < 100 ; i ++)}~\\
\texttt{~~~~f += k + l;}
\end{verse}
changed to
\begin{verse}
\texttt{itemp = k + l;}~\\
\texttt{for (i = 0; i < 100; i++)}~\\
\texttt{~~~~f += itemp;}
\end{verse}
As mentioned previously some loop invariants are not as apparent,
all static address computations are also moved out of the loop.\\
\\
Strength Reduction\index{Strength reduction}, this optimization substitutes
an expression by a cheaper expression:
\begin{verse}
\texttt{for (i=0;i < 100; i++)}~\\
\texttt{~~~~ar{[}i{*}5{]} = i{*}3;}
\end{verse}
changed to
\begin{verse}
\texttt{itemp1 = 0;}~\\
\texttt{itemp2 = 0;}~\\
\texttt{for (i=0;i< 100;i++) \{}~\\
\texttt{~~~~ar{[}itemp1{]} = itemp2;}~\\
\texttt{~~~~itemp1 += 5;}~\\
\texttt{~~~~itemp2 += 3;}~\\
\texttt{\}}
\end{verse}
The more expensive multiplication\index{Multiplication} is changed
to a less expensive addition.

\subsection{Loop Reversing\index{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 compilers use data-dependency
analysis to make this determination, SDCC uses a more simple minded
analysis).
\begin{itemize}
\item The 'for' loop is of the form \\
\\
\texttt{for(<symbol> = <expression>; <sym> {[}< | <={]} <expression>;
{[}<sym>++ | <sym> += 1{]})}~\\
\texttt{~~~~<for body>}
\item The <for body> does not contain ``continue'' or 'break''.
\item All goto's are contained within the loop.
\item No function calls within the loop.
\item The loop control variable <sym> is not assigned any value within the
loop
\item The loop control variable does NOT participate in any arithmetic operation
within the loop.
\item There are NO switch statements in the loop.
\end{itemize}

\subsection{Algebraic Simplifications}

SDCC does numerous algebraic simplifications, the following is a small
sub-set of these optimizations.
\begin{verse}
\texttt{i = j + 0;~~~~ /{*} changed to: {*}/~~~~ i = j;}~\\
\texttt{i /= 2;~~~~~~~ /{*} for unsigned i changed to: {*}/~~~~
i >\textcompwordmark >= 1;}~\\
\texttt{i = j - j;~~~~ /{*} changed to: {*}/~~~~ i = 0;}~\\
\texttt{i = j / 1;~~~~ /{*} changed to: {*}/~~~~ i = j;}
\end{verse}
Note the subexpressions\index{Subexpression} given above are generally
introduced by macro expansions or as a result of copy/constant propagation.

\subsection{'switch' Statements\label{subsec:'switch'-Statements}\index{switch statement}}

SDCC can optimize switch statements to jump tables\index{jump tables}.
It makes the decision based on an estimate of the generated code size.
SDCC is quite liberal in the requirements for jump table generation: 
\begin{itemize}
\item The labels need not be in order, and the starting number need not
be one or zero, the case labels are in numerical sequence or not too
many case labels are missing.

\begin{verse}
\texttt{switch(i) \{~~~~~~~~~~~~~~~~~~~~~~~~~~switch
(i) \{}~\\
\texttt{~~~case 4: ...~~~~~~~~~~~~~~~~~~~~~~~~~~case
0: ...}~\\
\texttt{~~~case 5: ...~~~~~~~~~~~~~~~~~~~~~~~~~~case
1: ...}~\\
\texttt{~~~case 3: ...~~~~~~~~~~~~~~~~~~~~~~~~~~}~\\
\texttt{~~~case 6: ...~~~~~~~~~~~~~~~~~~~~~~~~~~case
3: ...}~\\
\texttt{~~~case 7: ...~~~~~~~~~~~~~~~~~~~~~~~~~~case
4: ...}~\\
\texttt{~~~case 8: ...~~~~~~~~~~~~~~~~~~~~~~~~~~case
5: ...}~\\
\texttt{~~~case 9: ...~~~~~~~~~~~~~~~~~~~~~~~~~~case
6: ...}~\\
\texttt{~~~case 10: ...~~~~~~~~~~~~~~~~~~~~~~~~~case
7: ...}~\\
\texttt{~~~case 11: ...~~~~~~~~~~~~~~~~~~~~~~~~~case
8: ...}~\\
\texttt{\}~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\}}
\end{verse}
Both the above switch statements will be implemented using a jump-table.
The example to the right side is slightly more efficient as the check
for the lower boundary of the jump-table is not needed.
\item The number of case labels is not larger than supported by the target
architecture.
\item If the case labels are not in numerical sequence ('gaps' between cases)
SDCC checks whether a jump table with additionally inserted dummy
cases is still attractive. 
\item If the starting number is not zero and a check for the lower boundary
of the jump-table can thus be eliminated SDCC might insert dummy cases
0, ... .
\end{itemize}
Switch statements which have large gaps in the numeric sequence or
those that have too many case labels can be split into more than one
switch statement for efficient code generation, e.g.:
\begin{verse}
\texttt{switch (i) \{}~\\
\texttt{~~case 1: ...}~\\
\texttt{~~case 2: ...}~\\
\texttt{~~case 3: ...}~\\
\texttt{~~case 4: ...}~\\
\texttt{~~case 5: ...}~\\
\texttt{~~case 6: ...}~\\
\texttt{~~case 7: ...}~\\
\texttt{~~case 101: ...}~\\
\texttt{~~case 102: ...}~\\
\texttt{~~case 103: ...}~\\
\texttt{~~case 104: ...}~\\
\texttt{~~case 105: ...}~\\
\texttt{~~case 106: ...}~\\
\texttt{~~case 107: ...}~\\
\texttt{\}}
\end{verse}
If the above switch statement is broken down into two switch statements
\begin{verse}
\texttt{switch (i) \{}~\\
\texttt{~~case 1: ...}~\\
\texttt{~~case 2: ...}~\\
\texttt{~~case 3: ...}~\\
\texttt{~~case 4: ...}~\\
\texttt{~~case 5: ...}~\\
\texttt{~~case 6: ...}~\\
\texttt{~~case 7: ...}~\\
\texttt{\}}
\end{verse}
and
\begin{verse}
\texttt{switch (i) \{}~\\
\texttt{~~case 101: ...}~\\
\texttt{~~case 102: ...}~\\
\texttt{~~case 103: ...}~\\
\texttt{~~case 104: ...}~\\
\texttt{~~case 105: ...}~\\
\texttt{~~case 106: ...}~\\
\texttt{~~case 107: ...}~\\
\texttt{\}}
\end{verse}
then both the switch statements will be implemented using jump-tables
whereas the unmodified switch statement will not be.


\subsection{Bit-shifting Operations\index{Bit shifting}.}

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, e.g.:
\begin{verse}
\texttt{unsigned char i;}~\\
\texttt{...}~\\
\texttt{i >\textcompwordmark >= 4;}~\\
\texttt{...}
\end{verse}
generates the following code:
\begin{verse}
\texttt{mov~ a,\_i}~\\
\texttt{swap a}~\\
\texttt{anl~ a,\#0x0f}~\\
\texttt{mov~ \_i,a}
\end{verse}
Typically, SDCC will not setup a loop if the shift count is known.
Another example:
\begin{verse}
\texttt{unsigned int i;}~\\
\texttt{...}~\\
\texttt{i >\textcompwordmark >= 9;}~\\
\texttt{...}
\end{verse}
will generate:
\begin{verse}
\texttt{mov~~a,(\_i + 1)}~\\
\texttt{mov~~(\_i + 1),\#0x00}~\\
\texttt{clr~~c}~\\
\texttt{rrc~~a}~\\
\texttt{mov~~\_i,a}
\end{verse}

\subsection{Bit-rotation\index{Bit rotation}}

A special case of the bit-shift operation is bit rotation\index{rotating bits},
SDCC recognizes the following expression to be a left bit-rotation:
\begin{verse}
\texttt{\textbf{unsigned}}\texttt{~~char i;~~~~~~~~~~~/{*}
unsigned is needed for rotation {*}/}~\\
\texttt{...}~\\
\texttt{i = ((i <\textcompwordmark < 1) | (i >\textcompwordmark >
7));}\\
\texttt{...}
\end{verse}
will generate the following code:
\begin{verse}
\texttt{mov~~a,\_i}~\\
\texttt{rl~~~a}~\\
\texttt{mov~~\_i,a}
\end{verse}
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.: 
\begin{verse}
\texttt{i = ((i >\textcompwordmark > 7) | (i <\textcompwordmark <
1)); /{*} left-bit rotation {*}/}
\end{verse}

\subsection{Nibble and Byte Swapping}

Other special cases of the bit-shift operations are nibble or byte
swapping\index{swapping nibbles/bytes}, SDCC recognizes the following
expressions:
\begin{verse}
\texttt{\textbf{unsigned}}\texttt{~~char i;}~\\
\texttt{\textbf{unsigned}}\texttt{~~int j;}~\\
\texttt{...}~\\
\texttt{i = ((i <\textcompwordmark < 4) | (i >\textcompwordmark >
4));} \\
\texttt{j = ((j <\textcompwordmark < 8) | (j >\textcompwordmark >
8)); }
\end{verse}
and generates a swap instruction for the nibble swapping\index{Nibble swapping}
or move instructions for the byte swapping\index{Byte swapping}.
The ''j'' example can be used to convert from little to big-endian
or vice versa. If you want to change the endianness of a \emph{signed}
integer you have to cast to \texttt{(unsigned int)} first.

Note that SDCC stores numbers in little-endian\footnote{Usually 8-bit processors don't care much about endianness. This is
not the case for the standard 8051 which only has an instruction to
increment its \emph{dptr}\index{DPTR}-datapointer so little-endian
is the more efficient byte order.}\index{little-endian}\index{Endianness} format (i.e. lowest order
first) for most backends. However, the hc08, s08 and stm8 backends
are big-endian.

\subsection{Getting a Bit\index{Any Order Bit}}

It is frequently required to obtain the highest order bit of an integral
type (long, int, short or char types). Also obtaining any other order
bit is not uncommon. SDCC recognizes the following expressions to
yield the highest order bit and generates optimized code for it, e.g.:
\begin{verse}
\texttt{unsigned int gint;}~\\
\texttt{}~\\
\texttt{foo () \{}~\\
\texttt{~~unsigned char hob1, aob1;}~\\
\texttt{~~bit hob2, hob3, aob2, aob3;}~\\
\texttt{~~...}~\\
\texttt{~~hob1 = (gint >\textcompwordmark > 15) \& 1;}~\\
\texttt{~~hob2 = (gint >\textcompwordmark > 15) \& 1;}~\\
\texttt{~~hob3 = gint \& 0x8000;}~\\
\texttt{~~aob1 = (gint >\textcompwordmark > 9) \& 1;}~\\
\texttt{~~aob2 = (gint >\textcompwordmark > 8) \& 1;}~\\
\texttt{~~aob3 = gint \& 0x0800;}~\\
\texttt{~~...}~\\
\texttt{\}}
\end{verse}
will generate the following code:
\begin{verse}
\texttt{~~~~~~~~~~~~~~~~~~~~~~~~~ 61 ;~
hob.c 7}~\\
\texttt{000A E5{*}01~~~~~~~~~~~~~~~ 62~~~~~~~~
mov~~ a,(\_gint + 1)}~\\
\texttt{000C 23~~~~~~~~~~~~~~~~~~ 63~~~~~~~~
rl~~~ a}~\\
\texttt{000D 54 01~~~~~~~~~~~~~~~ 64~~~~~~~~
anl~~ a,\#0x01}~\\
\texttt{000F F5{*}02~~~~~~~~~~~~~~~ 65~~~~~~~~
mov~~ \_foo\_hob1\_1\_1,a}~\\
\texttt{~~~~~~~~~~~~~~~~~~~~~~~~~ 66 ;~
hob.c 8}~\\
\texttt{0011 E5{*}01~~~~~~~~~~~~~~~ 67~~~~~~~~
mov~~ a,(\_gint + 1)}~\\
\texttt{0013 33~~~~~~~~~~~~~~~~~~ 68~~~~~~~~
rlc~~ a}~\\
\texttt{0014 92{*}00~~~~~~~~~~~~~~~ 69~~~~~~~~
mov~~ \_foo\_hob2\_1\_1,c}~\\
\texttt{~~~~~~~~~~~~~~~~~~~~~~~~~ 66 ;~
hob.c 9}~\\
\texttt{0016 E5{*}01~~~~~~~~~~~~~~~ 67~~~~~~~~
mov~~ a,(\_gint + 1)}~\\
\texttt{0018 33~~~~~~~~~~~~~~~~~~ 68~~~~~~~~
rlc~~ a}~\\
\texttt{0019 92{*}01~~~~~~~~~~~~~~~ 69~~~~~~~~
mov~~ \_foo\_hob3\_1\_1,c}~\\
\texttt{~~~~~~~~~~~~~~~~~~~~~~~~~ 70 ;~
hob.c 10}~\\
\texttt{001B E5{*}01~~~~~~~~~~~~~~~ 71~~~~~~~~
mov~~ a,(\_gint + 1)}~\\
\texttt{001D 03~~~~~~~~~~~~~~~~~~ 72~~~~~~~~
rr~~~ a}~\\
\texttt{001E 54 01~~~~~~~~~~~~~~~ 73~~~~~~~~
anl~~ a,\#0x01}~\\
\texttt{0020 F5{*}03~~~~~~~~~~~~~~~ 74~~~~~~~~
mov~~ \_foo\_aob1\_1\_1,a}~\\
\texttt{~~~~~~~~~~~~~~~~~~~~~~~~~ 75 ;~
hob.c 11}~\\
\texttt{0022 E5{*}01~~~~~~~~~~~~~~~ 76~~~~~~~~
mov~~ a,(\_gint + 1)}~\\
\texttt{0024 13~~~~~~~~~~~~~~~~~~ 77~~~~~~~~
rrc~~ a}~\\
\texttt{0025 92{*}02~~~~~~~~~~~~~~~ 78~~~~~~~~
mov~~ \_foo\_aob2\_1\_1,c}~\\
\texttt{~~~~~~~~~~~~~~~~~~~~~~~~~ 79 ;~
hob.c 12}~\\
\texttt{0027 E5{*}01~~~~~~~~~~~~~~~ 80~~~~~~~~
mov~~ a,(\_gint + 1)}~\\
\texttt{0029 A2 E3~~~~~~~~~~~~~~~ 81~~~~~~~~
mov~~ c,acc{[}3{]}}~\\
\texttt{002B 92{*}03~~~~~~~~~~~~~~~ 82~~~~~~~~
mov~~ \_foo\_aob3\_1\_1,c}
\end{verse}
Other variations of these cases however will \emph{not} be recognized.
They are standard C expressions, so I heartily recommend these 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,
e.g.:
\begin{verse}
\texttt{xyz = gint + ((gint >\textcompwordmark > 15) \& 1);}
\end{verse}
will still be recognized.

\subsection{Higher Order Byte\index{Higher Order Byte} / Higher Order Word\index{Higher Order Word}}

It is also frequently required to obtain a higher order byte or word
of a larger integral type (long, int or short types). For mcs51, SDCC
recognizes the following expressions to yield the higher order byte
or word and generates optimized code for it, e.g.:
\begin{verse}
\texttt{unsigned int gint;}~\\
\texttt{unsigned long int glong;}~\\
\texttt{}~\\
\texttt{foo () \{}~\\
\texttt{~~unsigned char hob1, hob2;}~\\
\texttt{~~unsigned int how1, how2;}~\\
\texttt{~~...}~\\
\texttt{~~hob1 = (gint >\textcompwordmark > 8) \& 0xFF;}~\\
\texttt{~~hob2 = glong >\textcompwordmark > 24;}~\\
\texttt{~~how1 = (glong >\textcompwordmark > 16) \& 0xFFFF;}~\\
\texttt{~~how2 = glong >\textcompwordmark > 8;}~\\
\texttt{~~...}~\\
\texttt{\}}
\end{verse}
will generate the following code:
\begin{verse}
\texttt{~~~~~~~~~~~~~~~~~~~~~~~~~ 91 ;~
hob.c 15}~\\
\texttt{0037 85{*}01{*}06~~~~~~~~~~~~ 92~~~~~~~~
mov~~ \_foo\_hob1\_1\_1,(\_gint + 1)}~\\
\texttt{~~~~~~~~~~~~~~~~~~~~~~~~~ 93 ;~
hob.c 16}~\\
\texttt{003A 85{*}05{*}07~~~~~~~~~~~~ 94~~~~~~~~
mov~~ \_foo\_hob2\_1\_1,(\_glong + 3)}~\\
\texttt{~~~~~~~~~~~~~~~~~~~~~~~~~ 95 ;~
hob.c 17}~\\
\texttt{003D 85{*}04{*}08~~~~~~~~~~~~ 96~~~~~~~~
mov~~ \_foo\_how1\_1\_1,(\_glong + 2)}~\\
\texttt{0040 85{*}05{*}09~~~~~~~~~~~~ 97~~~~~~~~
mov~~ (\_foo\_how1\_1\_1 + 1),(\_glong + 3)}~\\
\texttt{0043 85{*}03{*}0A~~~~~~~~~~~~ 98~~~~~~~~
mov~~ \_foo\_how2\_1\_1,(\_glong + 1)}~\\
\texttt{0046 85{*}04{*}0B~~~~~~~~~~~~ 99~~~~~~~~
mov~~ (\_foo\_how2\_1\_1 + 1),(\_glong + 2)}
\end{verse}
Again, variations of these cases may \emph{not} be recognized. They
are standard C expressions, so I heartily recommend these be the only
way to get the higher order byte/word, (it is portable). Of course
it will be recognized even if it is embedded in other expressions,
e.g.:
\begin{verse}
\texttt{xyz = gint + ((gint >\textcompwordmark > 8) \& 0xFF);}
\end{verse}
will still be recognized.

\subsection{Placement of Bank-Selection Instructions}

For non-intrinsic named address spaces, SDCC will place the bank selection
instructions optimally. For details see Philipp Klaus Krause, ''Optimal
Placement of Bank Selection Instructions in Polynomial Time'', Proceedings
of the 16th International Workshop on Software and Compilers for Embedded
Systems, M-SCOPES ’13, pp 23–30. Association for Computing Machinery,
2013. 

\subsection{Lifetime-Optimal Speculative Partial Redundancy Elimination}

SDCC has an implementation of lifetime-optimal speculative partial
redundancy elimination based on tree-decompositions.

\subsection{Register Allocation\label{subsec:Register-Allocation}\index{Register-Allocation}}

SDCC currently has two register allocators. One of them is optimal
when optimizing for code size. This register allocator is used by
default on all ports except for mcs51, ds390, pic14 and pic16. With
the exception of hc08 and s08, it is also the only available register
allocator for these ports. Even though it runs in polynomial time,
it can be quite slow; therefore the \code{-{}-max-allocs-per-node}
command line option can be used for a trade-off between compilation
speed and quality of the generated code: Lower values result in faster
compilation, higher values can result in better code being generated.

It first creates a tree-decomposition of the control-flow graph, and
then uses dynamic programming bottom-up along the tree-decomposition.
Optimality is achieved through the use of a cost function, which gives
cost for instructions under register assignments. The cost function
is target-specific and has to be implemented for each port; in all
current SDCC ports the cost function is integrated into code generation.

For more details on how this register allocator works, see: Philipp
Klaus Krause, ''Optimal Register Allocation in Polynomial Time'',
Compiler Construction - 22nd International Conference, CC 2013, Held
as Part of the European Joint Conferences on Theory and Practice of
Software, ETAPS 2013. Proceedings, Lecture Notes in Computer Science,
volume 7791, pp. 1-20. Springer, 2013. Also: Philipp Klaus Krause,
''Bytewise Register Allocation'', Proceedings of the 18th International
Workshop on Software and Compilers for Embedded Systems, SCOPES ’15,
pp 22–27. Association for Computing Machinery, 2015. 

\subsection{Peephole Optimizer\label{subsec:Peephole-Optimizer}\index{Peephole optimizer}}

The compiler uses a rule based, pattern matching and re-writing mechanism
for peep-hole optimization. It is inspired by \emph{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 \emph{-\/-peep-file\index{-/-peep-file@-\/-peep-file}
<filename>} option. The rule language is best illustrated with examples.
\begin{verse}
\texttt{replace \{}~\\
\texttt{~~mov \%1,a}~\\
\texttt{~~mov a,\%1}~\\
\texttt{\} by \{}~\\
\texttt{~~mov \%1,a}~\\
\texttt{\}}
\end{verse}
The above rule will change the following assembly\index{Assembler routines}
sequence:
\begin{verse}
\texttt{mov r1,a}~\\
\texttt{mov a,r1}
\end{verse}
to
\begin{verse}
\texttt{mov r1,a}
\end{verse}
Note: All occurrences of a \emph{\%n} (pattern variable) must denote
the same string. With the above rule, the assembly sequence:
\begin{verse}
\texttt{mov r1,a}~\\
\texttt{mov a,r2}
\end{verse}
will remain unmodified.\\
\\
Other special case optimizations may be added by the user (via \emph{-\/-peep-file
option}). E.g. some variants of the 8051 MCU\index{MCS51 variants}
allow only \texttt{ajmp} and \texttt{acall}. The following two rules
will change all \texttt{ljmp} and \texttt{lcall} to \texttt{ajmp}
and \texttt{acall}
\begin{verse}
\texttt{replace \{ lcall \%1 \} by \{ acall \%1 \}}~\\
\texttt{replace \{ ljmp \%1 \} by \{ ajmp \%1 \}}
\end{verse}
(NOTE: from version 2.7.3 on, you can use option -\emph{\/}-acall-ajmp\index{-/-acall-ajmp@-\/-acall-ajmp},
which also takes care of aligning the interrupt vectors properly.)\\

The \emph{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:
\begin{verse}
\texttt{rule := replace {[} restart {]} '\{' <assembly sequence> '\textbackslash n'}~\\
\texttt{~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ '\}' by '\{' '\textbackslash n'}~\\
\texttt{~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ <assembly
sequence> '\textbackslash n'}~\\
\texttt{~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ '\}' {[}if <functionName>
{]} '\textbackslash n'}
\end{verse}
<assembly sequence> := assembly instruction (each instruction 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 when all rules are
exhausted. If the 'restart' option is specified, then the optimizer
will start matching the rules 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. An example
of this (not a good one, it has side effects) is the following rule:
\begin{verse}
\texttt{replace restart \{}~\\
\texttt{~~pop \%1}~\\
\texttt{~~push \%1 \} by \{}~\\
\texttt{~~; nop}~\\
\texttt{\}}
\end{verse}
Note that the replace pattern cannot be a blank, but can be a comment
line. Without the 'restart' option only the innermost 'pop' 'push'
pair would be eliminated, i.e.:
\begin{verse}
\texttt{pop ar1}~\\
\texttt{pop ar2}~\\
\texttt{push ar2}~\\
\texttt{push ar1}
\end{verse}
would result in:
\begin{verse}
\texttt{pop ar1}~\\
\texttt{; nop}~\\
\texttt{push ar1}
\end{verse}
\emph{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:
\begin{verse}
\texttt{; nop}~\\
\texttt{; nop}
\end{verse}
A conditional function can be attached to a rule. Attaching rules
are somewhat more involved, let's illustrate this with an example.
\begin{verse}
\texttt{replace \{}~\\
\texttt{~ ~ ~ljmp \%5}~\\
\texttt{\%2:}~\\
\texttt{\} by \{}~\\
\texttt{~ ~ ~sjmp \%5}~\\
\texttt{\%2:}~\\
\texttt{\} if labelInRange}
\end{verse}
The optimizer does a look-up of a function name table defined in function
\emph{callFuncByName} in the source file SDCCpeeph.c, with the name
\emph{labelInRange}. If it finds a corresponding entry the function
is called. Note there can be no parameters specified for some of these
functions, in this case the use of \emph{\%5} is crucial, since the
function \emph{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. Currently implemented are \emph{labelInRange, labelRefCount,
labelRefCountChange, labelIsReturnOnly, xramMovcOption, portIsDS390,
24bitMode, notVolatile}. \emph{notUsed, notSame, operandsNotRelated,
labelJTInRange, canAssign, optimizeReturn, notUsedFrom, labelIsReturnOnly,
operandsLiteral, labelIsUncondJump, deadMove, useAcallAjmp} and \emph{okToRemoveSLOC.}

This whole thing is a little kludgy, but maybe some day SDCC will
have some better means. If you are looking at the \texttt{peeph{*}.def}
files, you will see the default 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.

\section{Cyclomatic Complexity\index{Cyclomatic complexity}}

Cyclomatic complexity of a function is defined as the number of independent
paths the program can take during execution of the function. This
is an important number since it defines the number test cases you
have to generate to validate the function. The accepted industry standard
for complexity number is 10, if the cyclomatic complexity reported
by SDCC exceeds 10 you should think about simplification of the function
logic. Note that the complexity level is not related to the number
of lines of code in a function. Large functions can have low complexity,
and small functions can have large complexity levels. \\
\\
SDCC uses the following formula to compute the complexity:\\

complexity = (number of edges in control flow graph) - (number of
nodes in control flow graph) + 2;\\
\\
Having said that the industry standard is 10, you should be aware
that in some cases it be may unavoidable to have a complexity level
of less than 10. For example if you have switch statement with more
than 10 case labels, each case label adds one to the complexity level.
The complexity level is by no means an absolute measure of the algorithmic
complexity of the function, it does however provide a good starting
point for which functions you might look at for further optimization.

\section{Retargetting for other Processors}

The issues for retargetting the compiler are far too numerous to be
covered by this document. What follows is a brief description of each
of the phases of the compiler and its MCU dependency.
\begin{itemize}
\item 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 like back patching labels and the pattern matching optimizations
like bit-rotation etc.
\item The second phase involves generating an intermediate code which can
be easy manipulated during the later phases. This phase is entirely
MCU independent. The intermediate code generation assumes the target
machine has unlimited number of registers, and designates them with
the name iTemp. The compiler can be made to dump a human readable
form of the code generated by using the -\/-dumpraw option.
\item This phase does the bulk of the standard optimizations and is also
MCU independent. This phase can be broken down into several sub-phases:\\
\\
Break down intermediate code (iCode) into basic blocks.\\
Do control flow \& data flow analysis on the basic blocks.\\
Do local common subexpression elimination, then global subexpression
elimination\\
Dead code elimination\\
Loop optimizations\\
If loop optimizations caused any changes then do 'global subexpression
elimination' and 'dead code elimination' again.
\item This phase determines the live-ranges; by live range I mean those
iTemp variables defined by the compiler that still survive after all
the optimizations. Live range analysis\index{Live range analysis}
is essential for register allocation, since these computation determines
which of these iTemps will be assigned to registers, and for how long.
\item Phase five is register allocation. For new ports register allocator
described above in \ref{subsec:Register-Allocation} should be used
in most cases, since it can result in substantially better code. In
the old register allocator, there are two parts to register allocation.\\
\\
The first part I call 'register packing' (for lack of a better term).
In this case several MCU specific expression folding is done to reduce
register pressure.\\
\\
The second part is more MCU independent and deals with allocating
registers to the remaining live ranges. A lot of MCU specific code
does creep into this phase because of the limited number of index
registers available in the 8051.
\item The Code generation phase is (unhappily), entirely MCU dependent and
very little (if any at all) of this code can be reused for other MCU.
However the scheme for allocating a homogenized assembler operand
for each iCode operand may be reused.
\item As mentioned in the optimization section the peep-hole optimizer is
rule based system, which can reprogrammed for other MCUs.
\end{itemize}
More information is available on SDCC Wiki\index{wiki} (preliminary
link \url{https://sourceforge.net/p/sdcc/wiki/Adding\%20a\%20port/})
and in the thread \url{http://sourceforge.net/mailarchive/message.php?msg_id=13954144}
.

\chapter{Compiler internals\index{Compiler internals}}

\section{The anatomy of the compiler\label{subsec:The-anatomy-of}}

\textit{This is an excerpt from an article published in Circuit Cellar
Magazine in} \textbf{\textit{August 2000}}\textit{. It's outdated
(the compiler is much more efficient now and user/developer friendly),
but pretty well exposes the guts of it all.}\\
\\
The current version of SDCC can generate code for Intel 8051 and Z80
MCU. It is fairly easy to retarget for other 8-bit MCU. Here we take
a look at some of the internals of the compiler. 

\paragraph*{Parsing\index{Parsing} }

Parsing the input source file and creating an AST (Annotated Syntax
Tree\index{Annotated syntax tree}). This phase also involves propagating
types (annotating each node of the parse tree with type information)
and semantic analysis. There are some MCU specific parsing rules.
For example the intrinsic named address spaces are MCU specific: While
there may be an \_\_xdata intrinsic named address space for 8051 there
none for z80. SDCC has MCU specific intrinsic named address spacess,
i.e. \_\_xdata will be treated as a named address space when parsing
8051 C code but will be treated as a C identifier when parsing z80
code.

\paragraph*{Generating iCode\index{iCode}}

Intermediate code generation. In this phase the AST is broken down
into three-operand form (iCode). These three operand forms are represented
as doubly linked lists. ICode is the term given to the intermediate
form generated by the compiler. ICode example section shows some examples
of iCode generated for some simple C source functions.

\paragraph*{Optimizations\index{Optimizations}.}

Bulk of the target independent optimizations is performed in this
phase. The optimizations include constant propagation, common sub-expression
elimination, loop invariant code movement, strength reduction of loop
induction variables and dead-code elimination.

\paragraph*{Live range analysis\index{Live range analysis}}

During intermediate code generation phase, the compiler assumes the
target machine has infinite number of registers and generates a lot
of temporary variables. The live range computation determines the
lifetime of each of these compiler-generated temporaries. A picture
speaks a thousand words. ICode example sections show the live range
annotations for each of the operand. It is important to note here,
each iCode is assigned a number in the order of its execution in the
function. The live ranges are computed in terms of these numbers.
The from number is the number of the iCode which first defines the
operand and the to number signifies the iCode which uses this operand
last.

\paragraph*{Register Allocation\index{Register allocation}}

The register allocation determines the type and number of registers
needed by each operand. In most MCUs only a few registers can be used
for indirect addressing. In case of 8051 for example the registers
R0 \& R1 can be used to indirectly address the internal ram and DPTR
to indirectly address the external ram. The compiler will try to allocate
the appropriate register to pointer variables if it can. ICode example
section shows the operands annotated with the registers assigned to
them. The compiler will try to keep operands in registers as much
as possible; there are several schemes the compiler uses to do achieve
this. When the compiler runs out of registers the compiler will check
to see if there are any live operands which is not used or defined
in the current basic block being processed, if there are any found
then it will push that operand and use the registers in this block,
the operand will then be popped at the end of the basic block. 

There are other MCU specific considerations in this phase. Some MCUs
have an accumulator; very short-lived operands could be assigned to
the accumulator instead of a general-purpose register.

\paragraph*{Code generation}

Figure II gives a table of iCode\index{iCode} operations supported
by the compiler. The code generation involves translating these operations
into corresponding assembly code for the processor. This sounds overly
simple but that is the essence of code generation. Some of the iCode
operations are generated on a MCU specific manner for example, the
z80 port does not use registers to pass parameters so the SEND and
RECV iCode operations will not be generated, and it also does not
support JUMPTABLES. \\

{\footnotesize Figure II }{\footnotesize{}%
\begin{longtable}[c]{|p{0.13\columnwidth}|>{\raggedright}p{0.13\columnwidth}|p{0.22\columnwidth}|p{0.4\columnwidth}|}
\hline 
\textbf{iCode}\index{iCode} & \textbf{Operands} & \textbf{Description} & \textbf{C Equivalent}\tabularnewline
\hline 
\hline
\endhead
\hline 
{\footnotesize '!'} & {\footnotesize IC\_LEFT() IC\_RESULT()} & {\footnotesize NOT operation } & {\footnotesize IC\_RESULT = ! IC\_LEFT;}\tabularnewline
\hline 
{\footnotesize '\textasciitilde '} & {\footnotesize IC\_LEFT() IC\_RESULT()} & {\footnotesize Bitwise complement of } & {\footnotesize IC\_RESULT = \textasciitilde IC\_LEFT;}\tabularnewline
\hline 
{\footnotesize ROT} & {\footnotesize IC\_LEFT() IC\_RIGHT() IC\_RESULT()} & {\footnotesize Rotate} & {\footnotesize IC\_RESULT = (IC\_LEFT <\textcompwordmark < IC\_RIGHT)
| (IC\_LEFT >\textcompwordmark > (sizeof(IC\_LEFT){*}8-IC\_RIGHT));}\tabularnewline
\hline 
{\footnotesize UNARYMINUS} & {\footnotesize IC\_LEFT() IC\_RESULT()} & {\footnotesize Unary minus} & {\footnotesize IC\_RESULT = - IC\_LEFT;}\tabularnewline
\hline 
{\footnotesize IPUSH} & {\footnotesize IC\_LEFT()} & {\footnotesize Push the operand onto stack} & {\footnotesize NONE}\tabularnewline
\hline 
{\footnotesize IPOP} & {\footnotesize IC\_LEFT()} & {\footnotesize Pop the operand from the stack } & {\footnotesize NONE}\tabularnewline
\hline 
{\footnotesize CALL} & {\footnotesize IC\_LEFT() IC\_RESULT()} & {\footnotesize Call the function represented by IC\_LEFT } & {\footnotesize IC\_RESULT = IC\_LEFT();}\tabularnewline
\hline 
{\footnotesize PCALL} & {\footnotesize IC\_LEFT() IC\_RESULT()} & {\footnotesize Call via function pointer} & {\footnotesize IC\_RESULT = ({*}IC\_LEFT)();}\tabularnewline
\hline 
{\footnotesize RETURN} & {\footnotesize IC\_LEFT()} & {\footnotesize Return the value in operand IC\_LEFT } & {\footnotesize return IC\_LEFT;}\tabularnewline
\hline 
{\footnotesize LABEL} & {\footnotesize IC\_LABEL() } & {\footnotesize Label} & {\footnotesize IC\_LABEL:}\tabularnewline
\hline 
{\footnotesize GOTO} & {\footnotesize IC\_LABEL() } & {\footnotesize Goto label} & {\footnotesize goto IC\_LABEL();}\tabularnewline
\hline 
{\footnotesize '+'} & {\footnotesize IC\_LEFT() IC\_RIGHT() IC\_RESULT()} & {\footnotesize Addition} & {\footnotesize IC\_RESULT = IC\_LEFT + IC\_RIGHT}\tabularnewline
\hline 
{\footnotesize '-'} & {\footnotesize IC\_LEFT() IC\_RIGHT() IC\_RESULT()} & {\footnotesize Subtraction} & {\footnotesize IC\_RESULT = IC\_LEFT - IC\_RIGHT }\tabularnewline
\hline 
{\footnotesize '{*}'} & {\footnotesize IC\_LEFT() IC\_RIGHT() IC\_RESULT()} & {\footnotesize Multiplication } & {\footnotesize IC\_RESULT = IC\_LEFT {*} IC\_RIGHT;}\tabularnewline
\hline 
{\footnotesize '/'} & {\footnotesize IC\_LEFT() IC\_RIGHT() IC\_RESULT()} & {\footnotesize Division} & {\footnotesize IC\_RESULT = IC\_LEFT / IC\_RIGHT;}\tabularnewline
\hline 
{\footnotesize '\%'} & {\footnotesize IC\_LEFT() IC\_RIGHT() IC\_RESULT()} & {\footnotesize Modulus} & {\footnotesize IC\_RESULT = IC\_LEFT \% IC\_RIGHT;}\tabularnewline
\hline 
{\footnotesize '<'} & {\footnotesize IC\_LEFT() IC\_RIGHT() IC\_RESULT()} & {\footnotesize Less than} & {\footnotesize IC\_RESULT = IC\_LEFT < IC\_RIGHT;}\tabularnewline
\hline 
{\footnotesize '>'} & {\footnotesize IC\_LEFT() IC\_RIGHT() IC\_RESULT()} & {\footnotesize Greater than } & {\footnotesize IC\_RESULT = IC\_LEFT > IC\_RIGHT;}\tabularnewline
\hline 
{\footnotesize EQ\_OP} & {\footnotesize IC\_LEFT() IC\_RIGHT() IC\_RESULT()} & {\footnotesize Equal to } & {\footnotesize IC\_RESULT = IC\_LEFT == IC\_RIGHT;}\tabularnewline
\hline 
{\footnotesize AND\_OP} & {\footnotesize IC\_LEFT() IC\_RIGHT() IC\_RESULT() } & {\footnotesize Logical and operation} & {\footnotesize IC\_RESULT = IC\_LEFT \&\& IC\_RIGHT; }\tabularnewline
\hline 
{\footnotesize OR\_OP} & {\footnotesize IC\_LEFT() IC\_RIGHT() IC\_RESULT() } & {\footnotesize Logical or operation } & {\footnotesize IC\_RESULT = IC\_LEFT || IC\_RIGHT; }\tabularnewline
\hline 
{\footnotesize '\textasciicircum '} & {\footnotesize IC\_LEFT() IC\_RIGHT() IC\_RESULT() } & {\footnotesize Exclusive OR} & {\footnotesize IC\_RESULT = IC\_LEFT \textasciicircum{} IC\_RIGHT;}\tabularnewline
\hline 
{\footnotesize '|'} & {\footnotesize IC\_LEFT() IC\_RIGHT() IC\_RESULT() } & {\footnotesize Bitwise OR } & {\footnotesize IC\_RESULT = IC\_LEFT | IC\_RIGHT;}\tabularnewline
\hline 
{\footnotesize BITWISEAND} & {\footnotesize IC\_LEFT() IC\_RIGHT() IC\_RESULT()} & {\footnotesize Bitwise AND } & {\footnotesize IC\_RESULT = IC\_LEFT \& IC\_RIGHT;}\tabularnewline
\hline 
{\footnotesize LEFT\_OP} & {\footnotesize IC\_LEFT() IC\_RIGHT() IC\_RESULT()} & {\footnotesize Left shift } & {\footnotesize IC\_RESULT = IC\_LEFT <\textcompwordmark < IC\_RIGHT }\tabularnewline
\hline 
{\footnotesize RIGHT\_OP} & {\footnotesize IC\_LEFT() IC\_RIGHT() IC\_RESULT()} & {\footnotesize Right shift} & {\footnotesize IC\_RESULT = IC\_LEFT >\textcompwordmark > IC\_RIGHT }\tabularnewline
\hline 
{\footnotesize GET\_VALUE\_}\newline
{\footnotesize AT\_ ADDRESS} & {\footnotesize IC\_LEFT() IC\_RESULT()} & {\footnotesize Indirect fetch } & {\footnotesize IC\_RESULT = ({*}IC\_LEFT);}\tabularnewline
\hline 
{\footnotesize POINTER\_SET} & {\footnotesize IC\_RIGHT() IC\_RESULT() } & {\footnotesize Indirect set} & {\footnotesize ({*}IC\_RESULT) = IC\_RIGHT;}\tabularnewline
\hline 
{\footnotesize '='} & {\footnotesize IC\_RIGHT() IC\_RESULT()} & {\footnotesize Assignment} & {\footnotesize IC\_RESULT = IC\_RIGHT;}\tabularnewline
\hline 
{\footnotesize IFX} & {\footnotesize IC\_COND IC\_TRUE IC\_LABEL} & {\footnotesize Conditional jump. If true label is present then jump
to true label if condition is true else jump to false label if condition
is false } & {\footnotesize if (IC\_COND) goto IC\_TRUE; }\newline
{\footnotesize ~~Or }\newline
{\footnotesize If (!IC\_COND) goto IC\_FALSE;}\tabularnewline
\hline 
{\footnotesize ADDRESS\_OF} & {\footnotesize IC\_LEFT() IC\_RESULT()} & {\footnotesize Address of } & {\footnotesize IC\_RESULT = \&IC\_LEFT();}\tabularnewline
\hline 
{\footnotesize JUMPTABLE} & {\footnotesize IC\_JTCOND IC\_JTLABELS} & {\footnotesize Jump to list of labels depending on the value of JTCOND} & {\footnotesize Switch statement}\tabularnewline
\hline 
{\footnotesize CAST} & {\footnotesize IC\_RIGHT() IC\_LEFT() IC\_RESULT()} & {\footnotesize Cast types } & {\footnotesize IC\_RESULT = (typeof IC\_LEFT) IC\_RIGHT;}\tabularnewline
\hline 
{\footnotesize SEND} & {\footnotesize IC\_LEFT()} & {\footnotesize This is used for passing parameters in registers; }\newline
{\footnotesize move IC\_LEFT to the next available parameter register.} & {\footnotesize None}\tabularnewline
\hline 
{\footnotesize RECV} & {\footnotesize IC\_RESULT()} & {\footnotesize This is used for receiving parameters passed in registers;}\newline
{\footnotesize Move the values in the next parameter register to IC\_RESULT } & {\footnotesize None}\tabularnewline
\hline 
{\footnotesize\textsl{(some more have been added)}} &  &  & {\footnotesize\textsl{see f.e.}}{\footnotesize{} }{\footnotesize\texttt{\textsl{gen51Code()}}}{\footnotesize{}
}{\footnotesize\textsl{in}}{\footnotesize{} }{\footnotesize\texttt{\textsl{src/mcs51/gen.c}}}\tabularnewline
\hline 
\end{longtable}}{\footnotesize\par}


\paragraph*{ICode Example\index{iCode}}

This section shows some details of iCode. The example C code does
not do anything useful; it is used as an example to illustrate the
intermediate code generated by the compiler.
\begin{verse}
\texttt{1.~\_\_xdata int {*} p;}~\\
\texttt{2.~int gint;}~\\
\texttt{3.~/{*} This function does nothing useful. It is used}~\\
\texttt{4.~~~~for the purpose of explaining iCode {*}/}~\\
\texttt{5.~short function (\_\_data int {*}x)}~\\
\texttt{6.~\{}~\\
\texttt{7.~~~short i=10; ~~/{*} dead initialization eliminated
{*}/}~\\
\texttt{8.~~~short sum=10; /{*} dead initialization eliminated
{*}/}~\\
\texttt{9.~~~short mul;}~\\
\texttt{10.~~int j ;}~\\
\texttt{11.~~while ({*}x) {*}x++ = {*}p++;}~\\
\texttt{12.~~~~sum = 0 ;}~\\
\texttt{13.~~mul = 0;}~\\
\texttt{14.~~/{*} compiler detects i,j to be induction variables
{*}/}~\\
\texttt{15.~~for (i = 0, j = 10 ; i < 10 ; i++, j}-\/-\texttt{)
\{}~\\
\texttt{16.~~~~sum += i;}~\\
\texttt{17.~~~~mul += i {*} 3; ~~/{*} this multiplication remains
{*}/}~\\
\texttt{18.~~~~gint += j {*} 3;~~/{*} this multiplication changed
to addition {*}/}~\\
\texttt{19.~~\}}~\\
\texttt{20.~~return sum+mul;}~\\
\texttt{21.~\}}
\end{verse}
In addition to the operands each iCode contains information about
the filename and line it corresponds to in the source file. The first
field in the listing should be interpreted as follows:\\
{\footnotesize\textit{Filename(linenumber: iCode Execution sequence
number : ICode hash table key : loop depth of the iCode).}}\\
Then follows the human readable form of the ICode operation. Each
operand of this triplet form can be of three basic types a) compiler
generated temporary b) user defined variable c) a constant value.
Note that local variables and parameters are replaced by compiler
generated temporaries. Live ranges\index{Live range analysis} are
computed only for temporaries (i.e. live ranges are not computed for
global variables). Registers\index{Register allocation} are allocated
for temporaries only. Operands are formatted in the following manner:\\
{\footnotesize\textit{Operand Name {[}lr live-from : live-to {]} \{
type information \} {[} registers allocated {]}.}}\\
As mentioned earlier the live ranges are computed in terms of the
execution sequence number of the iCodes, for example \\
the iTemp0 is live from (i.e. first defined in iCode with execution
sequence number 3, and is last used in the iCode with sequence number
5). For induction variables such as iTemp21 the live range computation
extends the lifetime from the start to the end of the loop.\\
The register allocator used the live range information to allocate
registers, the same registers may be used for different temporaries
if their live ranges do not overlap, for example r0 is allocated to
both iTemp6 and to iTemp17 since their live ranges do not overlap.
In addition the allocator also takes into consideration the type and
usage of a temporary, for example itemp6 is a pointer to near space
and is used as to fetch data from (i.e. used in GET\_VALUE\_AT\_ADDRESS)
so it is allocated a pointer register (r0). Some short lived temporaries
are allocated to special registers which have meaning to the code
generator e.g. iTemp13 is allocated to a pseudo register CC which
tells the back end that the temporary is used only for a conditional
jump the code generation makes use of this information to optimize
a compare and jump ICode.\\
There are several loop optimizations\index{Loop optimization} performed
by the compiler. It can detect induction variables iTemp21(i) and
iTemp23(j). Also note the compiler does selective strength reduction\index{Strength reduction},
i.e. the multiplication of an induction variable in line 18 (gint
= j {*} 3) is changed to addition, a new temporary iTemp17 is allocated
and assigned a initial value, a constant 3 is then added for each
iteration of the loop. The compiler does not change the multiplication\index{Multiplication}
in line 17 however since the processor does support an 8 {*} 8 bit
multiplication.\\
Note the dead code elimination\index{Dead-code elimination} optimization
eliminated the dead assignments in line 7 \& 8 to I and sum respectively.\\

{\footnotesize Sample.c (5:1:0:0) \_entry(\$9) :}{\footnotesize\par}

{\footnotesize Sample.c(5:2:1:0) proc \_function {[}lr0:0{]}\{function
short\}}{\footnotesize\par}

{\footnotesize Sample.c(11:3:2:0) iTemp0 {[}lr3:5{]}\{\_near {*} int\}{[}r2{]}
= recv }{\footnotesize\par}

{\footnotesize Sample.c(11:4:53:0) preHeaderLbl0(\$11) :}{\footnotesize\par}

{\footnotesize Sample.c(11:5:55:0) iTemp6 {[}lr5:16{]}\{\_near {*}
int\}{[}r0{]} := iTemp0 {[}lr3:5{]}\{\_near {*} int\}{[}r2{]}}{\footnotesize\par}

{\footnotesize Sample.c(11:6:5:1) \_whilecontinue\_0(\$1) :}{\footnotesize\par}

{\footnotesize Sample.c(11:7:7:1) iTemp4 {[}lr7:8{]}\{int\}{[}r2 r3{]}
= @{[}iTemp6 {[}lr5:16{]}\{\_near {*} int\}{[}r0{]}{]}}{\footnotesize\par}

{\footnotesize Sample.c(11:8:8:1) if iTemp4 {[}lr7:8{]}\{int\}{[}r2
r3{]} == 0 goto \_whilebreak\_0(\$3)}{\footnotesize\par}

{\footnotesize Sample.c(11:9:14:1) iTemp7 {[}lr9:13{]}\{\_far {*} int\}{[}DPTR{]}
:= \_p {[}lr0:0{]}\{\_far {*} int\}}{\footnotesize\par}

{\footnotesize Sample.c(11:10:15:1) \_p {[}lr0:0{]}\{\_far {*} int\}
= \_p {[}lr0:0{]}\{\_far {*} int\} + 0x2 \{short\}}{\footnotesize\par}

{\footnotesize Sample.c(11:13:18:1) iTemp10 {[}lr13:14{]}\{int\}{[}r2
r3{]} = @{[}iTemp7 {[}lr9:13{]}\{\_far {*} int\}{[}DPTR{]}{]}}{\footnotesize\par}

{\footnotesize Sample.c(11:14:19:1) {*}(iTemp6 {[}lr5:16{]}\{\_near
{*} int\}{[}r0{]}) := iTemp10 {[}lr13:14{]}\{int\}{[}r2 r3{]}}{\footnotesize\par}

{\footnotesize Sample.c(11:15:12:1) iTemp6 {[}lr5:16{]}\{\_near {*}
int\}{[}r0{]} = iTemp6 {[}lr5:16{]}\{\_near {*} int\}{[}r0{]} + 0x2
\{short\}}{\footnotesize\par}

{\footnotesize Sample.c(11:16:20:1) goto \_whilecontinue\_0(\$1)}{\footnotesize\par}

{\footnotesize Sample.c(11:17:21:0)\_whilebreak\_0(\$3) :}{\footnotesize\par}

{\footnotesize Sample.c(12:18:22:0) iTemp2 {[}lr18:40{]}\{short\}{[}r2{]}
:= 0x0 \{short\}}{\footnotesize\par}

{\footnotesize Sample.c(13:19:23:0) iTemp11 {[}lr19:40{]}\{short\}{[}r3{]}
:= 0x0 \{short\}}{\footnotesize\par}

{\footnotesize Sample.c(15:20:54:0)preHeaderLbl1(\$13) :}{\footnotesize\par}

{\footnotesize Sample.c(15:21:56:0) iTemp21 {[}lr21:38{]}\{short\}{[}r4{]}
:= 0x0 \{short\}}{\footnotesize\par}

{\footnotesize Sample.c(15:22:57:0) iTemp23 {[}lr22:38{]}\{int\}{[}r5
r6{]} := 0xa \{int\}}{\footnotesize\par}

{\footnotesize Sample.c(15:23:58:0) iTemp17 {[}lr23:38{]}\{int\}{[}r7
r0{]} := 0x1e \{int\}}{\footnotesize\par}

{\footnotesize Sample.c(15:24:26:1)\_forcond\_0(\$4) :}{\footnotesize\par}

{\footnotesize Sample.c(15:25:27:1) iTemp13 {[}lr25:26{]}\{char\}{[}CC{]}
= iTemp21 {[}lr21:38{]}\{short\}{[}r4{]} < 0xa \{short\}}{\footnotesize\par}

{\footnotesize Sample.c(15:26:28:1) if iTemp13 {[}lr25:26{]}\{char\}{[}CC{]}
== 0 goto \_forbreak\_0(\$7)}{\footnotesize\par}

{\footnotesize Sample.c(16:27:31:1) iTemp2 {[}lr18:40{]}\{short\}{[}r2{]}
= iTemp2 {[}lr18:40{]}\{short\}{[}r2{]} + ITemp21 {[}lr21:38{]}\{short\}{[}r4{]}}{\footnotesize\par}

{\footnotesize Sample.c(17:29:33:1) iTemp15 {[}lr29:30{]}\{short\}{[}r1{]}
= iTemp21 {[}lr21:38{]}\{short\}{[}r4{]} {*} 0x3 \{short\}}{\footnotesize\par}

{\footnotesize Sample.c(17:30:34:1) iTemp11 {[}lr19:40{]}\{short\}{[}r3{]}
= iTemp11 {[}lr19:40{]}\{short\}{[}r3{]} + iTemp15 {[}lr29:30{]}\{short\}{[}r1{]}}{\footnotesize\par}

{\footnotesize Sample.c(18:32:36:1:1) iTemp17 {[}lr23:38{]}\{int\}{[}r7
r0{]}= iTemp17 {[}lr23:38{]}\{int\}{[}r7 r0{]}- 0x3 \{short\}}{\footnotesize\par}

{\footnotesize Sample.c(18:33:37:1) \_gint {[}lr0:0{]}\{int\} = \_gint
{[}lr0:0{]}\{int\} + iTemp17 {[}lr23:38{]}\{int\}{[}r7 r0{]}}{\footnotesize\par}

{\footnotesize Sample.c(15:36:42:1) iTemp21 {[}lr21:38{]}\{short\}{[}r4{]}
= iTemp21 {[}lr21:38{]}\{short\}{[}r4{]} + 0x1 \{short\}}{\footnotesize\par}

{\footnotesize Sample.c(15:37:45:1) iTemp23 {[}lr22:38{]}\{int\}{[}r5
r6{]}= iTemp23 {[}lr22:38{]}\{int\}{[}r5 r6{]}- 0x1 \{short\}}{\footnotesize\par}

{\footnotesize Sample.c(19:38:47:1) goto \_forcond\_0(\$4)}{\footnotesize\par}

{\footnotesize Sample.c(19:39:48:0)\_forbreak\_0(\$7) :}{\footnotesize\par}

{\footnotesize Sample.c(20:40:49:0) iTemp24 {[}lr40:41{]}\{short\}{[}DPTR{]}
= iTemp2 {[}lr18:40{]}\{short\}{[}r2{]} + ITemp11 {[}lr19:40{]}\{short\}{[}r3{]}}{\footnotesize\par}

{\footnotesize Sample.c(20:41:50:0) ret iTemp24 {[}lr40:41{]}\{short\}}{\footnotesize\par}

{\footnotesize Sample.c(20:42:51:0)\_return(\$8) :}{\footnotesize\par}

{\footnotesize Sample.c(20:43:52:0) eproc \_function {[}lr0:0{]}\{
ia0 re0 rm0\}\{function short\}}\\
\\
Finally the code generated for this function:\\

{\footnotesize .area DSEG (DATA)}{\footnotesize\par}

{\footnotesize\_p::}{\footnotesize\par}

{\footnotesize ~~.ds 2}{\footnotesize\par}

{\footnotesize\_gint::}{\footnotesize\par}

{\footnotesize ~~.ds 2}{\footnotesize\par}

{\footnotesize ; sample.c 5}{\footnotesize\par}

{\footnotesize ; ———————————————-}{\footnotesize\par}

{\footnotesize ; function function}{\footnotesize\par}

{\footnotesize ; ———————————————-}{\footnotesize\par}

{\footnotesize\_function:}{\footnotesize\par}

{\footnotesize ; iTemp0 {[}lr3:5{]}\{\_near {*} int\}{[}r2{]} = recv }{\footnotesize\par}

{\footnotesize ~~mov r2,dpl}{\footnotesize\par}

{\footnotesize ; iTemp6 {[}lr5:16{]}\{\_near {*} int\}{[}r0{]} := iTemp0
{[}lr3:5{]}\{\_near {*} int\}{[}r2{]}}{\footnotesize\par}

{\footnotesize ~~mov ar0,r2}{\footnotesize\par}

{\footnotesize ;\_whilecontinue\_0(\$1) :}{\footnotesize\par}

{\footnotesize 00101\$:}{\footnotesize\par}

{\footnotesize ; iTemp4 {[}lr7:8{]}\{int\}{[}r2 r3{]} = @{[}iTemp6
{[}lr5:16{]}\{\_near {*} int\}{[}r0{]}{]}}{\footnotesize\par}

{\footnotesize ; if iTemp4 {[}lr7:8{]}\{int\}{[}r2 r3{]} == 0 goto
\_whilebreak\_0(\$3)}{\footnotesize\par}

{\footnotesize ~~mov ar2,@r0}{\footnotesize\par}

{\footnotesize ~~inc r0}{\footnotesize\par}

{\footnotesize ~~mov ar3,@r0}{\footnotesize\par}

{\footnotesize ~~dec r0}{\footnotesize\par}

{\footnotesize ~~mov a,r2}{\footnotesize\par}

{\footnotesize ~~orl a,r3}{\footnotesize\par}

{\footnotesize ~~jz 00103\$}{\footnotesize\par}

{\footnotesize 00114\$:}{\footnotesize\par}

{\footnotesize ; iTemp7 {[}lr9:13{]}\{\_far {*} int\}{[}DPTR{]} :=
\_p {[}lr0:0{]}\{\_far {*} int\}}{\footnotesize\par}

{\footnotesize ~~mov dpl,\_p}{\footnotesize\par}

{\footnotesize ~~mov dph,(\_p + 1)}{\footnotesize\par}

{\footnotesize ; \_p {[}lr0:0{]}\{\_far {*} int\} = \_p {[}lr0:0{]}\{\_far
{*} int\} + 0x2 \{short\}}{\footnotesize\par}

{\footnotesize ~~mov a,\#0x02}{\footnotesize\par}

{\footnotesize ~~add a,\_p}{\footnotesize\par}

{\footnotesize ~~mov \_p,a}{\footnotesize\par}

{\footnotesize ~~clr a}{\footnotesize\par}

{\footnotesize ~~addc a,(\_p + 1)}{\footnotesize\par}

{\footnotesize ~~mov (\_p + 1),a}{\footnotesize\par}

{\footnotesize ; iTemp10 {[}lr13:14{]}\{int\}{[}r2 r3{]} = @{[}iTemp7
{[}lr9:13{]}\{\_far {*} int\}{[}DPTR{]}{]}}{\footnotesize\par}

{\footnotesize ~~movx a,@dptr}{\footnotesize\par}

{\footnotesize ~~mov r2,a}{\footnotesize\par}

{\footnotesize ~~inc dptr}{\footnotesize\par}

{\footnotesize ~~movx a,@dptr}{\footnotesize\par}

{\footnotesize ~~mov r3,a}{\footnotesize\par}

{\footnotesize ; {*}(iTemp6 {[}lr5:16{]}\{\_near {*} int\}{[}r0{]})
:= iTemp10 {[}lr13:14{]}\{int\}{[}r2 r3{]}}{\footnotesize\par}

{\footnotesize ~~mov @r0,ar2}{\footnotesize\par}

{\footnotesize ~~inc r0}{\footnotesize\par}

{\footnotesize ~~mov @r0,ar3}{\footnotesize\par}

{\footnotesize ; iTemp6 {[}lr5:16{]}\{\_near {*} int\}{[}r0{]} = }{\footnotesize\par}

{\footnotesize ; iTemp6 {[}lr5:16{]}\{\_near {*} int\}{[}r0{]} + }{\footnotesize\par}

{\footnotesize ; 0x2 \{short\}}{\footnotesize\par}

{\footnotesize ~~inc r0}{\footnotesize\par}

{\footnotesize ; goto \_whilecontinue\_0(\$1)}{\footnotesize\par}

{\footnotesize ~~sjmp 00101\$}{\footnotesize\par}

{\footnotesize ; \_whilebreak\_0(\$3) :}{\footnotesize\par}

{\footnotesize 00103\$:}{\footnotesize\par}

{\footnotesize ; iTemp2 {[}lr18:40{]}\{short\}{[}r2{]} := 0x0 \{short\}}{\footnotesize\par}

{\footnotesize ~~mov r2,\#0x00}{\footnotesize\par}

{\footnotesize ; iTemp11 {[}lr19:40{]}\{short\}{[}r3{]} := 0x0 \{short\}}{\footnotesize\par}

{\footnotesize ~~mov r3,\#0x00}{\footnotesize\par}

{\footnotesize ; iTemp21 {[}lr21:38{]}\{short\}{[}r4{]} := 0x0 \{short\}}{\footnotesize\par}

{\footnotesize ~~mov r4,\#0x00}{\footnotesize\par}

{\footnotesize ; iTemp23 {[}lr22:38{]}\{int\}{[}r5 r6{]} := 0xa \{int\}}{\footnotesize\par}

{\footnotesize ~~mov r5,\#0x0A}{\footnotesize\par}

{\footnotesize ~~mov r6,\#0x00}{\footnotesize\par}

{\footnotesize ; iTemp17 {[}lr23:38{]}\{int\}{[}r7 r0{]} := 0x1e \{int\}}{\footnotesize\par}

{\footnotesize ~~mov r7,\#0x1E}{\footnotesize\par}

{\footnotesize ~~mov r0,\#0x00}{\footnotesize\par}

{\footnotesize ; \_forcond\_0(\$4) :}{\footnotesize\par}

{\footnotesize 00104\$:}{\footnotesize\par}

{\footnotesize ; iTemp13 {[}lr25:26{]}\{char\}{[}CC{]} = iTemp21 {[}lr21:38{]}\{short\}{[}r4{]}
< 0xa \{short\}}{\footnotesize\par}

{\footnotesize ; if iTemp13 {[}lr25:26{]}\{char\}{[}CC{]} == 0 goto
\_forbreak\_0(\$7)}{\footnotesize\par}

{\footnotesize ~~clr c}{\footnotesize\par}

{\footnotesize ~~mov a,r4}{\footnotesize\par}

{\footnotesize ~~xrl a,\#0x80}{\footnotesize\par}

{\footnotesize ~~subb a,\#0x8a}{\footnotesize\par}

{\footnotesize ~~jnc 00107\$}{\footnotesize\par}

{\footnotesize 00115\$:}{\footnotesize\par}

{\footnotesize ; iTemp2 {[}lr18:40{]}\{short\}{[}r2{]} = iTemp2 {[}lr18:40{]}\{short\}{[}r2{]}
+ }{\footnotesize\par}

{\footnotesize ; iTemp21 {[}lr21:38{]}\{short\}{[}r4{]}}{\footnotesize\par}

{\footnotesize ~~mov a,r4}{\footnotesize\par}

{\footnotesize ~~add a,r2}{\footnotesize\par}

{\footnotesize ~~mov r2,a}{\footnotesize\par}

{\footnotesize ; iTemp15 {[}lr29:30{]}\{short\}{[}r1{]} = iTemp21 {[}lr21:38{]}\{short\}{[}r4{]}
{*} 0x3 \{short\}}{\footnotesize\par}

{\footnotesize ~~mov b,\#0x03}{\footnotesize\par}

{\footnotesize ~~mov a,r4}{\footnotesize\par}

{\footnotesize ~~mul ab}{\footnotesize\par}

{\footnotesize ~~mov r1,a}{\footnotesize\par}

{\footnotesize ; iTemp11 {[}lr19:40{]}\{short\}{[}r3{]} = iTemp11 {[}lr19:40{]}\{short\}{[}r3{]}
+ }{\footnotesize\par}

{\footnotesize ; iTemp15 {[}lr29:30{]}\{short\}{[}r1{]}}{\footnotesize\par}

{\footnotesize ~~add a,r3}{\footnotesize\par}

{\footnotesize ~~mov r3,a}{\footnotesize\par}

{\footnotesize ; iTemp17 {[}lr23:38{]}\{int\}{[}r7 r0{]}= iTemp17 {[}lr23:38{]}\{int\}{[}r7
r0{]}- 0x3 \{short\}}{\footnotesize\par}

{\footnotesize ~~mov a,r7}{\footnotesize\par}

{\footnotesize ~~add a,\#0xfd}{\footnotesize\par}

{\footnotesize ~~mov r7,a}{\footnotesize\par}

{\footnotesize ~~mov a,r0}{\footnotesize\par}

{\footnotesize ~~addc a,\#0xff}{\footnotesize\par}

{\footnotesize ~~mov r0,a}{\footnotesize\par}

{\footnotesize ; \_gint {[}lr0:0{]}\{int\} = \_gint {[}lr0:0{]}\{int\}
+ iTemp17 {[}lr23:38{]}\{int\}{[}r7 r0{]}}{\footnotesize\par}

{\footnotesize ~~mov a,r7}{\footnotesize\par}

{\footnotesize ~~add a,\_gint}{\footnotesize\par}

{\footnotesize ~~mov \_gint,a}{\footnotesize\par}

{\footnotesize ~~mov a,r0}{\footnotesize\par}

{\footnotesize ~~addc a,(\_gint + 1)}{\footnotesize\par}

{\footnotesize ~~mov (\_gint + 1),a}{\footnotesize\par}

{\footnotesize ; iTemp21 {[}lr21:38{]}\{short\}{[}r4{]} = iTemp21 {[}lr21:38{]}\{short\}{[}r4{]}
+ 0x1 \{short\}}{\footnotesize\par}

{\footnotesize ~~inc r4}{\footnotesize\par}

{\footnotesize ; iTemp23 {[}lr22:38{]}\{int\}{[}r5 r6{]}= iTemp23 {[}lr22:38{]}\{int\}{[}r5
r6{]}- 0x1 \{short\}}{\footnotesize\par}

{\footnotesize ~~dec r5}{\footnotesize\par}

{\footnotesize ~~cjne r5,\#0xff,00104\$}{\footnotesize\par}

{\footnotesize ~~dec r6}{\footnotesize\par}

{\footnotesize ; goto \_forcond\_0(\$4)}{\footnotesize\par}

{\footnotesize ~~sjmp 00104\$}{\footnotesize\par}

{\footnotesize ; \_forbreak\_0(\$7) :}{\footnotesize\par}

{\footnotesize 00107\$:}{\footnotesize\par}

{\footnotesize ; ret iTemp24 {[}lr40:41{]}\{short\}}{\footnotesize\par}

{\footnotesize ~~mov a,r3}{\footnotesize\par}

{\footnotesize ~~add a,r2}{\footnotesize\par}

{\footnotesize ~~mov dpl,a}{\footnotesize\par}

{\footnotesize ; \_return(\$8) :}{\footnotesize\par}

{\footnotesize 00108\$:}{\footnotesize\par}

{\footnotesize ~~ret}\\
{\footnotesize\par}

\section{A few words about basic block successors, predecessors and dominators}

Successors are basic blocks\index{Basic blocks} that might execute
after this basic block.\\
Predecessors are basic blocks that might execute before reaching this
basic block.\\
Dominators are basic blocks that WILL execute before reaching this
basic block.\\

{[}basic block 1{]}

if (something)

~~~~{[}basic block 2{]}

else

~~~~{[}basic block 3{]}

{[}basic block 4{]}\\

a) succList of {[}BB2{]} = {[}BB4{]}, of {[}BB3{]} = {[}BB4{]}, of
{[}BB1{]} = {[}BB2,BB3{]}

b) predList of {[}BB2{]} = {[}BB1{]}, of {[}BB3{]} = {[}BB1{]}, of
{[}BB4{]} = {[}BB2,BB3{]}

c) domVect of {[}BB4{]} = BB1 ... here we are not sure if BB2 or BB3
was executed but we are SURE that BB1 was executed.

\chapter{Acknowledgments}

\url{http://sdcc.sourceforge.net/\#Who}\\
\\
\emph{Thanks to all the other volunteer developers who have helped
with coding, testing, web-page creation, distribution sets, etc. You
know who you are :-)}\\
\\
\emph{Thanks to Sourceforge \url{http://sourceforge.net/} which has
hosted the project since 1999 and donates significant download bandwidth.}\\
\\
\emph{Also thanks to all SDCC Distributed Compile Farm members for
donating CPU cycles and bandwidth for snapshot builds.}\\

This document was initially written by Sandeep Dutta and updated by
SDCC developers.

All product names mentioned herein may be trademarks\index{Trademarks}
of their respective companies. 

\section*{Alphabetical index}

To avoid confusion, the installation and building options for SDCC
itself (chapter 2) are not part of the index.

\printindex
\end{document}
