designed for 8 bit Microprocessors.
The current version targets Intel MCS51 based Microprocessors (8031, 8032,
8051, 8052
\begin_inset LatexCommand \index{8031, 8032, 8051, 8052, mcs51 CPU}
designed for 8 bit Microprocessors.
The current version targets Intel MCS51 based Microprocessors (8031, 8032,
8051, 8052
\begin_inset LatexCommand \index{8031, 8032, 8051, 8052, mcs51 CPU}
, etc.), Dallas DS80C390 variants, Freescale (formerly Motorola) HC08 and
Zilog Z80 based MCUs.
, etc.), Dallas DS80C390 variants, Freescale (formerly Motorola) HC08 and
Zilog Z80 based MCUs.
SDCC uses ASXXXX
\begin_inset LatexCommand \index{asXXXX (as-gbz80, as-hc08, asx8051, as-z80)}
SDCC uses ASXXXX
\begin_inset LatexCommand \index{asXXXX (as-gbz80, as-hc08, asx8051, as-z80)}
, an open source retargetable assembler & linker.
SDCC has extensive language extensions suitable for utilizing various microcont
rollers and underlying hardware effectively.
, an open source retargetable assembler & linker.
SDCC has extensive language extensions suitable for utilizing various microcont
rollers and underlying hardware effectively.
For the back-end SDCC uses a global register allocation scheme which should
be well suited for other 8 bit MCUs.
For the back-end SDCC uses a global register allocation scheme which should
be well suited for other 8 bit MCUs.
<lyxtabular version="3" rows="8" columns="5">
<features>
<column alignment="center" valignment="top" leftline="true" width="0">
<lyxtabular version="3" rows="8" columns="5">
<features>
<column alignment="center" valignment="top" leftline="true" width="0">
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
to be embedded anywhere in a function.
In addition, routines developed in assembly can also be called.
to be embedded anywhere in a function.
In addition, routines developed in assembly can also be called.
-cyclomatic) to report the relative complexity of a function.
These functions can then be further optimized, or hand coded in assembly
if needed.
-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 freeware simulator for 8051 and other micro-controllers.<
SDCC also comes with a companion source level debugger SDCDB, the debugger
currently uses ucSim a freeware simulator for 8051 and other micro-controllers.<
The latest version can be downloaded from
\begin_inset LatexCommand \url{http://sdcc.sourceforge.net/snap.php}
The latest version can be downloaded from
\begin_inset LatexCommand \url{http://sdcc.sourceforge.net/snap.php}
; source code for all the sub-packages (pre-processor, assemblers, linkers
etc) is distributed with the package.
This documentation is maintained using a freeware word processor (LyX).
; source code for all the sub-packages (pre-processor, assemblers, linkers
etc) is distributed with the package.
This documentation is maintained using a freeware word processor (LyX).
-\newline
-This program is free software; you can redistribute it and/or modify it
- under the terms of the GNU General Public License
+\newline
+This
+ program is free software; you can redistribute it and/or modify it under
+ the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2, or (at
your option) any later version.
as published by the Free Software Foundation; either version 2, or (at
your option) any later version.
of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
You are forbidden to forbid anyone else to use, share and improve what
you give them.
Help stamp out software-hoarding!
You are forbidden to forbid anyone else to use, share and improve what
you give them.
Help stamp out software-hoarding!
Throughout this manual, we will use the following convention.
Commands you have to type in are printed in
Throughout this manual, we will use the following convention.
Commands you have to type in are printed in
This version has numerous bug fixes compared with the previous version.
But we also introduced some incompatibilities with older versions.
Not just for the fun of it, but to make the compiler more stable, efficient
and ANSI compliant
\begin_inset LatexCommand \index{ANSI-compliance}
This version has numerous bug fixes compared with the previous version.
But we also introduced some incompatibilities with older versions.
Not just for the fun of it, but to make the compiler more stable, efficient
and ANSI compliant
\begin_inset LatexCommand \index{ANSI-compliance}
short is now equivalent to int (16 bits), it used to be equivalent to char
(8 bits) which is not ANSI compliant.
short is now equivalent to int (16 bits), it used to be equivalent to char
(8 bits) which is not ANSI compliant.
the default directory for gcc-builds where include, library and documentation
files are stored is now in /usr/local/share.
the default directory for gcc-builds where include, library and documentation
files are stored is now in /usr/local/share.
char type parameters to vararg
\begin_inset LatexCommand \index{vararg, va\_arg}
char type parameters to vararg
\begin_inset LatexCommand \index{vararg, va\_arg}
types now consistently behave like the C99 _Bool type with respect to type
conversion
\begin_inset LatexCommand \index{type conversion}
types now consistently behave like the C99 _Bool type with respect to type
conversion
\begin_inset LatexCommand \index{type conversion}
.
The most common incompatibility resulting from this change is related to
bit toggling
\begin_inset LatexCommand \index{Bit toggling}
.
The most common incompatibility resulting from this change is related to
bit toggling
\begin_inset LatexCommand \index{Bit toggling}
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
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
For Windows some pre-compiled binary distributions are available for your
convenience.
You should have some experience with command line tools and compiler use.
For Windows some pre-compiled binary distributions are available for your
convenience.
You should have some experience with command line tools and compiler use.
is a great place to find distribution sets.
You can also find links to the user mailing lists that offer help or discuss
is a great place to find distribution sets.
You can also find links to the user mailing lists that offer help or discuss
A pdf version of this document is available at
\begin_inset LatexCommand \url{http://sdcc.sourceforge.net/doc/sdccman.pdf}
A pdf version of this document is available at
\begin_inset LatexCommand \url{http://sdcc.sourceforge.net/doc/sdccman.pdf}
If you want the latest unreleased software, the complete source package
is available directly from Subversion on https://svn.sourceforge.net/svnroot/sdcc
/trunk/sdcc.
If you want the latest unreleased software, the complete source package
is available directly from Subversion on https://svn.sourceforge.net/svnroot/sdcc
/trunk/sdcc.
If you can think of some more, please see the section
\begin_inset LatexCommand \ref{sub:Requesting-Features}
If you can think of some more, please see the section
\begin_inset LatexCommand \ref{sub:Requesting-Features}
For most users it is sufficient to skip to either section
\begin_inset LatexCommand \ref{sub:Building-SDCC-on-Linux}
For most users it is sufficient to skip to either section
\begin_inset LatexCommand \ref{sub:Building-SDCC-on-Linux}
The install paths, search paths and other options are defined when running
'configure'.
The defaults can be overridden by:
The install paths, search paths and other options are defined when running
'configure'.
The defaults can be overridden by:
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.
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.
Furthermore the environment variables CC, CFLAGS, ...
the tools and their arguments can be influenced.
Please see `configure -
\begin_inset ERT
Furthermore the environment variables CC, CFLAGS, ...
the tools and their arguments can be influenced.
Please see `configure -
\begin_inset ERT
-\newline
-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.
+\newline
+The names of the
+ standard libraries STD_LIB, STD_INT_LIB, STD_LONG_LIB, STD_FP_LIB, STD_DS390_LI
+B, STD_XA51_LIB and the environment variables SDCC_DIR_NAME, SDCC_INCLUDE_NAME,
+ SDCC_LIB_NAME are defined by `configure` too.
-\newline
-These configure options are compiled into the binaries, and can only be
- changed by rerunning 'configure' and recompiling SDCC.
+\newline
+These configure options are compiled into the binaries,
+ and can only be changed by rerunning 'configure' and recompiling SDCC.
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
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
See the examples, how to pass the Win32 settings to 'configure'.
The other Win32 builds using Borland, VC or whatever don't use 'configure',
but a header file sdcc_vc_in.h is the same as sdccconf.h built by 'configure'
for Win32.
See the examples, how to pass the Win32 settings to 'configure'.
The other Win32 builds using Borland, VC or whatever don't use 'configure',
but a header file sdcc_vc_in.h is the same as sdccconf.h built by 'configure'
for Win32.
<lyxtabular version="3" rows="9" columns="3">
<features>
<column alignment="block" valignment="top" leftline="true" width="0in">
<lyxtabular version="3" rows="9" columns="3">
<features>
<column alignment="block" valignment="top" leftline="true" width="0in">
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
'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):
'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):
<lyxtabular version="3" rows="4" columns="3">
<features>
<column alignment="block" valignment="top" leftline="true" width="0in">
<lyxtabular version="3" rows="4" columns="3">
<features>
<column alignment="block" valignment="top" leftline="true" width="0in">
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
-C' turns on caching, which gives a little bit extra speed.
However if options are changed, it can be necessary to delete the config.cache
file.
-C' turns on caching, which gives a little bit extra speed.
However if options are changed, it can be necessary to delete the config.cache
file.
<lyxtabular version="3" rows="5" columns="4">
<features>
<column alignment="left" valignment="top" leftline="true" width="0">
<lyxtabular version="3" rows="5" columns="4">
<features>
<column alignment="left" valignment="top" leftline="true" width="0">
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
*compiler, preprocessor, assembler, and linker
*compiler, preprocessor, assembler, and linker
is auto-appended by the compiler, e.g.
small, large, z80, ds390 etc
is auto-appended by the compiler, e.g.
small, large, z80, ds390 etc
<lyxtabular version="3" rows="4" columns="3">
<features>
<column alignment="block" valignment="top" leftline="true" width="0in">
<lyxtabular version="3" rows="4" columns="3">
<features>
<column alignment="block" valignment="top" leftline="true" width="0in">
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
<lyxtabular version="3" rows="6" columns="3">
<features>
<column alignment="block" valignment="top" leftline="true" width="1.5in">
<lyxtabular version="3" rows="6" columns="3">
<features>
<column alignment="block" valignment="top" leftline="true" width="1.5in">
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="left" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
is auto-appended by the compiler (e.g.
small, large, z80, ds390 etc.).
is auto-appended by the compiler (e.g.
small, large, z80, ds390 etc.).
<lyxtabular version="3" rows="6" columns="3">
<features>
<column alignment="block" valignment="top" leftline="true" width="1.7in">
<lyxtabular version="3" rows="6" columns="3">
<features>
<column alignment="block" valignment="top" leftline="true" width="1.7in">
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
Don't delete any of the stray spaces in the table above without checking
the HTML output (last line)!
Don't delete any of the stray spaces in the table above without checking
the HTML output (last line)!
This copies the binary executables, the include files, the libraries and
the documentation to the install directories.
Proceed with section
\begin_inset LatexCommand \ref{sec:Testing-the-SDCC}
This copies the binary executables, the include files, the libraries and
the documentation to the install directories.
Proceed with section
\begin_inset LatexCommand \ref{sec:Testing-the-SDCC}
-\newline
-On OSX 2.x it was reported, that the default gcc (version 3.1 20020420 (prerelease
-)) fails to compile SDCC.
+\newline
+On OSX 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:
Fortunately there's also gcc 2.9.x installed, which works fine.
This compiler can be selected by running 'configure' with:
With the Mingw32 gcc cross compiler it's easy to compile SDCC for Win32.
See section 'Configure Options'.
With the Mingw32 gcc cross compiler it's easy to compile SDCC for Win32.
See section 'Configure Options'.
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'.
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'.
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!
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!
-\newline
-The other good tip is to make sure you have no //c/-style paths anywhere,
- use /cygdrive/c/ instead.
+\newline
+The other good tip is to make sure you have no //c/-styl
+e paths anywhere, use /cygdrive/c/ instead.
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.
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.
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.
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.
either from the SDCC Subversion repository or from the
\begin_inset LatexCommand \url[nightly snapshots]{http://sdcc.sourceforge.net/snap.php}
either from the SDCC Subversion repository or from the
\begin_inset LatexCommand \url[nightly snapshots]{http://sdcc.sourceforge.net/snap.php}
SDCC is distributed with all the projects, workspaces, and files you need
to build it using Visual C++ 6.0/NET (except for SDCDB and ucSim).
The workspace name is 'sdcc.dsw'.
Please note that as it is now, all the executables are created in a folder
called sdcc
SDCC is distributed with all the projects, workspaces, and files you need
to build it using Visual C++ 6.0/NET (except for SDCDB and ucSim).
The workspace name is 'sdcc.dsw'.
Please note that as it is now, all the executables are created in a folder
called sdcc
WARNING: Visual studio is very picky with line terminations; it expects
the 0x0d, 0x0a DOS style line endings, not the 0x0a Unix style line endings.
When using the Subversion repository it's easiest to configure the svn
WARNING: Visual studio is very picky with line terminations; it expects
the 0x0d, 0x0a DOS style line endings, not the 0x0a Unix style line endings.
When using the Subversion repository it's easiest to configure the svn
when opening the sdcc.dsw workspace or any of the *.dsp projects, then you
need to convert the Unix style line endings to DOS style line endings.
To do so you can use the
\begin_inset Quotes sld
when opening the sdcc.dsw workspace or any of the *.dsp projects, then you
need to convert the Unix style line endings to DOS style line endings.
To do so you can use the
\begin_inset Quotes sld
utility freely available on the internet.
Doug Hawkins reported in the sdcc-user list that this works:
utility freely available on the internet.
Doug Hawkins reported in the sdcc-user list that this works:
-\newline
-In order to build SDCC with MSVC you need win32 executables of bison.exe,
- flex.exe, and gawk.exe.
+\newline
+In order to build SDCC with MSVC
+ you need win32 executables of bison.exe, flex.exe, and gawk.exe.
.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!):
.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!):
hard disk PRESERVING the original paths, otherwise bison won't work.
(If you are using WinZip make certain that 'Use folder names' is selected)
hard disk PRESERVING the original paths, otherwise bison won't work.
(If you are using WinZip make certain that 'Use folder names' is selected)
-\newline
-b) In the Visual C++ IDE click Tools, Options, select the Directory tab,
- in 'Show directories for:' select 'Executable files', and in the directories
+\newline
+b)
+ In the Visual C++ IDE click Tools, Options, select the Directory tab, in
+ 'Show directories for:' select 'Executable files', and in the directories
-\newline
-(As a side effect, you get a bunch of Unix utilities that could be useful,
- such as diff and patch.)
-\layout Enumerate
+\newline
+(As a side effect, you get a bunch of Unix utilities that
+ could be useful, such as diff and patch.)
+\end_layout
-\newline
-b) Extract 'bison.exe', 'bison.hairy', 'bison.simple', 'flex.exe', and gawk.exe
- to such directory WITHOUT preserving the original paths.
+\newline
+b) Extract 'bison.exe', 'bison.hairy', 'bison.simple', 'flex.exe', and
+ gawk.exe to such directory WITHOUT preserving the original paths.
-\newline
-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.
+\newline
+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.
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.
-\newline
-e) In the Visual C++ IDE click Tools, Options, select the Directory tab,
+\newline
+e
+) In the Visual C++ IDE click Tools, Options, select the Directory tab,
in 'Show directories for:' select 'Executable files', and in the directories
window add a new path: 'c:
in 'Show directories for:' select 'Executable files', and in the directories
window add a new path: 'c:
That is it.
Open 'sdcc.dsw' in Visual Studio, click 'build all', when it finishes copy
the executables from sdcc
That is it.
Open 'sdcc.dsw' in Visual Studio, click 'build all', when it finishes copy
the executables from sdcc
From the sdcc directory, run the command "make -f Makefile.bcc".
This should regenerate all the .exe files in the bin directory except for
SDCDB and ucSim.
From the sdcc directory, run the command "make -f Makefile.bcc".
This should regenerate all the .exe files in the bin directory except for
SDCDB and ucSim.
If you modify any source files and need to rebuild, be aware that the dependenci
es may not be correctly calculated.
The safest option is to delete all .obj files and run the build again.
From a Cygwin BASH prompt, this can easily be done with the command (be
sure you are in the sdcc directory):
If you modify any source files and need to rebuild, be aware that the dependenci
es may not be correctly calculated.
The safest option is to delete all .obj files and run the build again.
From a Cygwin BASH prompt, this can easily be done with the command (be
sure you are in the sdcc directory):
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:
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:
Adjust your environment variable PATH to include the location of the bin
directory or start sdcc using the full path.
Adjust your environment variable PATH to include the location of the bin
directory or start sdcc using the full path.
SDCC supports the VPATH feature provided by configure and make.
It allows to separate the source and build trees.
Here's an example:
SDCC supports the VPATH feature provided by configure and make.
It allows to separate the source and build trees.
Here's an example:
will create the directory tree will all the necessary Makefiles in ~/sdcc.build.
It automagically computes the variables srcdir, top_srcdir and top_buildir
for each directory.
After running
will create the directory tree will all the necessary Makefiles in ~/sdcc.build.
It automagically computes the variables srcdir, top_srcdir and top_buildir
for each directory.
After running
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
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
Simply copy it to the build directory, edit it, enter `make clean`, `rm
Makefile.dep` and `make`.
Simply copy it to the build directory, edit it, enter `make clean`, `rm
Makefile.dep` and `make`.
-enable-doc to the configure arguments to build the documentation together
with all the other stuff.
You will need several tools (LyX, LaTeX, LaTeX2HTML, pdflatex, dvipdf,
dvips and makeindex) to get the job done.
Another possibility is to change to the doc directory and to type
-enable-doc to the configure arguments to build the documentation together
with all the other stuff.
You will need several tools (LyX, LaTeX, LaTeX2HTML, pdflatex, dvipdf,
dvips and makeindex) to get the job done.
Another possibility is to change to the doc directory and to type
there.
You're invited to make changes and additions to this manual (sdcc/doc/sdccman.ly
x).
Using LyX
\begin_inset LatexCommand \url{http://www.lyx.org}
there.
You're invited to make changes and additions to this manual (sdcc/doc/sdccman.ly
x).
Using LyX
\begin_inset LatexCommand \url{http://www.lyx.org}
as editor is straightforward.
Prebuilt documentation in html and pdf format is available from
\begin_inset LatexCommand \url{http://sdcc.sf.net/snap.php}
as editor is straightforward.
Prebuilt documentation in html and pdf format is available from
\begin_inset LatexCommand \url{http://sdcc.sf.net/snap.php}
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
\begin_inset Foot
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
\begin_inset Foot
It tries to document SDCC for several processor architectures in one document
(commercially these probably would be separate documents/products).
This document
\begin_inset LatexCommand \index{Status of documentation}
It tries to document SDCC for several processor architectures in one document
(commercially these probably would be separate documents/products).
This document
\begin_inset LatexCommand \index{Status of documentation}
currently matches SDCC for mcs51 and DS390 best and does give too few informati
on about f.e.
Z80, PIC14, PIC16 and HC08.
currently matches SDCC for mcs51 and DS390 best and does give too few informati
on about f.e.
Z80, PIC14, PIC16 and HC08.
There are many references pointing away from this documentation.
Don't let this distract you.
If there f.e.
was a reference like
\begin_inset LatexCommand \url{http://www.opencores.org}
There are many references pointing away from this documentation.
Don't let this distract you.
If there f.e.
was a reference like
\begin_inset LatexCommand \url{http://www.opencores.org}
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 (
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 (
).
Make sure that the sdcc program is in the bin folder, if not perhaps something
did not install correctly.
).
Make sure that the sdcc program is in the bin folder, if not perhaps something
did not install correctly.
Make sure the compiler works on a very simple example.
Type in the following test.c program using your favorite
Make sure the compiler works on a very simple example.
Type in the following test.c program using your favorite
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.
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.
.
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
.
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
A thing to try is starting from scratch by unpacking the .tgz source package
again in an empty directory.
Configure it like:
A thing to try is starting from scratch by unpacking the .tgz source package
again in an empty directory.
Configure it like:
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.
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.
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.
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.
This runs the GNU make tool, which automatically compiles all the source
packages into the final installed binary executables.
This runs the GNU make tool, which automatically compiles all the source
packages into the final installed binary executables.
This will install the compiler, other executables libraries and include
files into the appropriate directories.
See sections
\begin_inset LatexCommand \ref{sub:Install-paths}
This will install the compiler, other executables libraries and include
files into the appropriate directories.
See sections
\begin_inset LatexCommand \ref{sub:Install-paths}
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.
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.
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.
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.
the subdirs src and small, large, z80, gbz80 and ds390 with the precompiled
relocatables.
the subdirs src and small, large, z80, gbz80 and ds390 with the precompiled
relocatables.
As development for other processors proceeds, this list will expand to include
executables to support processors like AVR, PIC, etc.
As development for other processors proceeds, this list will expand to include
executables to support processors like AVR, PIC, etc.
This is the actual compiler, it in turn uses the c-preprocessor and invokes
the assembler and linkage editor.
This is the actual compiler, it in turn uses the c-preprocessor and invokes
the assembler and linkage editor.
.
The C preprocessor is used to pull in #include sources, process #ifdef
statements, #defines and so on.
.
The C preprocessor is used to pull in #include sources, process #ifdef
statements, #defines and so on.
This is retargettable assembler & linkage editor, it was developed by Alan
Baldwin.
John Hartman created the version for 8051, and I (Sandeep) have made some
enhancements and bug fixes for it to work properly with SDCC.
This is retargettable assembler & linkage editor, it was developed by Alan
Baldwin.
John Hartman created the version for 8051, and I (Sandeep) have made some
enhancements and bug fixes for it to work properly with SDCC.
is a freeware, opensource simulator developed by Daniel Drotos.
The simulator is built as part of the build process.
For more information visit Daniel's web site at:
\begin_inset LatexCommand \url{http://mazsola.iit.uni-miskolc.hu/~drdani/embedded/s51}
is a freeware, opensource simulator developed by Daniel Drotos.
The simulator is built as part of the build process.
For more information visit Daniel's web site at:
\begin_inset LatexCommand \url{http://mazsola.iit.uni-miskolc.hu/~drdani/embedded/s51}
is the companion source level debugger.
More about SDCDB in section
\begin_inset LatexCommand \ref{cha:Debugging-with-SDCDB}
is the companion source level debugger.
More about SDCDB in section
\begin_inset LatexCommand \ref{cha:Debugging-with-SDCDB}
.
The current version of the debugger uses Daniel's Simulator S51
\begin_inset LatexCommand \index{s51}
.
The current version of the debugger uses Daniel's Simulator S51
\begin_inset LatexCommand \index{s51}
For single source file 8051 projects the process is very simple.
Compile your programs with the following command
For single source file 8051 projects the process is very simple.
Compile your programs with the following command
This will compile, assemble and link your source file.
Output files are as follows:
This will compile, assemble and link your source file.
Output files are as follows:
).
Both formats are documented in the documentation of srecord
\begin_inset LatexCommand \index{srecord (bin, hex, ... tool)}
).
Both formats are documented in the documentation of srecord
\begin_inset LatexCommand \index{srecord (bin, hex, ... tool)}
An optional AOMF or AOMF51
\begin_inset LatexCommand \index{AOMF, AOMF51}
An optional AOMF or AOMF51
\begin_inset LatexCommand \index{AOMF, AOMF51}
In most cases this won't be needed but the Intel Hex file
\begin_inset LatexCommand \index{<file>.ihx}
In most cases this won't be needed but the Intel Hex file
\begin_inset LatexCommand \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
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
package additionally allows to set undefined locations to a predefined
value, to insert checksums
\begin_inset LatexCommand \index{checksum}
package additionally allows to set undefined locations to a predefined
value, to insert checksums
\begin_inset LatexCommand \index{checksum}
of various flavours (crc, add, xor) and to perform other manipulations
(convert, split, crop, offset, ...).
of various flavours (crc, add, xor) and to perform other manipulations
(convert, split, crop, offset, ...).
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
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
SDCC can compile only ONE file at a time.
Let us for example assume that you have a project containing the following
files:
SDCC can compile only ONE file at a time.
Let us for example assume that you have a project containing the following
files:
file specified in the command line, since the linkage editor processes
file in the order they are presented to it.
The linker is invoked from SDCC using a script file with extension .lnk
\begin_inset LatexCommand \index{<file>.lnk}
file specified in the command line, since the linkage editor processes
file in the order they are presented to it.
The linker is invoked from SDCC using a script file with extension .lnk
\begin_inset LatexCommand \index{<file>.lnk}
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
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
library file.
Libraries created in this manner can be included in the command line.
Make sure you include the -L <library-path> option to tell the linker where
to look for these files if they are not in the current directory.
Here is an example, assuming you have the source file
library file.
Libraries created in this manner can be included in the command line.
Make sure you include the -L <library-path> option to tell the linker where
to look for these files if they are not in the current directory.
Here is an example, assuming you have the source file
Alternatively, instead of having a .rel file for each entry on the library
file as described in the preceding section, sdcclib can be used to embed
all the modules belonging to such library in the library file itself.
Alternatively, instead of having a .rel file for each entry on the library
file as described in the preceding section, sdcclib can be used to embed
all the modules belonging to such library in the library file itself.
Additionally, the packed library file contains an index of all include
modules and symbols that significantly speeds up the linking process.
To display a list of options supported by sdcclib type:
Additionally, the packed library file contains an index of all include
modules and symbols that significantly speeds up the linking process.
To display a list of options supported by sdcclib type:
This will create files _divsint.rel, _divuint.rel, _modsint.rel, _moduint.rel,
and _mulint.rel.
The next step is to add the .rel files to the library file:
This will create files _divsint.rel, _divuint.rel, _modsint.rel, _moduint.rel,
and _mulint.rel.
The next step is to add the .rel files to the library file:
If the file already exists in the library, it will be replaced.
To see what modules and symbols are included in the library, options -s
and -m are available.
For example:
If the file already exists in the library, it will be replaced.
To see what modules and symbols are included in the library, options -s
and -m are available.
For example:
is embedded in the library file itself.
Library files created using sdcclib are used as described in the preceding
sections.
is embedded in the library file itself.
Library files created using sdcclib are used as described in the preceding
sections.
processor (Not maintained, not complete).
AVR users should probably have a look at winavr
\begin_inset LatexCommand \url{http://sourceforge.net/projects/winavr}
processor (Not maintained, not complete).
AVR users should probably have a look at winavr
\begin_inset LatexCommand \url{http://sourceforge.net/projects/winavr}
I think it is fair to direct users there for now.
Open source is also about avoiding unnecessary work .
But I didn't find the 'official' link.
I think it is fair to direct users there for now.
Open source is also about avoiding unnecessary work .
But I didn't find the 'official' link.
-bit processors (p16f84 and variants.
In development, not complete).
-bit processors (p16f84 and variants.
In development, not complete).
-bit processors (p18f452 and variants.
In development, not complete).
-bit processors (p18f452 and variants.
In development, not complete).
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 `
Tell the preprocessor to output a rule suitable for make describing the
dependencies of each object file.
For each source file, the preprocessor outputs one make-rule whose target
is the object file name for that source file and whose dependencies are
all the files `#include'd in it.
This rule may be a single line or may be continued with `
'-newline if it is long.
The list of rules is printed on standard output instead of the preprocessed
C program.
`-M' implies `-E
\begin_inset LatexCommand \index{-E}
'-newline if it is long.
The list of rules is printed on standard output instead of the preprocessed
C program.
`-M' implies `-E
\begin_inset LatexCommand \index{-E}
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.
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.
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.
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.
Tell the preprocessor to pass all macro definitions into the output, in
their proper sequence in the rest of the output.
Tell the preprocessor to pass all macro definitions into the output, in
their proper sequence in the rest of the output.
Like `-dD' except that the macro arguments and contents are omitted.
Only `#define name' is included in the output.
Like `-dD' except that the macro arguments and contents are omitted.
Only `#define name' is included in the output.
Pedentic parse numbers so that situations like 0xfe-LO_B(3) are parsed properly
and the macro LO_B(3) gets expanded.
See also #pragma pedantic_parse_number in section
\begin_inset LatexCommand \ref{sec:Pragmas}
Pedentic parse numbers so that situations like 0xfe-LO_B(3) are parsed properly
and the macro LO_B(3) gets expanded.
See also #pragma pedantic_parse_number in section
\begin_inset LatexCommand \ref{sec:Pragmas}
<absolute path to additional libraries> This option is passed to the linkage
editor's additional libraries
\begin_inset LatexCommand \index{Libraries}
<absolute path to additional libraries> This option is passed to the linkage
editor's additional libraries
\begin_inset LatexCommand \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.
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.
<Value> The start location of the external ram
\begin_inset LatexCommand \index{xdata (mcs51, ds390 storage class)}
<Value> The start location of the external ram
\begin_inset LatexCommand \index{xdata (mcs51, ds390 storage class)}
segment, default value 0.
Note when this option is used the interrupt vector table
\begin_inset LatexCommand \index{interrupt vector table}
segment, default value 0.
Note when this option is used the interrupt vector table
\begin_inset LatexCommand \index{interrupt vector table}
is also relocated to the given address.
The value entered can be in Hexadecimal or Decimal format, e.g.: -
\begin_inset ERT
is also relocated to the given address.
The value entered can be in Hexadecimal or Decimal format, e.g.: -
\begin_inset ERT
is placed after the data segment.
Using this option the stack can be placed anywhere in the internal memory
is placed after the data segment.
Using this option the stack can be placed anywhere in the internal memory
option (which is now a default setting) will override this setting, so
you should also specify the
option (which is now a default setting) will override this setting, so
you should also specify the
is placed after the pdata
\begin_inset LatexCommand \index{pdata (mcs51, ds390 storage class)}
is placed after the pdata
\begin_inset LatexCommand \index{pdata (mcs51, ds390 storage class)}
-stack-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.
-stack-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.
<Value> The start location of the internal ram data
\begin_inset LatexCommand \index{data (mcs51, ds390 storage class)}
<Value> The start location of the internal ram data
\begin_inset LatexCommand \index{data (mcs51, ds390 storage class)}
For example if register banks 0 and 1 are used without bit variables, the
data segment will be set, if -
\begin_inset ERT
For example if register banks 0 and 1 are used without bit variables, the
data segment will be set, if -
\begin_inset ERT
<Value> The start location of the indirectly addressable internal ram
\begin_inset LatexCommand \index{idata (mcs51, ds390 storage class)}
<Value> The start location of the indirectly addressable internal ram
\begin_inset LatexCommand \index{idata (mcs51, ds390 storage class)}
of the 8051, default value is 0x80.
The value entered can be in Hexadecimal or Decimal format, eg.
-
\begin_inset ERT
of the 8051, default value is 0x80.
The value entered can be in Hexadecimal or Decimal format, eg.
-
\begin_inset ERT
The linker output (final object code) is in Intel Hex format.
\begin_inset LatexCommand \index{Intel hex format}
The linker output (final object code) is in Intel Hex format.
\begin_inset LatexCommand \index{Intel hex format}
This is the default option.
The format itself is documented in the documentation of srecord
\begin_inset LatexCommand \index{srecord (bin, hex, ... tool)}
This is the default option.
The format itself is documented in the documentation of srecord
\begin_inset LatexCommand \index{srecord (bin, hex, ... tool)}
The linker output (final object code) is in Motorola S19 format
\begin_inset LatexCommand \index{Motorola S19 format}
The linker output (final object code) is in Motorola S19 format
\begin_inset LatexCommand \index{Motorola S19 format}
would be typical to set the start of the code segment.
See also #pragma constseg and #pragma codeseg in section
\begin_inset LatexCommand \ref{sec:Pragmas}
would be typical to set the start of the code segment.
See also #pragma constseg and #pragma codeseg in section
\begin_inset LatexCommand \ref{sec:Pragmas}
Generate code for Small Model programs, see section Memory Models for more
details.
This is the default model.
Generate code for Small Model programs, see section Memory Models for more
details.
This is the default model.
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.
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.
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.
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.
Uses a pseudo stack in the pdata
\begin_inset LatexCommand \index{pdata (mcs51, ds390 storage class)}
Uses a pseudo stack in the pdata
\begin_inset LatexCommand \index{pdata (mcs51, ds390 storage class)}
area (usually the first 256 bytes in the external ram) for allocating variables
and passing parameters.
See section
\begin_inset LatexCommand \ref{sub:External-Stack}
area (usually the first 256 bytes in the external ram) for allocating variables
and passing parameters.
See section
\begin_inset LatexCommand \ref{sub:External-Stack}
Causes the linker to use unused register banks for data variables and pack
data, idata and stack together.
This is the default now.
Causes the linker to use unused register banks for data variables and pack
data, idata and stack together.
This is the default now.
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
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
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
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
.
In this mode, the stack is located in the lower 1K of the internal RAM,
which is mapped to 0x400000.
.
In this mode, the stack is located in the lower 1K of the internal RAM,
which is mapped to 0x400000.
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
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
option, but that has not been tested.
It is incompatible with the
option, but that has not been tested.
It is incompatible with the
When linking, skip the standard crt0.o object file.
You must provide your own crt0.o for your system when linking.
When linking, skip the standard crt0.o object file.
You must provide your own crt0.o for your system when linking.
Will not do global subexpression elimination, this option may be used when
the compiler creates undesirably large stack/data spaces to store compiler
temporaries (
Will not do global subexpression elimination, this option may be used when
the compiler creates undesirably large stack/data spaces to store compiler
temporaries (
).
A warning message will be generated when this happens and the compiler
will indicate the number of extra bytes it allocated.
).
A warning message will be generated when this happens and the compiler
will indicate the number of extra bytes it allocated.
can be used to turn off global subexpression elimination
\begin_inset LatexCommand \index{Subexpression elimination}
can be used to turn off global subexpression elimination
\begin_inset LatexCommand \index{Subexpression elimination}
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
\begin_inset LatexCommand \ref{sub:Loop-Optimizations}
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
\begin_inset LatexCommand \ref{sub:Loop-Optimizations}
Will not generate boundary condition check when switch statements
\begin_inset LatexCommand \index{switch statement}
Will not generate boundary condition check when switch statements
\begin_inset LatexCommand \index{switch statement}
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
\begin_inset LatexCommand \index{Variable initialization}
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
\begin_inset LatexCommand \index{Variable initialization}
The compiler will not overlay parameters and local variables of any function,
see section Parameters and local variables for more details.
The compiler will not overlay parameters and local variables of any function,
see section Parameters and local variables for more details.
<filename> This option can be used to use additional rules to be used by
the peep hole optimizer.
See section
\begin_inset LatexCommand \ref{sub:Peephole-Optimizer}
<filename> This option can be used to use additional rules to be used by
the peep hole optimizer.
See section
\begin_inset LatexCommand \ref{sub:Peephole-Optimizer}
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
\begin_inset LatexCommand \index{Peephole optimizer}
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
\begin_inset LatexCommand \index{Peephole optimizer}
The compiler will optimize code generation towards fast code, possibly
at the expense of code size.
The compiler will optimize code generation towards fast code, possibly
at the expense of code size.
The compiler will optimize code generation towards compact code, possibly
at the expense of code speed.
The compiler will optimize code generation towards compact code, possibly
at the expense of code speed.
reads the preprocessed source from standard input and compiles it.
The file name for the assembler output must be specified using the -o option.
reads the preprocessed source from standard input and compiles it.
The file name for the assembler output must be specified using the -o option.
Run only the C preprocessor.
Preprocess all the C source files specified and output the results to standard
output.
Run only the C preprocessor.
Preprocess all the C source files specified and output the results to standard
output.
The output path resp.
file where everything will be placed.
If the parameter is a path, it must have a trailing slash (or backslash
for the Windows binaries) to be recognized as a path.
The output path resp.
file where everything will be placed.
If the parameter is a path, it must have a trailing slash (or backslash
for the Windows binaries) to be recognized as a path.
, i.e.
the parameters and local variables will be allocated on the stack
\begin_inset LatexCommand \index{stack}
, i.e.
the parameters and local variables will be allocated on the stack
\begin_inset LatexCommand \index{stack}
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 --int-long-reent and --float-reent.
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 --int-long-reent and --float-reent.
The compiler by default uses a caller saves convention for register saving
across function calls, however this can cause unnecessary register pushing
& popping when calling small functions from larger functions.
The compiler by default uses a caller saves convention for register saving
across function calls, however this can cause unnecessary register pushing
& popping when calling small functions from larger functions.
function names specified.
The compiler will not save registers when calling these functions, no extra
code will be generated at the entry & exit (function prologue
function names specified.
The compiler will not save registers when calling these functions, no extra
code will be generated at the entry & exit (function prologue
) for these functions to save & restore the registers used by these functions,
this can SUBSTANTIALLY reduce code & improve run time performance of the
generated code.
) for these functions to save & restore the registers used by these functions,
this can SUBSTANTIALLY reduce code & improve run time performance of the
generated code.
If the project consists of multiple source files then all the source file
should be compiled with the same -
\begin_inset ERT
If the project consists of multiple source files then all the source file
should be compiled with the same -
\begin_inset ERT
When this option is used the compiler will generate debug information.
The debug information collected in a file with .cdb extension can be used
with the SDCDB.
When this option is used the compiler will generate debug information.
The debug information collected in a file with .cdb extension can be used
with the SDCDB.
Another file with no extension contains debug information in AOMF or AOMF51
\begin_inset LatexCommand \index{AOMF, AOMF51}
Another file with no extension contains debug information in AOMF or AOMF51
\begin_inset LatexCommand \index{AOMF, AOMF51}
Stop after the stage of compilation proper; do not assemble.
The output is an assembler code file for the input file specified.
Stop after the stage of compilation proper; do not assemble.
The output is an assembler code file for the input file specified.
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.
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.
This option will cause the compiler to generate an information message for
each function in the source file.
The message contains some
This option will cause the compiler to generate an information message for
each function in the source file.
The message contains some
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
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
This option can be used if the code generated is called by a monitor program
or if the main routine includes an endless loop.
This option results in slightly smaller code and saves two bytes of stack
This option can be used if the code generated is called by a monitor program
or if the main routine includes an endless loop.
This option results in slightly smaller code and saves two bytes of stack
This will prevent the compiler from passing on the default library
\begin_inset LatexCommand \index{Libraries}
This will prevent the compiler from passing on the default library
\begin_inset LatexCommand \index{Libraries}
Include i-codes in the asm file.
Sounds like noise but is most helpful for debugging the compiler itself.
Include i-codes in the asm file.
Sounds like noise but is most helpful for debugging the compiler itself.
Display errors and warnings using MSVC style, so you can use SDCC with
the visual studio IDE
\begin_inset LatexCommand \index{IDE}
Display errors and warnings using MSVC style, so you can use SDCC with
the visual studio IDE
\begin_inset LatexCommand \index{IDE}
.
With SDCC both offering a GCC-like (the default) and a MSVC-like
\begin_inset LatexCommand \index{MSVC output style}
.
With SDCC both offering a GCC-like (the default) and a MSVC-like
\begin_inset LatexCommand \index{MSVC output style}
Generally follow the C89 standard, but allow SDCC features that conflict
with the standard (default).
Generally follow the C89 standard, but allow SDCC features that conflict
with the standard (default).
Generally follow the C99 standard, but allow SDCC features that conflict
with the standard (incomplete support).
Generally follow the C99 standard, but allow SDCC features that conflict
with the standard (incomplete support).
Follow the C99 standard and disable SDCC features that conflict with the
standard (incomplete support).
Follow the C99 standard and disable SDCC features that conflict with the
standard (incomplete support).
in a special place in memory.
Can be used for instance when using bank switching to put the const data
in a bank.
in a special place in memory.
Can be used for instance when using bank switching to put the const data
in a bank.
warnings you can use a separate tool dedicated to syntax checking like
splint
\begin_inset LatexCommand \label{lyx:more-pedantic-SPLINT}
warnings you can use a separate tool dedicated to syntax checking like
splint
\begin_inset LatexCommand \label{lyx:more-pedantic-SPLINT}
Splint has an excellent on line manual at
\begin_inset LatexCommand \url{http://www.splint.org/manual/}
Splint has an excellent on line manual at
\begin_inset LatexCommand \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:
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:
The following options are provided for the purpose of retargetting and debugging
the compiler.
They provide a means to dump the intermediate code (iCode
\begin_inset LatexCommand \index{iCode}
The following options are provided for the purpose of retargetting and debugging
the compiler.
They provide a means to dump the intermediate code (iCode
\begin_inset LatexCommand \index{iCode}
) generated by the compiler in human readable form at various stages of
the compilation process.
More on iCodes see chapter
\begin_inset LatexCommand \ref{sub:The-anatomy-of}
) generated by the compiler in human readable form at various stages of
the compilation process.
More on iCodes see chapter
\begin_inset LatexCommand \ref{sub:The-anatomy-of}
just after the intermediate code has been generated for a function, i.e.
before any optimizations are done.
The basic blocks
\begin_inset LatexCommand \index{Basic blocks}
just after the intermediate code has been generated for a function, i.e.
before any optimizations are done.
The basic blocks
\begin_inset LatexCommand \index{Basic blocks}
Will create a dump of iCode's, after global subexpression elimination
\begin_inset LatexCommand \index{Global subexpression elimination}
Will create a dump of iCode's, after global subexpression elimination
\begin_inset LatexCommand \index{Global subexpression elimination}
Will create a dump of iCode's, after deadcode elimination
\begin_inset LatexCommand \index{Dead-code elimination}
Will create a dump of iCode's, after deadcode elimination
\begin_inset LatexCommand \index{Dead-code elimination}
Will create a dump of iCode's, after loop optimizations
\begin_inset LatexCommand \index{Loop optimization}
Will create a dump of iCode's, after loop optimizations
\begin_inset LatexCommand \index{Loop optimization}
Will create a dump of iCode's, after live range analysis
\begin_inset LatexCommand \index{Live range analysis}
Will create a dump of iCode's, after live range analysis
\begin_inset LatexCommand \index{Live range analysis}
Will create a dump of iCode's, after register assignment
\begin_inset LatexCommand \index{Register assignment}
Will create a dump of iCode's, after register assignment
\begin_inset LatexCommand \index{Register assignment}
.
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 -
.
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 -
to be able to delete temporary files after an user break (^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.
to be able to delete temporary files after an user break (^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.
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.
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.
There are some more environment variables recognized by SDCC, but these
are solely used for debugging purposes.
They can change or disappear very quickly, and will never be documented.
There are some more environment variables recognized by SDCC, but these
are solely used for debugging purposes.
They can change or disappear very quickly, and will never be documented.
can be used synonymously).
Variables declared with this storage class will be allocated in the directly
addressable portion of the internal RAM of a 8051, e.g.:
can be used synonymously).
Variables declared with this storage class will be allocated in the directly
addressable portion of the internal RAM of a 8051, e.g.:
Variables declared with this storage class will be allocated into the indirectly
addressable portion of the internal ram of a 8051, e.g.:
Variables declared with this storage class will be allocated into the indirectly
addressable portion of the internal ram of a 8051, e.g.:
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
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
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
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
The high byte of the address is determined by port P2
\begin_inset LatexCommand \index{P2 (mcs51 sfr)}
The high byte of the address is determined by port P2
\begin_inset LatexCommand \index{P2 (mcs51 sfr)}
(or in case of some 8051 variants by a separate Special Function Register,
see section
\begin_inset LatexCommand \ref{sub:MCS51-variants}
(or in case of some 8051 variants by a separate Special Function Register,
see section
\begin_inset LatexCommand \ref{sub:MCS51-variants}
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.
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.
__code char test_array[] = {'c','h','e','a','p'};
__code char test_array[] = {'c','h','e','a','p'};
This is a data-type and a storage class specifier.
When a variable is declared as a bit, it is allocated into the bit addressable
memory of 8051, e.g.:
This is a data-type and a storage class specifier.
When a variable is declared as a bit, it is allocated into the bit addressable
memory of 8051, e.g.:
Not really meant as examples, but nevertheless showing what bitfields are
about: device/include/mc68hc908qy.h and support/regression/tests/bitfields.c
Not really meant as examples, but nevertheless showing what bitfields 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.
.
In accordance with ISO/IEC 9899 bits and bitfields without an explicit
signed modifier are implemented as unsigned.
-\newline
-
-\newline
-/* 16 bit special function register combination for timer 0
-\newline
-\SpecialChar ~
-\SpecialChar ~
- with the high byte at location 0x8C and the low byte at location 0x8A */
-\newline
-__sfr16 __at (0x8C8A) TMR0;
-\newline
-
-\newline
+\newline
+
+\newline
+/* 16 bit
+ special function register combination for timer 0
+\newline
+\InsetSpace ~
+\InsetSpace ~
+ with the high byte at
+ location 0x8C and the low byte at location 0x8A */
+\newline
+__sfr16 __at (0x8C8A)
+ TMR0;
+\newline
+
+\newline
Special function registers which are located on an address dividable by
8 are bit-addressable, an
Special function registers which are located on an address dividable by
8 are bit-addressable, an
-\newline
-16 Bit and 32 bit special function register combinations which require a
- certain access order are better not declared using
-\emph on
+\newline
+16 Bit and 32 bit special function
+ register combinations which require a certain access order are better not
+ declared using
+\emph on
Please note, if you use a header file which was written for another compiler
then the sfr / sfr16 / sfr32 / sbit Storage Class extensions will most
likely be
Please note, if you use a header file which was written for another compiler
then the sfr / sfr16 / sfr32 / sbit Storage Class extensions will most
likely be
which can be shared among different compilers (see section
\begin_inset LatexCommand \ref{sec:Porting-code-to-other-compilers}
which can be shared among different compilers (see section
\begin_inset LatexCommand \ref{sec:Porting-code-to-other-compilers}
SDCC allows (via language extensions) pointers to explicitly point to any
of the memory spaces
\begin_inset LatexCommand \index{Memory model}
SDCC allows (via language extensions) pointers to explicitly point to any
of the memory spaces
\begin_inset LatexCommand \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.
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.
-\newline
-
-\newline
-/* pointer physically in code rom pointing to data in xdata space */
-\newline
-__xdata unsigned char * __code p;
-\newline
-
-\newline
-/* pointer physically in code space pointing to data in code space */
-\newline
+\newline
+
+\newline
+/*
+ pointer physically in code rom pointing to data in xdata space */
+\newline
+__xdata
+ unsigned char * __code p;
+\newline
+
+\newline
+/* pointer physically in code space pointing to
+ data in code space */
+\newline
pointers contains the data space information.
Assembler support routines are called whenever data is stored or retrieved
using
pointers contains the data space information.
Assembler support routines are called whenever data is stored or retrieved
using
The 8051 family of microcontrollers have a minimum of 128 bytes of internal
RAM memory which is structured as follows:
The 8051 family of microcontrollers have a minimum of 128 bytes of internal
RAM memory which is structured as follows:
-\newline
-
-\newline
-- Bytes 00-1F - 32 bytes to hold up to 4 banks of the registers R0 to R7,
-
-\newline
-- Bytes 20-2F - 16 bytes to hold 128 bit
+\newline
+
+\newline
+- Bytes 00-1F - 32 bytes to hold
+ up to 4 banks of the registers R0 to R7,
+\newline
+- Bytes 20-2F - 16 bytes to hold
+ 128 bit
Additionally some members of the MCS51 family may have up to 128 bytes of
additional, indirectly addressable, internal RAM memory (
Additionally some members of the MCS51 family may have up to 128 bytes of
additional, indirectly addressable, internal RAM memory (
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
\begin_inset LatexCommand \ref{sub:Startup-Code}
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
\begin_inset LatexCommand \ref{sub:Startup-Code}
Normally SDCC will only use the first bank
\begin_inset LatexCommand \index{register bank (mcs51, ds390)}
Normally SDCC will only use the first bank
\begin_inset LatexCommand \index{register bank (mcs51, ds390)}
of registers (register bank 0), but it is possible to specify that other
banks of registers (keyword
of registers (register bank 0), but it is possible to specify that other
banks of registers (keyword
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
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
variables, it will position the base of the internal stack at address 20
(0x14).
This implies that as the stack
\begin_inset LatexCommand \index{stack}
variables, it will position the base of the internal stack at address 20
(0x14).
This implies that as the stack
\begin_inset LatexCommand \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.
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.
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),
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),
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 (
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 (
.
If in doubt, don't specify any options and see if the resulting memory
layout is appropriate, then you can adjust it.
.
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
\begin_inset LatexCommand \index{<file>.map}
The linker generates two files with memory allocation information.
The first, with extension .map
\begin_inset LatexCommand \index{<file>.map}
shows all the variables and segments.
The second with extension .mem
\begin_inset LatexCommand \index{<file>.mem}
shows all the variables and segments.
The second with extension .mem
\begin_inset LatexCommand \index{<file>.mem}
shows the final memory layout.
The linker will complain either if memory segments overlap, there is not
shows the final memory layout.
The linker will complain either if memory segments overlap, there is not
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.
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.
The data storage class declares a variable that resides in the first 256
bytes of memory (the direct page).
The HC08
\begin_inset LatexCommand \index{HC08}
The data storage class declares a variable that resides in the first 256
bytes of memory (the direct page).
The HC08
\begin_inset LatexCommand \index{HC08}
The xdata storage class declares a variable that can reside anywhere in
memory.
This is the default if no storage class is specified.
The xdata storage class declares a variable that can reside anywhere in
memory.
This is the default if no storage class is specified.
(they are implemented with an equate in the assembler).
Thus it is left to the programmer to make sure there are no overlaps with
(they are implemented with an equate in the assembler).
Thus it is left to the programmer to make sure there are no overlaps with
The above example will allocate the variable at offset 0x02 in the bit-addressab
le space.
There is no real advantage to assigning absolute addresses to variables
The above example will allocate the variable at offset 0x02 in the bit-addressab
le space.
There is no real advantage to assigning absolute addresses to variables
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:
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:
-\newline
-extern volatile __bit MISO;\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-/* master in, slave out */
-\newline
-extern volatile __bit MCLK;\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
+\newline
+extern volatile __bit MISO;\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+/* master
+ in, slave out */
+\newline
+extern volatile __bit MCLK;\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
-\newline
-
-\newline
-/* Input and Output of a byte on a 3-wire serial bus.
-\newline
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-If needed adapt polarity of clock, polarity of data and bit order
-\newline
-\SpecialChar ~
+\newline
+
+\newline
+/* Input and
+ Output of a byte on a 3-wire serial bus.
+\newline
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+If needed adapt polarity of clock,
+ polarity of data and bit order
+\newline
+\InsetSpace ~
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.
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.
Automatic (local) variables and parameters to functions can either be placed
on the stack or in data-space.
The default action of the compiler is to place these variables in the internal
RAM (for small model) or external RAM (for large model).
This in fact makes them similar to
Automatic (local) variables and parameters to functions can either be placed
on the stack or in data-space.
The default action of the compiler is to place these variables in the internal
RAM (for small model) or external RAM (for large model).
This in fact makes them similar to
option should be used sparingly.
Note that the reentrant keyword just means that the parameters & local
variables will be allocated to the stack, it
option should be used sparingly.
Note that the reentrant keyword just means that the parameters & local
variables will be allocated to the stack, it
mean that the function is register bank
\begin_inset LatexCommand \index{register bank (mcs51, ds390)}
mean that the function is register bank
\begin_inset LatexCommand \index{register bank (mcs51, ds390)}
, (storage classes for parameters will be ignored), their allocation is
governed by the memory model in use, and the reentrancy options.
, (storage classes for parameters will be ignored), their allocation is
governed by the memory model in use, and the reentrancy options.
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
\begin_inset LatexCommand \index{stack}
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
\begin_inset LatexCommand \index{stack}
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
\begin_inset LatexCommand \index{local variables}
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
\begin_inset LatexCommand \index{local variables}
no other function calls and the function is non-reentrant and the memory
model
\begin_inset LatexCommand \index{Memory model}
no other function calls and the function is non-reentrant and the memory
model
\begin_inset LatexCommand \index{Memory model}
Note that the compiler (not the linkage editor) makes the decision for overlayin
g the data items.
Functions that are called from an interrupt service routine
\begin_inset Marginal
Note that the compiler (not the linkage editor) makes the decision for overlayin
g the data items.
Functions that are called from an interrupt service routine
\begin_inset Marginal
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.
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.
Parameters and local variables of functions that contain 16 or 32 bit multiplica
tion
\begin_inset LatexCommand \index{Multiplication}
Parameters and local variables of functions that contain 16 or 32 bit multiplica
tion
\begin_inset LatexCommand \index{Multiplication}
nooverlay was
not present, this could cause unpredictable runtime behavior when called
from an interrupt service routine.
nooverlay was
not present, this could cause unpredictable runtime behavior when called
from an interrupt service routine.
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
\begin_inset LatexCommand \index{interrupt vector table}
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
\begin_inset LatexCommand \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
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
can be used to tell the compiler to use the specified register bank when
generating code for this function.
can be used to tell the compiler to use the specified register bank when
generating code for this function.
If an interrupt service routine changes variables which are accessed by
other functions these variables have to be declared
If an interrupt service routine changes variables which are accessed by
other functions these variables have to be declared
(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.
(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.
-\newline
-Access to 16 or 32 bit variables is obviously not atomic on 8 bit CPUs and
- should be protected by disabling interrupts.
+\newline
+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
\begin_inset Quotes srd
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
\begin_inset Quotes srd
The return address and the registers used in the interrupt service routine
are saved on the stack
\begin_inset LatexCommand \index{stack}
The return address and the registers used in the interrupt service routine
are saved on the stack
\begin_inset LatexCommand \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
so there must be sufficient stack space.
If there isn't variables or registers (or even the return address itself)
will be corrupted.
This
A special note here, int (16 bit) and long (32 bit) integer division
\begin_inset LatexCommand \index{Division}
A special note here, int (16 bit) and long (32 bit) integer division
\begin_inset LatexCommand \index{Division}
operations are implemented using external support routines.
If an interrupt service routine needs to do any of these operations then
the support routines (as mentioned in a following section) will have to
be recompiled using the
operations are implemented using external support routines.
If an interrupt service routine needs to do any of these operations then
the support routines (as mentioned in a following section) will have to
be recompiled using the
Calling other functions from an interrupt service routine is not recommended,
avoid it if possible.
Note that when some function is called from an interrupt service routine
Calling other functions from an interrupt service routine is not recommended,
avoid it if possible.
Note that when some function is called from an interrupt service routine
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
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
numbers and the corresponding address & descriptions for the Standard 8051/8052
are listed below.
SDCC will automatically adjust the
\begin_inset LatexCommand \index{interrupt vector table}
numbers and the corresponding address & descriptions for the Standard 8051/8052
are listed below.
SDCC will automatically adjust the
\begin_inset LatexCommand \index{interrupt vector table}
<lyxtabular version="3" rows="9" columns="3">
<features>
<column alignment="center" valignment="top" leftline="true" width="0in">
<lyxtabular version="3" rows="9" columns="3">
<features>
<column alignment="center" valignment="top" leftline="true" width="0in">
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
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.
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.
& 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
\begin_inset LatexCommand \index{stack}
& 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
\begin_inset LatexCommand \index{stack}
available is chip specific and the interrupt vector table always ends at
the last byte of memory, the interrupt numbers corresponds to the 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
uses several different methods for determining the correct interrupt
\begin_inset LatexCommand \index{Z80!interrupt}
uses several different methods for determining the correct interrupt
\begin_inset LatexCommand \index{Z80!interrupt}
vector depending on the hardware implementation.
Therefore, SDCC ignores the optional interrupt number and does not attempt
to generate an interrupt vector table.
vector depending on the hardware implementation.
Therefore, SDCC ignores the optional interrupt number and 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, add the
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, add the
However if you need to create a non-interruptable interrupt service routine
you would also require the
However if you need to create a non-interruptable interrupt service routine
you would also require the
upon entry to a critical function and restore the interrupt enable to the
previous state before returning.
Nesting critical functions will need one additional byte on the stack
\begin_inset LatexCommand \index{stack}
upon entry to a critical function and restore the interrupt enable to the
previous state before returning.
Nesting critical functions will need one additional byte on the stack
\begin_inset LatexCommand \index{stack}
On other architectures which have seperate opcodes for enabling and disabling
interrupts you might want to make use of defines with inline assembly
\begin_inset LatexCommand \index{Assembler routines}
On other architectures which have seperate opcodes for enabling and disabling
interrupts you might want to make use of defines with inline assembly
\begin_inset LatexCommand \index{Assembler routines}
Note: it is sometimes sufficient to disable only a specific interrupt source
like f.e.
a timer or serial interrupt by manipulating an
Note: it is sometimes sufficient to disable only a specific interrupt source
like f.e.
a timer or serial interrupt by manipulating an
(the time between the occurrence of the interrupt and the execution of
the first code in the interrupt routine) and
(the time between the occurrence of the interrupt and the execution of
the first code in the interrupt routine) and
(the difference between the shortest and the longest interrupt latency).
These really are something different, f.e.
(the difference between the shortest and the longest interrupt latency).
These really are something different, f.e.
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.
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 reenable interrupts within an interrupt routine and on some architecture
s you can make use of two (or more) levels of
You can reenable interrupts within an interrupt routine and on some architecture
s you can make use of two (or more) levels of
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
\begin_inset LatexCommand \index{lock}
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
\begin_inset LatexCommand \index{lock}
on it'), makes some modifications and then releases the lock when the data
structure is consistent again.
on it'), makes some modifications and then releases the lock when the data
structure is consistent again.
With the atomic bit test and clear instruction interrupts
\begin_inset LatexCommand \index{interrupt}
With the atomic bit test and clear instruction interrupts
\begin_inset LatexCommand \index{interrupt}
Note, mcs51 and ds390 support only an atomic
\begin_inset LatexCommand \index{atomic}
Note, mcs51 and ds390 support only an atomic
\begin_inset LatexCommand \index{atomic}
Functions using private register banks
\begin_inset LatexCommand \label{sub:Functions-using-private-banks}
Functions using private register banks
\begin_inset LatexCommand \label{sub:Functions-using-private-banks}
Some architectures have support for quickly changing register sets.
SDCC supports this feature with the
Some architectures have support for quickly changing register sets.
SDCC supports this feature with the
attribute (which tells the compiler to use a register bank
\begin_inset LatexCommand \index{register bank (mcs51, ds390)}
attribute (which tells the compiler to use a register bank
\begin_inset LatexCommand \index{register bank (mcs51, ds390)}
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.
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.
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.
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.
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
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
function using a non-zero bank will assume that it can trash that register
bank, and will not save it.
Since high-priority interrupts
\begin_inset LatexCommand \index{interrupts}
function using a non-zero bank will assume that it can trash that register
bank, and will not save it.
Since high-priority interrupts
\begin_inset LatexCommand \index{interrupts}
the same bank, terrible and bad things can happen.
To prevent this, no single register bank should be
the same bank, terrible and bad things can happen.
To prevent this, no single register bank should be
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.
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
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
at the start of the CODE area.
This routine is in the runtime library
\begin_inset LatexCommand \index{Runtime library}
at the start of the CODE area.
This routine is in the runtime library
\begin_inset LatexCommand \index{Runtime library}
routine to your program to override the default if you need to setup hardware
or perform some other critical operation prior to static & global variable
initialization
\begin_inset LatexCommand \index{Variable initialization}
routine to your program to override the default if you need to setup hardware
or perform some other critical operation prior to static & global variable
initialization
\begin_inset LatexCommand \index{Variable initialization}
.
On some mcs51 variants xdata
\begin_inset LatexCommand \index{xdata (mcs51, ds390 storage class)}
.
On some mcs51 variants xdata
\begin_inset LatexCommand \index{xdata (mcs51, ds390 storage class)}
memory has to be explicitly enabled before it can be accessed or if the
watchdog
\begin_inset LatexCommand \index{watchdog}
memory has to be explicitly enabled before it can be accessed or if the
watchdog
\begin_inset LatexCommand \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
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
the startup code is inserted by linking with crt0.o which is generated from
sdcc/device/lib/z80/crt0.s.
If you need a different startup code you can use the compiler option
the startup code is inserted by linking with crt0.o which is generated from
sdcc/device/lib/z80/crt0.s.
If you need a different startup code you can use the compiler option
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:
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:
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
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
in file buffer.c in which we cut and paste the generated code, removing
unwanted comments and some ':'.
Then add
\begin_inset Quotes sld
in file buffer.c in which we cut and paste the generated code, removing
unwanted comments and some ':'.
Then add
\begin_inset Quotes sld
;buffer.c buf[ head++ ] = c; /* access to a 256 byte aligned array */
\begin_inset LatexCommand \index{Aligned array}
;buffer.c buf[ head++ ] = c; /* access to a 256 byte aligned array */
\begin_inset LatexCommand \index{Aligned array}
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:
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:
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/as/doc/asxhtm.html
\begin_inset LatexCommand \index{asXXXX (as-gbz80, as-hc08, asx8051, as-z80)}
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/as/doc/asxhtm.html
\begin_inset LatexCommand \index{asXXXX (as-gbz80, as-hc08, asx8051, as-z80)}
keyword pair.
Specifically it will not know which registers are used and thus register
pushing/popping
\begin_inset LatexCommand \index{push/pop}
keyword pair.
Specifically it will not know which registers are used and thus register
pushing/popping
\begin_inset LatexCommand \index{push/pop}
It is recommended that each assembly instruction (including labels) be placed
in a separate line (as the example shows).
When the -
\begin_inset ERT
It is recommended that each assembly instruction (including labels) be placed
in a separate line (as the example shows).
When the -
\begin_inset ERT
command line option is used, the inline assembler code will be passed through
the peephole optimizer
\begin_inset LatexCommand \index{Peephole optimizer}
command line option is used, the inline assembler code will be passed through
the peephole optimizer
\begin_inset LatexCommand \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
.
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
function modifier attribute prevents the compiler from generating prologue
\begin_inset LatexCommand \index{function prologue}
function modifier attribute prevents the compiler from generating prologue
\begin_inset LatexCommand \index{function prologue}
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
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
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:
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:
function, there are many ways to shoot yourself in the foot doing this,
and it is recommended that you stick to inline assembler.
function, there are many ways to shoot yourself in the foot doing this,
and it is recommended that you stick to inline assembler.
SDCC allows the use of in-line assembler with a few restrictions regarding
labels.
In older versions of the compiler all labels defined within inline assembler
code
SDCC allows the use of in-line assembler with a few restrictions regarding
labels.
In older versions of the compiler all labels defined within inline assembler
code
Inline assembler code cannot reference any C-Labels, however it can reference
labels
\begin_inset LatexCommand \index{Labels}
Inline assembler code cannot reference any C-Labels, however it can reference
labels
\begin_inset LatexCommand \index{Labels}
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.
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.
to pass the first parameter to a routine.
The second parameter onwards is either allocated on the stack (for reentrant
routines or if -
\begin_inset ERT
to pass the first parameter to a routine.
The second parameter onwards is either allocated on the stack (for reentrant
routines or if -
\begin_inset ERT
the function c_func calls an assembler routine asm_func, which takes two
parameters
\begin_inset LatexCommand \index{function parameter}
the function c_func calls an assembler routine asm_func, which takes two
parameters
\begin_inset LatexCommand \index{function parameter}
are placed in 'dpl' - One byte return value, 'dpl' LSB & 'dph' MSB for
two byte values.
'dpl', 'dph' and 'b' for three byte values (generic pointers) and 'dpl','dph','
b' & 'acc' for four byte values.
are placed in 'dpl' - One byte return value, 'dpl' LSB & 'dph' MSB for
two byte values.
'dpl', 'dph' and 'b' for three byte values (generic pointers) and 'dpl','dph','
b' & 'acc' for four byte values.
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
\begin_inset Quotes eld
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
\begin_inset Quotes eld
for a four bytes parameter.
The variable name for the second parameter will be _<function_name>_PARM_2.
for a four bytes parameter.
The variable name for the second parameter will be _<function_name>_PARM_2.
onwards will be passed on the stack, the parameters are pushed from right
to left i.e.
after the call the leftmost parameter will be on the top of the stack.
Here is an example:
onwards will be passed on the stack, the parameters are pushed from right
to left i.e.
after the call the leftmost parameter will be on the top of the stack.
Here is an example:
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.
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.
For signed & unsigned int (16 bit) and long (32 bit) variables, division,
multiplication and modulus operations are implemented by support routines.
These support routines are all developed in ANSI-C to facilitate porting
For signed & unsigned int (16 bit) and long (32 bit) variables, division,
multiplication and modulus operations are implemented by support routines.
These support routines are all developed in ANSI-C to facilitate porting
used.
The following files contain the described routines, all of them can be
found in <installdir>/share/sdcc/lib.
used.
The following files contain the described routines, all of them can be
found in <installdir>/share/sdcc/lib.
<lyxtabular version="3" rows="11" columns="2">
<features>
<column alignment="left" valignment="top" leftline="true" width="0">
<lyxtabular version="3" rows="11" columns="2">
<features>
<column alignment="left" valignment="top" leftline="true" width="0">
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
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
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
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.
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.
SDCC supports IEEE (single precision 4 bytes) floating point numbers.
The floating point support routines are derived from gcc's floatlib.c and
consist of the following routines:
SDCC supports IEEE (single precision 4 bytes) floating point numbers.
The floating point support routines are derived from gcc's floatlib.c and
consist of the following routines:
<lyxtabular version="3" rows="17" columns="2">
<features>
<column alignment="left" valignment="top" leftline="true" width="0">
<lyxtabular version="3" rows="17" columns="2">
<features>
<column alignment="left" valignment="top" leftline="true" width="0">
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
Also notice that you don't have to call this routines directly.
The compiler will use them automatically every time a floating point operation
is required.
Also notice that you don't have to call this routines directly.
The compiler will use them automatically every time a floating point operation
is required.
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
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
(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
(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
support long variables and field widths).
Be shure to only use only one of these printf options within a project.
support long variables and field widths).
Be shure to only use only one of these printf options within a project.
<column alignment="center" valignment="top" leftline="true" width="0">
<column alignment="center" valignment="top" leftline="true" width="12col%">
<column alignment="center" valignment="top" leftline="true" width="10col%">
<column alignment="center" valignment="top" leftline="true" width="0">
<column alignment="center" valignment="top" leftline="true" width="12col%">
<column alignment="center" valignment="top" leftline="true" width="10col%">
</cell>
</row>
<row topline="true" endhead="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" endhead="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" endhead="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" endhead="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
+\end_inset
+</cell>
+<cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
+\begin_inset Text
+
+\begin_layout Standard
+1.6k / 1.6k
+\end_layout
+
+\end_inset
+</cell>
+<cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
+\begin_inset Text
+
+\begin_layout Standard
+0.26k / 0.26k
+\end_layout
+
+\end_inset
+</cell>
+</row>
+<row topline="true">
+<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
+\begin_inset Text
+
+\begin_layout Standard
+formats
+\end_layout
+
+\end_inset
+</cell>
+<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
+\begin_inset Text
+
+\begin_layout Standard
+cdi
+\emph on
+o
+\emph default
+psux
+\end_layout
+
+\end_inset
+</cell>
+<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
+\begin_inset Text
+
+\begin_layout Standard
+
+\family roman
+\series medium
+\shape up
+\size normal
+\emph off
+\bar no
+\noun off
+\end_layout
+
+\end_inset
+</cell>
+</row>
+<row bottomline="true">
+<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
+\begin_inset Text
+
+\begin_layout Standard
+string speed
+\begin_inset Foot
+status collapsed
+
+\begin_layout Standard
+Execution time of printf("%s%c%s%c%c%c", "Hello", ' ', "World", '!', '
+\backslash
+r', '
+\backslash
+n'); standard 8051 @ 22.1184 MHz, empty putchar()
+\end_layout
+
+\end_inset
+
+,
+\end_layout
+
+\begin_layout Standard
+small / large
+\end_layout
+
+\end_inset
+</cell>
+<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
+\begin_inset Text
+
+\begin_layout Standard
+1.52 / 2.59 ms
+\end_layout
+
+\end_inset
+</cell>
+<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
+\begin_inset Text
+
+\begin_layout Standard
+1.53 / 2.62 ms
+\end_layout
+
+\end_inset
+</cell>
+<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
+\begin_inset Text
+
+\begin_layout Standard
+0.92 / 0.93 ms
+\end_layout
+
+\end_inset
+</cell>
+<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
+\begin_inset Text
+
+\begin_layout Standard
+0.45 / 0.45 ms
+\end_layout
+
+\end_inset
+</cell>
+<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
+\begin_inset Text
+
+\begin_layout Standard
+0.46 / 0.46 ms
+\end_layout
+
+\end_inset
+\begin_layout Standard
+0.25 / 0.25 ms
+\end_layout
+
+\end_inset
+</cell>
+</row>
+<row bottomline="true">
+<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
+\begin_inset Text
+
+\begin_layout Standard
+long speed
+\begin_inset Foot
+status collapsed
+
+\begin_layout Standard
+Execution time of printf("%ld", -123456789); standard 8051 @ 22.1184 MHz,
+ empty putchar()
+\end_layout
+
+\end_inset
+
+,
+\end_layout
+
+\begin_layout Standard
+small / large
+\end_layout
+
+\end_inset
+</cell>
+<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
+\begin_inset Text
+
+\begin_layout Standard
+5.37 / 6.31 ms
+\end_layout
+
+\end_inset
+</cell>
+<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
+\begin_inset Text
+
+\begin_layout Standard
+5.37 / 6.31 ms
+\end_layout
+\begin_layout Standard
+-
+\end_layout
+
+\end_inset
+</cell>
+</row>
+<row bottomline="true">
+<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
+\begin_inset Text
+
+\begin_layout Standard
+float speed
+\begin_inset Foot
+status collapsed
+
+\begin_layout Standard
+Execution time of printf("%.3f", -12345.678); standard 8051 @ 22.1184 MHz,
+ empty putchar()
+\end_layout
+
+\end_inset
+
+,
+\end_layout
+
+\begin_layout Standard
+small / large
+\end_layout
+
+\end_inset
+</cell>
+<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
+\begin_inset Text
+
+\begin_layout Standard
+-
+\end_layout
+
+\end_inset
+</cell>
+<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
+\begin_inset Text
+
+\begin_layout Standard
+7.49 / 22.47 ms
+\end_layout
+
+\end_inset
+</cell>
+<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
+\begin_inset Text
+
+\begin_layout Standard
+-
+\end_layout
+
+\end_inset
+</cell>
+<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
+\begin_inset Text
+
+\begin_layout Standard
+-
+\end_layout
+
+\end_inset
+</cell>
+<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
+\begin_inset Text
+
+\begin_layout Standard
+1.04 / 1.04 ms
+\end_layout
+
+\end_inset
+</cell>
+<cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
+\begin_inset Text
As of SDCC 2.6.2 you no longer need to call an initialization routine before
using dynamic memory allocation
\begin_inset LatexCommand \index{dynamic memory allocation (malloc)}
As of SDCC 2.6.2 you no longer need to call an initialization routine before
using dynamic memory allocation
\begin_inset LatexCommand \index{dynamic memory allocation (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:
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:
included in SDCC should have a license at least as liberal as the GNU Lesser
General Public License
\begin_inset LatexCommand \index{GNU Lesser General Public License, LGPL}
included in SDCC should have a license at least as liberal as the GNU Lesser
General Public License
\begin_inset LatexCommand \index{GNU Lesser General Public License, LGPL}
or _decdptr f.e.
come with a GPL (as opposed to LGPL) License - this will not be liberal
enough for many embedded programmers.
or _decdptr f.e.
come with a GPL (as opposed to LGPL) License - this will not be liberal
enough for many embedded programmers.
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
\begin_inset Formula $^{\textrm{2}}$
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
\begin_inset Formula $^{\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
\begin_inset LatexCommand \url{http://sourceforge.net/mail/?group_id=599}
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
\begin_inset LatexCommand \url{http://sourceforge.net/mail/?group_id=599}
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 searchabl
e these references are very valuable.
Let's help to create a climate where information is shared.
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 searchabl
e these references are very valuable.
Let's help to create a climate where information is shared.
be combined together or the results would be unpredictable.
The library routines supplied with the compiler are compiled as small,
medium and large.
The compiled library modules are contained in separate directories as small,
medium and large so that you can link to the appropriate set.
be combined together or the results would be unpredictable.
The library routines supplied with the compiler are compiled as small,
medium and large.
The compiled library modules are contained in separate directories as small,
medium and large so that you can link to the appropriate set.
When the medium or large model is used all variables declared without a
storage class will be allocated into the external ram, this includes all
parameters and local variables (for non-reentrant
\begin_inset LatexCommand \index{reentrant}
When the medium or large model is used all variables declared without a
storage class will be allocated into the external ram, this includes all
parameters and local variables (for non-reentrant
\begin_inset LatexCommand \index{reentrant}
Judicious usage of the processor specific storage classes
\begin_inset LatexCommand \index{Storage class}
Judicious usage of the processor specific storage classes
\begin_inset LatexCommand \index{Storage class}
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.
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.
-xstack option is used to compile the program, the parameters and local
variables
\begin_inset LatexCommand \index{local variables}
-xstack option is used to compile the program, the parameters and local
variables
\begin_inset LatexCommand \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 -
\begin_inset ERT
of all reentrant functions are allocated in this area.
This option is provided for programs with large stack space requirements.
When used with the -
\begin_inset ERT
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).
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
\begin_inset LatexCommand \index{P2 (mcs51 sfr)}
The compiler outputs the higher order address byte of the external ram segment
into port P2
\begin_inset LatexCommand \index{P2 (mcs51 sfr)}
In this mode, up to four meg of external RAM or code space can be directly
addressed.
See the data sheets at www.dalsemi.com for further information on this part.
In this mode, up to four meg of external RAM or code space can be directly
addressed.
See the data sheets at www.dalsemi.com for further information on this part.
, the boot loader or similar code must ensure that the processor is in 24
bit contiguous addressing mode before calling the SDCC startup code.
, the boot loader or similar code must ensure that the processor is in 24
bit contiguous addressing mode before calling the SDCC startup code.
-*-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
-*-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
on the SDCC command line.
However, currently the linker can not handle code segments > 64k.
on the SDCC command line.
However, currently the linker can not handle code segments > 64k.
- 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.
- 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.
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 & popping
\begin_inset LatexCommand \index{push/pop}
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 & popping
\begin_inset LatexCommand \index{push/pop}
when calling small functions from larger functions.
This option can be used to switch off the register saving convention for
when calling small functions from larger functions.
This option can be used to switch off the register saving convention for
none | {acc[,b[,dpl[,dph]]] - The exclude pragma disables the generation
of pairs of push/pop
\begin_inset LatexCommand \index{push/pop}
none | {acc[,b[,dpl[,dph]]] - The exclude pragma disables the generation
of pairs of push/pop
\begin_inset LatexCommand \index{push/pop}
outines.
The directive should be placed immediately before the ISR function definition
and it affects ALL ISR functions following it.
outines.
The directive should be placed immediately before the ISR function definition
and it affects ALL ISR functions following it.
- will not do loop invariant optimizations.
For more details see Loop Invariants in section
\begin_inset LatexCommand \ref{sub:Loop-Optimizations}
- will not do loop invariant optimizations.
For more details see Loop Invariants in section
\begin_inset LatexCommand \ref{sub:Loop-Optimizations}
entries for all ISR functions defined after the pragma.
This is useful in cases where the interrupt vector table must be defined
entries for all ISR functions defined after the pragma.
This is useful in cases where the interrupt vector table must be defined
number after the interrupt keyword, see section
\begin_inset LatexCommand \ref{sub:Interrupt-Service-Routines}
number after the interrupt keyword, see section
\begin_inset LatexCommand \ref{sub:Interrupt-Service-Routines}
- will not generate code for boundary value checking, when switch statements
are turned into jump-tables (dangerous).
For more details see section
\begin_inset LatexCommand \ref{sub:'switch'-Statements}
- will not generate code for boundary value checking, when switch statements
are turned into jump-tables (dangerous).
For more details see section
\begin_inset LatexCommand \ref{sub:'switch'-Statements}
- The compiler will optimize code generation towards fast code, possibly
at the expense of code size.
Currently this has little effect.
- The compiler will optimize code generation towards fast code, possibly
at the expense of code size.
Currently this has little effect.
- The compiler will optimize code generation towards compact code, possibly
at the expense of code speed.
Currently this has little effect.
- The compiler will optimize code generation towards compact code, possibly
at the expense of code speed.
Currently this has little effect.
- 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).
- 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).
- Generally follow the C89 standard, but allow SDCC features that conflict
with the standard (default).
- Generally follow the C89 standard, but allow SDCC features that conflict
with the standard (default).
- Generally follow the C99 standard, but allow SDCC features that conflict
with the standard (incomplete support).
- Generally follow the C99 standard, but allow SDCC features that conflict
with the standard (incomplete support).
- Follow the C99 standard and disable SDCC features that conflict with the
standard (incomplete support).
- Follow the C99 standard and disable SDCC features that conflict with the
standard (incomplete support).
(+ | -) - Pedantic parse numbers so that situations like 0xfe-LO_B(3) are
parsed properly and the macro LO_B(3) gets expanded.
Default is off.
Below is an example on how to use this pragma.
(+ | -) - Pedantic parse numbers so that situations like 0xfe-LO_B(3) are
parsed properly and the macro LO_B(3) gets expanded.
Default is off.
Below is an example on how to use this pragma.
This will prevent the preprocessor from changing the formating required
by assembly code.
Below is an example on how to use this pragma.
This will prevent the preprocessor from changing the formating required
by assembly code.
Below is an example on how to use this pragma.
The pragma's are intended to be used to turn-on or off certain optimizations
which might cause the compiler to generate extra stack / data space to
store compiler generated temporary variables.
The pragma's are intended to be used to turn-on or off certain optimizations
which might cause the compiler to generate extra stack / data space to
store compiler generated temporary variables.
are used to control options & optimizations for a given function; pragmas
should be placed before and/or after a function, placing pragma's inside
a function body could have unpredictable results.
are used to control options & optimizations for a given function; pragmas
should be placed before and/or after a function, placing pragma's inside
a function body could have unpredictable results.
The compiler will generate a warning message when extra space is allocated.
It is strongly recommended that the save and restore pragma's be used when
changing options for a function.
The compiler will generate a warning message when extra space is allocated.
It is strongly recommended that the save and restore pragma's be used when
changing options for a function.
<lyxtabular version="3" rows="11" columns="2">
<features>
<column alignment="left" valignment="top" leftline="true" width="3in">
<lyxtabular version="3" rows="11" columns="2">
<features>
<column alignment="left" valignment="top" leftline="true" width="3in">
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
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.
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.
With the upcome of devices with internal xdata and flash memory devices
using port P2
\begin_inset LatexCommand \index{P2 (mcs51 sfr)}
With the upcome of devices with internal xdata and flash memory devices
using port P2
\begin_inset LatexCommand \index{P2 (mcs51 sfr)}
as dedicated I/O port is becoming more popular.
Switching the high byte for pdata
\begin_inset LatexCommand \index{pdata (mcs51, ds390 storage class)}
as dedicated I/O port is becoming more popular.
Switching the high byte for pdata
\begin_inset LatexCommand \index{pdata (mcs51, ds390 storage class)}
access which was formerly done by port P2 is then achieved by a Special
Function Register
\begin_inset LatexCommand \index{sfr}
access which was formerly done by port P2 is then achieved by a Special
Function Register
\begin_inset LatexCommand \index{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
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
For more exotic implementations further customizations may be needed.
See section
\begin_inset LatexCommand \ref{sub:Startup-Code}
For more exotic implementations further customizations may be needed.
See section
\begin_inset LatexCommand \ref{sub:Startup-Code}
, 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.
, 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.
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
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
) as the MCS51 and DS390 ports, so floating point support, support for long
variables and bitfield support is fine.
See mailing lists and forums about interrupt routines.
) as the MCS51 and DS390 ports, so floating point support, support for long
variables and bitfield support is fine.
See mailing lists and forums about interrupt routines.
As always, the code is the authoritative reference - see z80/ralloc.c and
z80/gen.c.
The stack
\begin_inset LatexCommand \index{Z80!stack}
As always, the code is the authoritative reference - see z80/ralloc.c and
z80/gen.c.
The stack
\begin_inset LatexCommand \index{Z80!stack}
frame is similar to that generated by the IAR Z80 compiler.
IX is used as the base pointer, HL and IY are used as a temporary registers,
frame is similar to that generated by the IAR Z80 compiler.
IX is used as the base pointer, HL and IY are used as a temporary registers,
for the Z80 port are stored in L (one byte), HL (two bytes), or DEHL (four
bytes).
The gbz80 port use the same set of registers for the return values, but
in a different order of significance: E (one byte), DE (two bytes), or
HLDE (four bytes).
for the Z80 port are stored in L (one byte), HL (two bytes), or DEHL (four
bytes).
The gbz80 port use the same set of registers for the return values, but
in a different order of significance: E (one byte), DE (two bytes), or
HLDE (four bytes).
unoptimized.
Some of the SDCC's standard C library functions have embedded non-HC08
inline assembly and so are not yet usable.
unoptimized.
Some of the SDCC's standard C library functions have embedded non-HC08
inline assembly and so are not yet usable.
The HC08 port passes the regression test suite (see section
\begin_inset LatexCommand \ref{sec:Quality-control}
The HC08 port passes the regression test suite (see section
\begin_inset LatexCommand \ref{sec:Quality-control}
port still requires a major effort from the development community.
However it can work for simple code.
It passes its (smaller set of) regression tests
\begin_inset LatexCommand \index{Regression test (PIC14)}
port still requires a major effort from the development community.
However it can work for simple code.
It passes its (smaller set of) regression tests
\begin_inset LatexCommand \index{Regression test (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
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
used.
The compiler treats all functions of a single C file as being in the same
code page unless it is non static.
used.
The compiler treats all functions of a single C file as being in the same
code page unless it is non static.
For devices that have multiple code pages it is more efficient to use the
same number of files as pages, i.e.
for the 16F877 use 4 separate files and i.e.
for the 16F874 use 2 separate files.
This way the linker can put the code for each file into different code
pages and there's less page selection overhead.
For devices that have multiple code pages it is more efficient to use the
same number of files as pages, i.e.
for the 16F877 use 4 separate files and i.e.
for the 16F874 use 2 separate files.
This way the linker can put the code for each file into different code
pages and there's less page selection overhead.
And as for any 8 bit micro (especially for PIC 14 as they have a very simple
instruction set), use 'unsigned char' whereever possible instead of 'int'.
And as for any 8 bit micro (especially for PIC 14 as they have a very simple
instruction set), use 'unsigned char' whereever possible instead of 'int'.
For the interrupt function, use the keyword '__interrupt'
\begin_inset LatexCommand \index{PIC14!interrupt}
For the interrupt function, use the keyword '__interrupt'
\begin_inset LatexCommand \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.:
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.:
gpasm.exe or MPLAB's mpasmwin.exe.
GPUTILS is available from
\begin_inset LatexCommand \url{http://sourceforge.net/projects/gputils}
gpasm.exe or MPLAB's mpasmwin.exe.
GPUTILS is available from
\begin_inset LatexCommand \url{http://sourceforge.net/projects/gputils}
.
For linking you can use either GPUTIL's 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.
.
For linking you can use either GPUTIL's 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.
Besides the switches common to all SDCC backends, the PIC14 port accepts
the following options (for an updated list see sdcc -
\begin_inset ERT
Besides the switches common to all SDCC backends, the PIC14 port accepts
the following options (for an updated list see sdcc -
\begin_inset ERT
sets the lowest address of the argument passing stack (defaults to a suitably
large shared databank to reduce BANKSEL overhead)
sets the lowest address of the argument passing stack (defaults to a suitably
large shared databank to reduce BANKSEL overhead)
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
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
to the linker's arguments.
Make sure you also add an include path for the library (using the -I switch
to the linker)!
to the linker's arguments.
Make sure you also add an include path for the library (using the -I switch
to the linker)!
This warning can usually be ignored due to the very good compatibility amongst
14 bit PIC
\begin_inset LatexCommand \index{PIC14}
This warning can usually be ignored due to the very good compatibility amongst
14 bit PIC
\begin_inset LatexCommand \index{PIC14}
You might also consider recompiling the library for your specific device
by changing the ARCH=p16f877 (default target) entry in
You might also consider recompiling the library for your specific device
by changing the ARCH=p16f877 (default target) entry in
port is the portion of SDCC that is responsible to produce code for the
Microchip
\begin_inset LatexCommand \index{Microchip}
port is the portion of SDCC that is responsible to produce code for the
Microchip
\begin_inset LatexCommand \index{Microchip}
(TM) microcontrollers with 16 bit core.
Currently this family of microcontrollers contains the PIC18Fxxx and PIC18Fxxxx.
Currently supported devices are:
(TM) microcontrollers with 16 bit core.
Currently this family of microcontrollers contains the PIC18Fxxx and PIC18Fxxxx.
Currently supported devices are:
<lyxtabular version="3" rows="4" columns="6">
<features>
<column alignment="center" valignment="top" leftline="true" width="0">
<lyxtabular version="3" rows="4" columns="6">
<features>
<column alignment="center" valignment="top" leftline="true" width="0">
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
PIC16 port supports the standard command line arguments as supposed, with
the exception of certain cases that will be mentioned in the following
list:
PIC16 port supports the standard command line arguments as supposed, with
the exception of certain cases that will be mentioned in the following
list:
-pstack-model=[model] Used in conjuction with the command above.
Defines the stack model to be used, valid stack models are :
-pstack-model=[model] Used in conjuction with the command above.
Defines the stack model to be used, valid stack models are :
Selects small stack model.
8 bit stack and frame pointers.
Supports 256 bytes stack size.
Selects small stack model.
8 bit stack and frame pointers.
Supports 256 bytes stack size.
Selects large stack model.
16 bit stack and frame pointers.
Supports 65536 bytes stack size.
Selects large stack model.
16 bit stack and frame pointers.
Supports 65536 bytes stack size.
-preplace-udata-with=[kword] Replaces the default udata keyword for allocating
unitialized data variables with [kword].
Valid keywords are: "udata_acs", "udata_shr", "udata_ovr".
-preplace-udata-with=[kword] Replaces the default udata keyword for allocating
unitialized data variables with [kword].
Valid keywords are: "udata_acs", "udata_shr", "udata_ovr".
1 checks previous used register and if it is the same then does not emit
BANKSEL, accounts only for labels.
1 checks previous used register and if it is the same then does not emit
BANKSEL, accounts only for labels.
2 tries to check the location of (even different) symbols and removes BANKSELs
if they are in the same bank.
2 tries to check the location of (even different) symbols and removes BANKSELs
if they are in the same bank.
-debug-ralloc Force register allocator to dump <source>.d file with debugging
information.
<source> is the name of the file compiled.
-debug-ralloc Force register allocator to dump <source>.d file with debugging
information.
<source> is the name of the file compiled.
There is a number of enviromental 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/dis
abled at will.
There is a number of enviromental 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/dis
abled at will.
OPTIMIZE_BITFIELD_POINTER_GET when this variable exists reading of structure
bitfields is optimized by directly loading FSR0 with the address of the
bitfield structure.
OPTIMIZE_BITFIELD_POINTER_GET when this variable exists reading of structure
bitfields is optimized by directly loading FSR0 with the address of the
bitfield structure.
NO_REG_OPT do not perform pCode registers optimization.
This should be used for debugging purposes.
In some where bugs in the pcode optimizer are found, users can benefit
from temporarily disabling the optimizer until the bug is fixed.
NO_REG_OPT do not perform pCode registers optimization.
This should be used for debugging purposes.
In some where bugs in the pcode optimizer are found, users can benefit
from temporarily disabling the optimizer until the bug is fixed.
<lyxtabular version="3" rows="6" columns="2">
<features>
<column alignment="center" valignment="top" leftline="true" width="0">
<lyxtabular version="3" rows="6" columns="2">
<features>
<column alignment="center" valignment="top" leftline="true" width="0">
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
<lyxtabular version="3" rows="4" columns="2">
<features>
<column alignment="center" valignment="top" leftline="true" width="0">
<lyxtabular version="3" rows="4" columns="2">
<features>
<column alignment="center" valignment="top" leftline="true" width="0">
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
<lyxtabular version="3" rows="3" columns="4">
<features>
<column alignment="center" valignment="top" leftline="true" width="0">
<lyxtabular version="3" rows="3" columns="4">
<features>
<column alignment="center" valignment="top" leftline="true" width="0">
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
forces the code generator to initialize the stack & frame pointers at a
specific address.
This is an adhoc solution for cases where no STACK directive is available
in the linker script or gplink is not instructed to create a stack section.
forces the code generator to initialize the stack & frame pointers at a
specific address.
This is an adhoc solution for cases where no STACK directive is available
in the linker script or gplink is not instructed to create a stack section.
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 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.
is the lower bound of the stack section.
The stack pointer initially will point at address (bottom_address+stack_size-1).
is the lower bound of the stack section.
The stack pointer initially will point at address (bottom_address+stack_size-1).
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.
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.
can be any library or object file (including its path).
Note that there are four reserved keywords which have special meaning.
These are:
can be any library or object file (including its path).
Note that there are four reserved keywords which have special meaning.
These are:
<lyxtabular version="3" rows="6" columns="3">
<features>
<column alignment="center" valignment="top" leftline="true" width="0">
<lyxtabular version="3" rows="6" columns="3">
<features>
<column alignment="center" valignment="top" leftline="true" width="0">
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
This feature allows for linking with specific libraries withoug having to
explicit name them in the command line.
Note that the
This feature allows for linking with specific libraries withoug having to
explicit name them in the command line.
Note that the
udata pragma udata instructs the compiler to emit code so that linker will
place a variable at a specific memory bank
udata pragma udata instructs the compiler to emit code so that linker will
place a variable at a specific memory bank
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:
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:
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.
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.
.
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:
.
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:
The specific microcontroller is selected within the pic18fregs.h automatically,
so the same source can be used with a variety of devices.
The specific microcontroller is selected within the pic18fregs.h automatically,
so the same source can be used with a variety of devices.
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
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
is the microcontroller identification number.
The specific library is selected automatically by the compiler at link
stage according to the selected device.
is the microcontroller identification number.
The specific library is selected automatically by the compiler at link
stage according to the selected device.
Libraries are created with gplib which is part of the gputils package
\begin_inset LatexCommand \url{http://sourceforge.net/projects/gputils}
Libraries are created with gplib which is part of the gputils package
\begin_inset LatexCommand \url{http://sourceforge.net/projects/gputils}
Before using SDCC/pic16 there are some libraries that need to be compiled.
This process is not done automatically by SDCC since not all users use
SDCC for pic16 projects.
So each user should compile the libraries separately.
Before using SDCC/pic16 there are some libraries that need to be compiled.
This process is not done automatically by SDCC since not all users use
SDCC for pic16 projects.
So each user should compile the libraries separately.
There exist a special target to build the I/O libraries.
This target is not automatically build because it will build the I/O library
for
There exist a special target to build the I/O libraries.
This target is not automatically build because it will build the I/O library
for
Memory model affects the default size of pointers within the source.
The sizes are shown in the next table:
Memory model affects the default size of pointers within the source.
The sizes are shown in the next table:
<lyxtabular version="3" rows="3" columns="3">
<features>
<column alignment="center" valignment="top" leftline="true" rightline="true" width="0">
<lyxtabular version="3" rows="3" columns="3">
<features>
<column alignment="center" valignment="top" leftline="true" rightline="true" width="0">
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
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
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
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:
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:
<lyxtabular version="3" rows="3" columns="3">
<features>
<column alignment="center" valignment="top" leftline="true" rightline="true" width="0">
<lyxtabular version="3" rows="3" columns="3">
<features>
<column alignment="center" valignment="top" leftline="true" rightline="true" width="0">
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
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:
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:
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.
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.
In addition to the standard SDCC function keywords, PIC16
\begin_inset LatexCommand \index{PIC16}
In addition to the standard SDCC function keywords, PIC16
\begin_inset LatexCommand \index{PIC16}
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:
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:
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
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
instructs the code generator not to store/restore WREG, STATUS, BSR when
entering/exiting the ISR.
instructs the code generator not to store/restore WREG, STATUS, BSR when
entering/exiting the ISR.
Return values from functions are placed to the appropriate registers following
a modified Microchip policy optimized for SDCC.
The following table shows these registers:
Return values from functions are placed to the appropriate registers following
a modified Microchip policy optimized for SDCC.
The following table shows these registers:
<lyxtabular version="3" rows="6" columns="2">
<features>
<column alignment="center" valignment="top" leftline="true" width="0">
<lyxtabular version="3" rows="6" columns="2">
<features>
<column alignment="center" valignment="top" leftline="true" width="0">
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
<lyxtabular version="3" rows="4" columns="3">
<features>
<column alignment="center" valignment="top" leftline="true" width="0">
<lyxtabular version="3" rows="4" columns="3">
<features>
<column alignment="center" valignment="top" leftline="true" width="0">
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
which points at the genetated ISR.
This single GOTO instruction is part of an automatically generated
which points at the genetated ISR.
This single GOTO instruction is part of an automatically generated
function.
The actuall 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
function.
The actuall 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
generated.
The whole interrupt functions is therefore placed at the Interrupt Vector
Address of the specific interrupt.
generated.
The whole interrupt functions is therefore placed at the Interrupt Vector
Address of the specific interrupt.
at the next interrupt´s vector address and cause undeterminate program
behaviour if that interrupt is raised.
\begin_inset Foot
at the next interrupt´s vector address and cause undeterminate program
behaviour if that interrupt is raised.
\begin_inset Foot
is possible to be omitted.
This way a function is generated similar to an ISR, but it is not assigned
to any interrupt.
is possible to 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
\begin_inset LatexCommand \index{PIC16}
When entering an interrupt, currently the PIC16
\begin_inset LatexCommand \index{PIC16}
NOTE that when the _naked attribute is specified for an interrupt routine,
then NO registers are stored or restored.
NOTE that when the _naked attribute is specified for an interrupt routine,
then NO registers are stored or restored.
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:
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:
<lyxtabular version="3" rows="5" columns="5">
<features>
<column alignment="center" valignment="top" leftline="true" rightline="true" width="0">
<lyxtabular version="3" rows="5" columns="5">
<features>
<column alignment="center" valignment="top" leftline="true" rightline="true" width="0">
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
Generic pointer are read and written with a set of library functions which
read/write 1, 2, 3, 4 bytes.
Generic pointer are read and written with a set of library functions which
read/write 1, 2, 3, 4 bytes.
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:
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:
<lyxtabular version="3" rows="2" columns="7">
<features>
<column alignment="center" valignment="top" leftline="true" rightline="true" width="0">
<lyxtabular version="3" rows="2" columns="7">
<features>
<column alignment="center" valignment="top" leftline="true" rightline="true" width="0">
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
<lyxtabular version="3" rows="4" columns="4">
<features>
<column alignment="center" valignment="top" leftline="true" width="0">
<lyxtabular version="3" rows="4" columns="4">
<features>
<column alignment="center" valignment="top" leftline="true" width="0">
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
is declared in stdio.h as having its parameter in WREG (it has the wparam
keyword).
In stdio.h exists the macro PUTCHAR(arg) that defines the putchar function
in a user-friendly way.
is declared in stdio.h as having its parameter in WREG (it has the wparam
keyword).
In stdio.h exists the macro PUTCHAR(arg) that defines the putchar function
in a user-friendly way.
PIC16 contains an implementation of the printf-family of functions.
There exist the following functions:
PIC16 contains an implementation of the printf-family of functions.
There exist the following functions:
should normally be a data pointer where the resulting string will be placed.
No range checking is done so the user should allocate the necessery buffer.
For fprintf and vfprintf
should normally be a data pointer where the resulting string will be placed.
No range checking is done so the user should allocate the necessery buffer.
For fprintf and vfprintf
should be a stream pointer (i.e.
stdout, STREAM_MSSP, etc...).
should be a stream pointer (i.e.
stdout, STREAM_MSSP, etc...).
The PIC18F family of microcontrollers supports a number of interrupt sources.
A list of these interrupts is shown in the following table:
The PIC18F family of microcontrollers supports a number of interrupt sources.
A list of these interrupts is shown in the following table:
<lyxtabular version="3" rows="11" columns="4">
<features>
<column alignment="left" valignment="top" leftline="true" width="0">
<lyxtabular version="3" rows="11" columns="4">
<features>
<column alignment="left" valignment="top" leftline="true" width="0">
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
size (that is 64 bytes) probably is enough for many programs.
One must take care that when there are many levels of function nesting,
size (that is 64 bytes) probably is enough for many programs.
One must take care that when there are many levels of function nesting,
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:
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:
It is should be understood that stack is easily consumed when calling complicate
d functions.
Using command line arguments like -
\begin_inset ERT
It is should be understood that stack is easily consumed when calling complicate
d functions.
Using command line arguments like -
\begin_inset ERT
-fommit-frame-pointer might reduce stack usage by not creating unnecessery
stack frames.
Other ways to reduce stack usage may exist.
-fommit-frame-pointer might reduce stack usage by not creating unnecessery
stack frames.
Other ways to reduce stack usage may exist.
The PIC16 Port currently does not pass SDCC's regression test
\begin_inset LatexCommand \index{Regression test (PIC16)}
The PIC16 Port currently does not pass SDCC's regression test
\begin_inset LatexCommand \index{Regression test (PIC16)}
) and thus the nightly regression tests for the PIC16 target are currently
disabled for all hosts except for
) and thus the nightly regression tests for the PIC16 target are currently
disabled for all hosts except for
This means you can see the result of the PIC16 regression tests f.e.
by checking the log files in
\begin_inset LatexCommand \url{http://sdcc.sourceforge.net/regression_test_results/amd64-unknown-linux2.3/}
This means you can see the result of the PIC16 regression tests f.e.
by checking the log files in
\begin_inset LatexCommand \url{http://sdcc.sourceforge.net/regression_test_results/amd64-unknown-linux2.3/}
There are several approaches to debugging your code.
This chapter is meant to show your options and to give detail on some of
them:
There are several approaches to debugging your code.
This chapter is meant to show your options and to give detail on some of
them:
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, ...)
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, ...)
run a syntax-checking tool like splint
\begin_inset LatexCommand \index{splint (syntax checking tool)}
run a syntax-checking tool like splint
\begin_inset LatexCommand \index{splint (syntax checking tool)}
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 -
\begin_inset ERT
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 -
\begin_inset ERT
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.
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.
there is a separate section about SDCDB (section
\begin_inset LatexCommand \ref{cha:Debugging-with-SDCDB}
there is a separate section about SDCDB (section
\begin_inset LatexCommand \ref{cha:Debugging-with-SDCDB}
or (8051 specific) use a freeware/commercial simulator which interfaces
to the AOMF
\begin_inset LatexCommand \index{AOMF, AOMF51}
or (8051 specific) use a freeware/commercial simulator which interfaces
to the AOMF
\begin_inset LatexCommand \index{AOMF, AOMF51}
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.
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.
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
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
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 f.e.
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 f.e.
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
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
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.
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?)
Terms to enter into your favourite search engine could be 'remote debugging',
'gdb stub' or 'inferior debugger'.
(is there one?)
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
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
doesn't affect runtime behaviour until a breakpoint is hit.
For the mcs51 most hardware debuggers use the AOMF
\begin_inset LatexCommand \index{AOMF, AOMF51}
doesn't affect runtime behaviour until a breakpoint is hit.
For the mcs51 most hardware debuggers use the AOMF
\begin_inset LatexCommand \index{AOMF, AOMF51}
if you are not familiar with any of the following terms you're likely to
run into problems rather sooner than later:
if you are not familiar with any of the following terms you're likely to
run into problems rather sooner than later:
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.
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.
.
The debugger uses a command line interface, the command repertoire of the
debugger has been kept as close to gdb
\begin_inset LatexCommand \index{gdb}
.
The debugger uses a command line interface, the command repertoire of the
debugger has been kept as close to gdb
\begin_inset LatexCommand \index{gdb}
(the GNU debugger) as possible.
The configuration and build process is part of the standard compiler installati
(the GNU debugger) as possible.
The configuration and build process is part of the standard compiler installati
specified during configuration.
The debugger allows you debug BOTH at the C source and at the ASM source
level.
specified during configuration.
The debugger allows you debug BOTH at the C source and at the ASM source
level.
-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
-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
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
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
The debugger can be started using the following command line.
(Assume the file you are debugging has the file name foo).
The debugger can be started using the following command line.
(Assume the file you are debugging has the file name foo).
-cpu <cpu-type> - this argument is passed to the simulator please see the
simulator docs for details.
-cpu <cpu-type> - this argument is passed to the simulator please see the
simulator docs for details.
-X <Clock frequency > this options is passed to the simulator please see
the simulator docs for details.
-X <Clock frequency > this options is passed to the simulator please see
the simulator docs for details.
As mentioned earlier the command interface for the debugger has been deliberatel
y 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.
As mentioned earlier the command interface for the debugger has been deliberatel
y 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.
Step program until it reaches a different source line.
Note: pressing <return> repeats the last command.
Step program until it reaches a different source line.
Note: pressing <return> repeats the last 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.
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.
The screenshot was included in sdccman.lyx cvs version 1.120 but later removed
as this broke the build system on Sourceforge (pdf-file was broken.
pdflatex does not accept eps files).
The screenshot was included in sdccman.lyx cvs version 1.120 but later removed
as this broke the build system on Sourceforge (pdf-file was broken.
pdflatex does not accept eps files).
(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.
(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.
Check that the double quotes or an apostroph within the command line survive
the LyX tool chain.
Previously the apostrophs got slanted in the PDF output so a cut and paste
did not work.
Check that the double quotes or an apostroph within the command line survive
the LyX tool chain.
Previously the apostrophs got slanted in the PDF output so a cut and paste
did not work.
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 installat
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 installat
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):
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):
.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:
.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:
-\newline
-The command line options that are passed to the simulator directly are bound
- to default values in the file sdcdbsrc.el.
+\newline
+The command line options that are passed to the simulator directly are
+ bound to default values in the file sdcdbsrc.el.
-\newline
-;;\SpecialChar ~
-g\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-sdcdbsrc-goto-sdcdb\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-Goto the SDCDB output buffer
-\newline
-;;\SpecialChar ~
-t\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-sdcdbsrc-mode\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-Toggles Sdcdbsrc mode (turns it off)
-\newline
+\newline
+;;\InsetSpace ~
+g\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+sdcdbsrc-goto-sdcdb\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+Got
+o the SDCDB output buffer
+\newline
+;;\InsetSpace ~
+t\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+sdcdbsrc-mode\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+Toggles Sdcdbsrc mode (turns it
+ off)
+\newline
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.
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.
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'.
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'.
can be omitted, if the result is the same.
The effect of the promotion rules together with the sign-extension is often
surprising:
can be omitted, if the result is the same.
The effect of the promotion rules together with the sign-extension is often
surprising:
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.
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.
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.)
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.)
-\newline
-Although character types (especially unsigned char) can be used as "tiny"
- integers, doing so is sometimes more trouble than it's worth, due to unpredicta
-ble sign extension and increased code size.
-\end_deeper
-\layout Itemize
-
+\newline
+Although
+ character types (especially unsigned char) can be used as "tiny" integers,
+ doing so is sometimes more trouble than it's worth, due to unpredictable
+ sign extension and increased code size.
+\end_layout
+
+\end_deeper
+\begin_layout Itemize
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.
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.
Porting code from or to other compilers
\begin_inset LatexCommand \label{sec:Porting-code-to-other-compilers}
Porting code from or to other compilers
\begin_inset LatexCommand \label{sec:Porting-code-to-other-compilers}
for compiler specific syntax.
Eventually include the file <compiler.h
\begin_inset LatexCommand \index{compiler.h (include file)}
for compiler specific syntax.
Eventually include the file <compiler.h
\begin_inset LatexCommand \index{compiler.h (include file)}
to allow using common header files.
(see f.e.
cc2510fx.h
\begin_inset LatexCommand \url{http://svn.sourceforge.net/viewvc/sdcc/trunk/sdcc/device/include/mcs51/cc2510fx.h?view=markup}
to allow using common header files.
(see f.e.
cc2510fx.h
\begin_inset LatexCommand \url{http://svn.sourceforge.net/viewvc/sdcc/trunk/sdcc/device/include/mcs51/cc2510fx.h?view=markup}
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
(
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
(
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
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
check the assembly code generated for interrupt routines (f.e.
for calls to possibly non-reentrant library functions).
check the assembly code generated for interrupt routines (f.e.
for calls to possibly non-reentrant library functions).
check whether timing loops result in proper timing (or preferably consider
a rewrite of the code with timer based delays instead).
check whether timing loops result in proper timing (or preferably consider
a rewrite of the code with timer based delays instead).
check for differences in printf parameters (some compilers push (va_arg
\begin_inset LatexCommand \index{vararg, va\_arg}
check for differences in printf parameters (some compilers push (va_arg
\begin_inset LatexCommand \index{vararg, va\_arg}
.
Usage of different memory spaces: code, stack, data (for mcs51/ds390 additional
ly idata, pdata, xdata).
Eventually check if unexpected library functions are included.
.
Usage of different memory spaces: code, stack, data (for mcs51/ds390 additional
ly idata, pdata, xdata).
Eventually check if unexpected library functions are included.
<lyxtabular version="3" rows="12" columns="3">
<features>
<column alignment="left" valignment="top" leftline="true" width="0pt">
<lyxtabular version="3" rows="12" columns="3">
<features>
<column alignment="left" valignment="top" leftline="true" width="0pt">
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
<lyxtabular version="3" rows="10" columns="2">
<features>
<column alignment="block" valignment="top" leftline="true" width="40col%">
<lyxtabular version="3" rows="10" columns="2">
<features>
<column alignment="block" valignment="top" leftline="true" width="40col%">
ASXXXX
\begin_inset LatexCommand \index{asXXXX (as-gbz80, as-hc08, asx8051, as-z80)}
ASXXXX
\begin_inset LatexCommand \index{asXXXX (as-gbz80, as-hc08, asx8051, as-z80)}
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
<lyxtabular version="3" rows="14" columns="3">
<features>
<column alignment="left" valignment="top" leftline="true" width="0pt">
<lyxtabular version="3" rows="14" columns="3">
<features>
<column alignment="left" valignment="top" leftline="true" width="0pt">
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
Debugger, serves nicely as GUI to SDCDB
\begin_inset LatexCommand \index{SDCDB (debugger)}
Debugger, serves nicely as GUI to SDCDB
\begin_inset LatexCommand \index{SDCDB (debugger)}
<lyxtabular version="3" rows="7" columns="3">
<features>
<column alignment="left" valignment="top" leftline="true" width="0pt">
<lyxtabular version="3" rows="7" columns="3">
<features>
<column alignment="left" valignment="top" leftline="true" width="0pt">
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
SDCC makes no claims about the completeness of this list and about up-to-datenes
s or correctness of the application notes
\begin_inset LatexCommand \index{Application notes}
SDCC makes no claims about the completeness of this list and about up-to-datenes
s or correctness of the application notes
\begin_inset LatexCommand \index{Application notes}
<lyxtabular version="3" rows="7" columns="3">
<features>
<column alignment="block" valignment="top" leftline="true" width="17col%">
<lyxtabular version="3" rows="7" columns="3">
<features>
<column alignment="block" valignment="top" leftline="true" width="17col%">
Using the Free SDCC C Compiler to Develop Firmware for the DS89C420/430/440/450
\begin_inset LatexCommand \index{DS89C4x0}
Using the Free SDCC C Compiler to Develop Firmware for the DS89C420/430/440/450
\begin_inset LatexCommand \index{DS89C4x0}
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
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?
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?
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?
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?
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?
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?
is the project done if you think it is done? Or is just that other interface/pro
tocol/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?
is the project done if you think it is done? Or is just that other interface/pro
tocol/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?
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).
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).
There are lots of ways to contribute, and we encourage you to take part
in making SDCC a great software package.
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
\begin_inset LatexCommand \htmlurl{http://sourceforge.net/projects/sdcc}
The SDCC project is hosted on the SDCC sourceforge site at
\begin_inset LatexCommand \htmlurl{http://sourceforge.net/projects/sdcc}
, forums, bug reporting system, patch submission
\begin_inset LatexCommand \index{Patch submission}
, forums, bug reporting system, patch submission
\begin_inset LatexCommand \index{Patch submission}
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.
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
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
option can sometimes be useful in locating optimization problems.
When reporting a bug please make sure you:
option can sometimes be useful in locating optimization problems.
When reporting a bug please make sure you:
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
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
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!
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:
\begin_inset LatexCommand \htmlurl{http://sourceforge.net/tracker/?group_id=599&atid=100599}
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:
\begin_inset LatexCommand \htmlurl{http://sourceforge.net/tracker/?group_id=599&atid=100599}
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.
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:
there must be some users.
So it's not exactly easy to find a new bug.
If you find one we need it:
Like bug reports feature requests are forwarded to the developer mailing
list.
This is the link for requesting features:
\begin_inset LatexCommand \htmlurl{http://sourceforge.net/tracker/?group_id=599&atid=350599}
Like bug reports feature requests are forwarded to the developer mailing
list.
This is the link for requesting features:
\begin_inset LatexCommand \htmlurl{http://sourceforge.net/tracker/?group_id=599&atid=350599}
Like bug reports contributed patches are forwarded to the developer mailing
list.
This is the link for submitting patches
\begin_inset LatexCommand \index{Patch submission}
Like bug reports contributed patches are forwarded to the developer mailing
list.
This is the link for submitting patches
\begin_inset LatexCommand \index{Patch submission}
These links should take you directly to the
\begin_inset LatexCommand \url[Mailing lists]{http://sourceforge.net/mail/?group_id=599}
These links should take you directly to the
\begin_inset LatexCommand \url[Mailing lists]{http://sourceforge.net/mail/?group_id=599}
Traffic on sdcc-devel and sdcc-user is about 100 mails/month each not counting
automated messages (mid 2003)
Traffic on sdcc-devel and sdcc-user is about 100 mails/month each not counting
automated messages (mid 2003)
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.
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.
or the filenames of the snapshot versions of SDCC include date and its
Subversion
\begin_inset LatexCommand \index{Subversion code repository}
or the filenames of the snapshot versions of SDCC include date and its
Subversion
\begin_inset LatexCommand \index{Subversion code repository}
number.
Subversion allows to download the source of recent or previous versions
\begin_inset LatexCommand \url{http://sourceforge.net/svn/?group_id=599}
number.
Subversion allows to download the source of recent or previous versions
\begin_inset LatexCommand \url{http://sourceforge.net/svn/?group_id=599}
Historically there often were long delays between official releases and
the sourceforge download area tends to get not updated at all.
Excuses in the past might have referred to problems with live range analysis,
Historically there often were long delays between official releases and
the sourceforge download area tends to get not updated at all.
Excuses in the past might have referred to problems with live range analysis,
daily snapshots available at
\begin_inset LatexCommand \htmlurl[snap]{http://sdcc.sourceforge.net/snap.php}
daily snapshots available at
\begin_inset LatexCommand \htmlurl[snap]{http://sdcc.sourceforge.net/snap.php}
, and you can always build the very last version (hopefully with many bugs
fixed, and features added) from the source code available at
\begin_inset LatexCommand \htmlurl[Source]{http://sdcc.sourceforge.net/snap.php#Source}
, and you can always build the very last version (hopefully with many bugs
fixed, and features added) from the source code available at
\begin_inset LatexCommand \htmlurl[Source]{http://sdcc.sourceforge.net/snap.php#Source}
I did insert a reference to Paul's web site here although it seems rather
dedicated to a specific 8032 board (I think it's okay because it f.e.
shows LCD/Harddisc interface and has a free 8051 monitor.
Independent 8032 board vendors face hard competition of heavily subsidized
development boards anyway).
I did insert a reference to Paul's web site here although it seems rather
dedicated to a specific 8032 board (I think it's okay because it f.e.
shows LCD/Harddisc interface and has a free 8051 monitor.
Independent 8032 board vendors face hard competition of heavily subsidized
development boards anyway).
Maybe we should include some links to real world applications.
Preferably pointer to pointers (one for each architecture) so this stays
manageable here?
Maybe we should include some links to real world applications.
Preferably pointer to pointers (one for each architecture) so this stays
manageable here?
check that SDCC itself compiles flawlessly on several host platforms (i386,
Opteron, 64 bit Alpha, ppc64, MacOS X on PPC, Solaris on Sparc) and checks
check that SDCC itself compiles flawlessly on several host platforms (i386,
Opteron, 64 bit Alpha, ppc64, MacOS X on PPC, Solaris on Sparc) and checks
(click on the red or green symbols on the right side of
\begin_inset LatexCommand \url{http://sdcc.sourceforge.net/snap.php}
(click on the red or green symbols on the right side of
\begin_inset LatexCommand \url{http://sdcc.sourceforge.net/snap.php}
if you don't want to run the complete tests).
The test code might also be interesting if you want to look for examples
\begin_inset LatexCommand \index{Examples}
if you don't want to run the complete tests).
The test code might also be interesting if you want to look for examples
\begin_inset LatexCommand \index{Examples}
checking corner cases of SDCC or if you plan to submit patches
\begin_inset LatexCommand \index{Patch submission}
checking corner cases of SDCC or if you plan to submit patches
\begin_inset LatexCommand \index{Patch submission}
The 14bit pic port uses a different set of regression tests
\begin_inset LatexCommand \index{Regression test (PIC14)}
The 14bit pic port uses a different set of regression tests
\begin_inset LatexCommand \index{Regression test (PIC14)}
fit for use in education".
This connotation is not intended but nevertheless risked as the licensing
of SDCC makes it difficult to offer educational discounts
fit for use in education".
This connotation is not intended but nevertheless risked as the licensing
of SDCC makes it difficult to offer educational discounts
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 (
\begin_inset LatexCommand \url[http://www.opencores.org]{opencores.org}
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 (
\begin_inset LatexCommand \url[http://www.opencores.org]{opencores.org}
), over assembly programming, to C to FPGA compilers (
\begin_inset LatexCommand \url[FPGAC]{http://sf.net/projects/fpgac}
), over assembly programming, to C to FPGA compilers (
\begin_inset LatexCommand \url[FPGAC]{http://sf.net/projects/fpgac}
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
\begin_inset LatexCommand \url[SourceForge]{http://www.sf.net}
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
\begin_inset LatexCommand \url[SourceForge]{http://www.sf.net}
, understanding BSD/LGPL/GPL/Proprietary licensing, growth models of Open
Source Software, CPU simulation, compiler regression tests
\begin_inset LatexCommand \index{Regression test}
, understanding BSD/LGPL/GPL/Proprietary licensing, growth models of Open
Source Software, CPU simulation, compiler regression tests
\begin_inset LatexCommand \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
\begin_inset LatexCommand \htmlurl{http://sourceforge.net/tracker/?group_id=599&atid=350599}
And if there should be a shortage of ideas then you can always point students
to the ever-growing feature request list
\begin_inset LatexCommand \htmlurl{http://sourceforge.net/tracker/?group_id=599&atid=350599}
choice (among them Alpha, i386, i386_64, MacOs, Mips, Sparc, Windows and
eventually
\begin_inset LatexCommand \url[OLPC]{http://www.laptop.org}
choice (among them Alpha, i386, i386_64, MacOs, Mips, Sparc, Windows and
eventually
\begin_inset LatexCommand \url[OLPC]{http://www.laptop.org}
then SDCC is probably among the first choices.
Well, probably SDCC might be the only choice.
then SDCC is probably among the first choices.
Well, probably SDCC might be the only choice.
In this case the address arithmetic a->b[i] will be computed only once;
the equivalent code in C would be.
In this case the address arithmetic a->b[i] will be computed only once;
the equivalent code in C would be.
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
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
Because of this preference of the register allocator
\begin_inset LatexCommand \index{Register allocation}
Because of this preference of the register allocator
\begin_inset LatexCommand \index{Register allocation}
, loop induction optimization causes an increase in register pressure, which
may cause unwanted spilling of other temporary variables into the stack
\begin_inset LatexCommand \index{stack}
, loop induction optimization causes an increase in register pressure, which
may cause unwanted spilling of other temporary variables into the stack
\begin_inset LatexCommand \index{stack}
If this extra space allocation is undesirable then induction optimization
can be eliminated either for the entire source file (with -
\begin_inset ERT
If this extra space allocation is undesirable then induction optimization
can be eliminated either for the entire source file (with -
\begin_inset ERT
As mentioned previously some loop invariants are not as apparent, all static
address computations are also moved out of the loop.
As mentioned previously some loop invariants are not as apparent, all static
address computations are also moved out of the loop.
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
\begin_inset Quotes eld
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
\begin_inset Quotes eld
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).
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).
given above are generally introduced by macro expansions or as a result
of copy/constant propagation.
given above are generally introduced by macro expansions or as a result
of copy/constant propagation.
.
It makes the decision based on an estimate of the generated code size.
SDCC is quite liberal in the requirements for jump table generation:
.
It makes the decision based on an estimate of the generated code size.
SDCC is quite liberal in the requirements for jump table generation:
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.
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.
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.
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.
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.
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.
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,
...
.
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,
...
.
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.:
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.:
then both the switch statements will be implemented using jump-tables whereas
the unmodified switch statement will not be.
then both the switch statements will be implemented using jump-tables whereas
the unmodified switch statement will not be.
There might be reasons which SDCC cannot know about to either favour or
not favour jump tables.
If the target system has to be as quick for the last switch case as for
the first (pro jump table), or if the switch argument is known to be zero
in the majority of the cases (contra jump table).
There might be reasons which SDCC cannot know about to either favour or
not favour jump tables.
If the target system has to be as quick for the last switch case as for
the first (pro jump table), or if the switch argument is known to be zero
in the majority of the cases (contra jump table).
aries.
It has no effect if a default label is supplied.
Use of this pragma is dangerous: if the switch
\begin_inset LatexCommand \index{switch statement}
aries.
It has no effect if a default label is supplied.
Use of this pragma is dangerous: if the switch
\begin_inset LatexCommand \index{switch statement}
Bit shifting is one of the most frequently used operation in embedded programmin
g.
SDCC tries to implement bit-shift operations in the most efficient way
possible, e.g.:
Bit shifting is one of the most frequently used operation in embedded programmin
g.
SDCC tries to implement bit-shift operations in the most efficient way
possible, e.g.:
A special case of the bit-shift operation is bit rotation
\begin_inset LatexCommand \index{rotating bits}
A special case of the bit-shift operation is bit rotation
\begin_inset LatexCommand \index{rotating bits}
SDCC uses pattern matching on the parse tree to determine this operation.Variatio
ns of this case will also be recognized as bit-rotation, i.e.:
SDCC uses pattern matching on the parse tree to determine this operation.Variatio
ns of this case will also be recognized as bit-rotation, i.e.:
Other special cases of the bit-shift operations are nibble or byte swapping
\begin_inset LatexCommand \index{swapping nibbles/bytes}
Other special cases of the bit-shift operations are nibble or byte swapping
\begin_inset LatexCommand \index{swapping nibbles/bytes}
and generates a swap instruction for the nibble swapping
\begin_inset LatexCommand \index{Nibble swapping}
and generates a swap instruction for the nibble swapping
\begin_inset LatexCommand \index{Nibble swapping}
example can be used to convert from little to big-endian or vice versa.
If you want to change the endianness of a
example can be used to convert from little to big-endian or vice versa.
If you want to change the endianness of a
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
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
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.:
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.:
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.:
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.:
It is also frequently required to obtain a higher order byte or word of
a larger integral type (long, int or short types).
SDCC recognizes the following expressions to yield the higher order byte
or word and generates optimized code for it, e.g.:
It is also frequently required to obtain a higher order byte or word of
a larger integral type (long, int or short types).
SDCC recognizes the following expressions to yield the higher order byte
or word and generates optimized code for it, e.g.:
-\newline
-0040 85*05*09\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
- 97\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
- mov\SpecialChar ~
-\SpecialChar ~
- (_foo_how1_1_1 + 1),(_glong + 3)
-\newline
-0043 85*03*0A\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
- 98\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
- mov\SpecialChar ~
-\SpecialChar ~
+\newline
+0040 85*05*09\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+ 97\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+ mov\InsetSpace ~
+\InsetSpace ~
+ (_foo_how1_1_1 +
+ 1),(_glong + 3)
+\newline
+0043 85*03*0A\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+ 98\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+\InsetSpace ~
+ mov\InsetSpace ~
+\InsetSpace ~
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.:
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.:
The compiler uses a rule based, pattern matching and re-writing mechanism
for peep-hole optimization.
It is inspired by
The compiler uses a rule based, pattern matching and re-writing mechanism
for peep-hole optimization.
It is inspired by
The above rule will change the following assembly
\begin_inset LatexCommand \index{Assembler routines}
The above rule will change the following assembly
\begin_inset LatexCommand \index{Assembler routines}
(pattern variable) must denote the same string.
With the above rule, the assembly sequence:
(pattern variable) must denote the same string.
With the above rule, the assembly sequence:
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-structur
e is MCU independent.
Peephole optimization rules for other MCU can be easily programmed using
the rule language.
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-structur
e is MCU independent.
Peephole optimization rules for other MCU can be easily programmed using
the rule language.
<assembly sequence> := assembly instruction (each instruction including
labels must be on a separate line).
<assembly sequence> := assembly instruction (each instruction including
labels must be on a separate line).
-\newline
-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.
+\newline
+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:
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:
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.:
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.:
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:
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:
A conditional function can be attached to a rule.
Attaching rules are somewhat more involved, let me illustrate this with
an example.
A conditional function can be attached to a rule.
Attaching rules are somewhat more involved, let me illustrate this with
an example.
.
If it finds a corresponding entry the function is called.
Note there can be no parameters specified for these functions, in this
case the use of
.
If it finds a corresponding entry the function is called.
Note there can be no parameters specified for these functions, in this
case the use of
expects to find the label in that particular variable (the hash table containin
g 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
expects to find the label in that particular variable (the hash table containin
g 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
labelInRange, labelRefCount, labelIsReturnOnly, operandsNotSame, xramMovcOption,
24bitMode, portIsDS390, 24bitModeAndPortDS390
labelInRange, labelRefCount, labelIsReturnOnly, operandsNotSame, xramMovcOption,
24bitMode, portIsDS390, 24bitModeAndPortDS390
I know this whole thing is a little kludgey, but maybe some day we will
have some better means.
If you are looking at this file, you will 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 -
\begin_inset ERT
I know this whole thing is a little kludgey, but maybe some day we will
have some better means.
If you are looking at this file, you will 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 -
\begin_inset ERT
cannot be assigned values directly, cannot be passed as function parameters
or assigned to each other and cannot be a return value
\begin_inset LatexCommand \index{return value}
cannot be assigned values directly, cannot be passed as function parameters
or assigned to each other and cannot be a return value
\begin_inset LatexCommand \index{return value}
command line options are used.
These may include (depending on the selected processor): 'at', 'banked',
'bit', 'code', 'critical', 'data', 'eeprom', 'far', 'flash', 'idata', 'interrup
command line options are used.
These may include (depending on the selected processor): 'at', 'banked',
'bit', 'code', 'critical', 'data', 'eeprom', 'far', 'flash', 'idata', 'interrup
that begin with two underscores
\begin_inset LatexCommand \index{\_\_ (prefix for extended keywords)}
that begin with two underscores
\begin_inset LatexCommand \index{\_\_ (prefix for extended keywords)}
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
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
-\newline
-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.
+\newline
+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.
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.
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 seven phases of the
compiler and its MCU dependency.
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 seven phases of the
compiler and its MCU dependency.
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.
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.
The second phase involves generating an intermediate code which can be easy
manipulated during the later phases.
This phase is entirely MCU independent.
The second phase involves generating an intermediate code which can be easy
manipulated during the later phases.
This phase is entirely MCU independent.
This phase does the bulk of the standard optimizations and is also MCU independe
nt.
This phase can be broken down into several sub-phases:
This phase does the bulk of the standard optimizations and is also MCU independe
nt.
This phase can be broken down into several sub-phases:
-\newline
-
-\newline
-Break down intermediate code (iCode) into basic blocks.
-\newline
-Do control flow & data flow analysis on the basic blocks.
-\newline
-Do local common subexpression elimination, then global subexpression elimination
-\newline
+\newline
+
+\newline
+Break down intermediate
+ code (iCode) into basic blocks.
+\newline
+Do control flow & data flow analysis on the
+ basic blocks.
+\newline
+Do local common subexpression elimination, then global subexpressio
+n elimination
+\newline
-\newline
-If loop optimizations caused any changes then do 'global subexpression eliminati
-on' and 'dead code elimination' again.
-\layout Itemize
+\newline
+If loop optimizations
+ caused any changes then do 'global subexpression elimination' and 'dead
+ code elimination' again.
+\end_layout
This phase determines the live-ranges; by live range I mean those iTemp
variables defined by the compiler that still survive after all the optimization
s.
Live range analysis
\begin_inset LatexCommand \index{Live range analysis}
This phase determines the live-ranges; by live range I mean those iTemp
variables defined by the compiler that still survive after all the optimization
s.
Live range analysis
\begin_inset LatexCommand \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.
is essential for register allocation, since these computation determines
which of these iTemps will be assigned to registers, and for how long.
-\newline
-The second part is more MCU independent and deals with allocating registers
- to the remaining live ranges.
+\newline
+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.
A lot of MCU specific code does creep into this phase because of the limited
number of index registers available in the 8051.
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.
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.
As mentioned in the optimization section the peep-hole optimizer is rule
based system, which can reprogrammed for other MCUs.
As mentioned in the optimization section the peep-hole optimizer is rule
based system, which can reprogrammed for other MCUs.
.
It's a little outdated (the compiler is much more efficient now and user/develo
per friendly), but pretty well exposes the guts of it all.
.
It's a little outdated (the compiler is much more efficient now and user/develo
per 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.
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.
Parsing the input source file and creating an AST (Annotated Syntax Tree
\begin_inset LatexCommand \index{Annotated syntax tree}
Parsing the input source file and creating an AST (Annotated Syntax Tree
\begin_inset LatexCommand \index{Annotated syntax tree}
xdata will be treated as a storage class specifier when parsing 8051 C
code but will be treated as a C identifier when parsing z80 or ATMEL AVR
C code.
xdata will be treated as a storage class specifier when parsing 8051 C
code but will be treated as a C identifier when parsing z80 or ATMEL AVR
C code.
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.
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.
Bulk of the target independent optimizations is performed in this phase.
The optimizations include constant propagation, common sub-expression eliminati
on, loop invariant code movement, strength reduction of loop induction variables
and dead-code elimination.
Bulk of the target independent optimizations is performed in this phase.
The optimizations include constant propagation, common sub-expression eliminati
on, loop invariant code movement, strength reduction of loop induction variables
and dead-code elimination.
During intermediate code generation phase, the compiler assumes the target
machine has infinite number of registers and generates a lot of temporary
variables.
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 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.
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.
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.
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.
operand and use the registers in this block, the operand will then be popped
at the end of the basic block.
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.
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.
operations supported by the compiler.
The code generation involves translating these operations into corresponding
operations supported by the compiler.
The code generation involves translating these operations into corresponding
<lyxtabular version="3" rows="39" columns="4">
<features islongtable="true" headBottomDL="true">
<column alignment="block" valignment="top" leftline="true" width="13col%">
<lyxtabular version="3" rows="39" columns="4">
<features islongtable="true" headBottomDL="true">
<column alignment="block" valignment="top" leftline="true" width="13col%">
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
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
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
</cell>
</row>
<row topline="true" bottomline="true">
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text
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.
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.
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:
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:
Filename(linenumber: iCode Execution sequence number : ICode hash table
key : loop depth of the iCode).
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.
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.
are computed only for temporaries (i.e.
live ranges are not computed for global variables).
Registers
\begin_inset LatexCommand \index{Register allocation}
are computed only for temporaries (i.e.
live ranges are not computed for global variables).
Registers
\begin_inset LatexCommand \index{Register allocation}
As mentioned earlier the live ranges are computed in terms of the execution
sequence number of the iCodes, for example
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 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.
-\newline
-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.
+\newline
+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.
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.
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.
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.
performed by the compiler.
It can detect induction variables iTemp21(i) and iTemp23(j).
Also note the compiler does selective strength reduction
\begin_inset LatexCommand \index{Strength reduction}
performed by the compiler.
It can detect induction variables iTemp21(i) and iTemp23(j).
Also note the compiler does selective strength reduction
\begin_inset LatexCommand \index{Strength reduction}
Sample.c(16:27:31:1) iTemp2 [lr18:40]{short}[r2] = iTemp2 [lr18:40]{short}[r2]
+ ITemp21 [lr21:38]{short}[r4]
Sample.c(16:27:31:1) iTemp2 [lr18:40]{short}[r2] = iTemp2 [lr18:40]{short}[r2]
+ ITemp21 [lr21:38]{short}[r4]
Sample.c(17:30:34:1) iTemp11 [lr19:40]{short}[r3] = iTemp11 [lr19:40]{short}[r3]
+ iTemp15 [lr29:30]{short}[r1]
Sample.c(17:30:34:1) iTemp11 [lr19:40]{short}[r3] = iTemp11 [lr19:40]{short}[r3]
+ iTemp15 [lr29:30]{short}[r1]
Sample.c(20:40:49:0) iTemp24 [lr40:41]{short}[DPTR] = iTemp2 [lr18:40]{short}[r2]
+ ITemp11 [lr19:40]{short}[r3]
Sample.c(20:40:49:0) iTemp24 [lr40:41]{short}[DPTR] = iTemp2 [lr18:40]{short}[r2]
+ ITemp11 [lr19:40]{short}[r3]
-\newline
-Predecessors are basic blocks that might execute before reaching this basic
- block.
-\newline
-Dominators are basic blocks that WILL execute before reaching this basic
- block.
-\newline
+\newline
+Predecessors are basic blocks
+ that might execute before reaching this basic block.
+\newline
+Dominators are basic
+ blocks that WILL execute before reaching this basic block.
+\newline
a) succList of [BB2] = [BB4], of [BB3] = [BB4], of [BB1] = [BB2,BB3]
a) succList of [BB2] = [BB4], of [BB3] = [BB4], of [BB1] = [BB2,BB3]
b) predList of [BB2] = [BB1], of [BB3] = [BB1], of [BB4] = [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.
c) domVect of [BB4] = BB1 ...
here we are not sure if BB2 or BB3 was executed but we are SURE that BB1
was executed.
Thanks to all the other volunteer developers who have helped with coding,
testing, web-page creation, distribution sets, etc.
You know who you are :-)
Thanks to all the other volunteer developers who have helped with coding,
testing, web-page creation, distribution sets, etc.
You know who you are :-)
which has hosted the project since 1999 and donates significant download
bandwidth and probably more than
\begin_inset ERT
which has hosted the project since 1999 and donates significant download
bandwidth and probably more than
\begin_inset ERT
more than 10^13 is an estimate: on my Athlon 2800+ it takes about (0.5+6.5+20)
minutes for (configure+make+regression test), and there is (i386, amd64,
alpha, ppc64, (mingw32), sparc, macosx).
more than 10^13 is an estimate: on my Athlon 2800+ it takes about (0.5+6.5+20)
minutes for (configure+make+regression test), and there is (i386, amd64,
alpha, ppc64, (mingw32), sparc, macosx).
To avoid confusion, the installation and building options for SDCC itself
(chapter 2) are not part of the index.
To avoid confusion, the installation and building options for SDCC itself
(chapter 2) are not part of the index.