-lSDCC Compiler User Guide
+SDCC Compiler User Guide
Table of Contents
1.1 About SDCC
1.2 Open Source
1.3 Typographic conventions
- 1.4 Pending: compatibilaty with previous versions
+ 1.4 Compatibility with previous versions
1.5 System Requirements
1.6 Other Resources
+ 1.7 Wishes for the future
2 Installation
2.1 Linux/Unix Installation
2.2 Windows Installation
4.1.10 Highest Order Bit
4.1.11 Peep-hole Optimizer
4.2 Pragmas
- 4.3 Library Routines
+ 4.3 <pending: this is messy and incomplete> Library Routines
4.4 Interfacing with Assembly Routines
- 4.5 Global Registers used for Parameter Passing
- 4.5.1 Assembler Routine(non-reentrant)
- 4.5.2 Assembler Routine(reentrant)
- 4.6 External Stack
- 4.7 ANSI-Compliance
- 4.8 Cyclomatic Complexity
+ 4.4.1 Global Registers used for Parameter Passing
+ 4.4.2 Assembler Routine(non-reentrant)
+ 4.4.3 Assembler Routine(reentrant)
+ 4.5 External Stack
+ 4.6 ANSI-Compliance
+ 4.7 Cyclomatic Complexity
5 TIPS
+ 5.1 Notes on MCS51 memory layout
6 Retargetting for other MCUs.
7 SDCDB - Source Level Debugger
7.1 Compiling for Debugging
8.1 The Z80 and gbz80 port
9 Support
9.1 Reporting Bugs
- 9.2 Acknowledgments
+10 Acknowledgments
1.1 About SDCC
-<pending: tabularise these features, this is unreadeble>
-
-SDCC is a Free ware, retargettable, optimizing ANSI-C compiler
+SDCC is a Freeware, retargettable, optimizing ANSI-C compiler
by Sandeep Dutta designed for 8 bit Microprocessors. The
current version targets Intel MCS51 based Microprocessors(8051,8052,
-etc), Zilog Z80 based MCUs, and the Dallas 80C390 MCS51
-variant. It can be retargetted for other microprocessors,
-support for PIC, AVR and 186 is under development. The entire
-source code for the compiler is distributed under GPL. SDCC
-uses ASXXXX & ASLINK, a Freeware, retargettable assembler
-& linker. SDCC has extensive language extensions suitable
-for utilizing various microcontrollers underlying hardware
-effectively. In addition to the MCU specific optimizations
-SDCC also does a host of standard optimizations like global
-sub expression elimination, loop optimizations (loop invariant,
-strength reduction of induction variables and loop reversing),
-constant folding & propagation, copy propagation, dead code
-elimination and jumptables for 'switch' statements. For
-the back-end SDCC uses a global register allocation scheme
-which should be well suited for other 8 bit MCUs. The peep
-hole optimizer uses a rule based substitution mechanism
-which is MCU dependent. Supported data-types are char (8
-bits, 1 byte), short and int (16 bits, 2 bytes), long (32
-bit, 4 bytes) and float (4 byte IEEE). The compiler also
-allows inline assembler code to be embedded anywhere in
-a function. In addition routines developed in assembly can
-also be called. SDCC also provides an option to report the
-relative complexity of a function, these functions can then
+etc), Zilog Z80 based MCUs, and the Dallas DS80C390 variant.
+It can be retargetted for other microprocessors, support
+for PIC, AVR and 186 is under development. The entire source
+code for the compiler is distributed under GPL. SDCC uses
+ASXXXX & ASLINK, a Freeware, retargettable assembler & linker.
+SDCC has extensive language extensions suitable for utilizing
+various microcontrollers and underlying hardware effectively.
+
+
+In addition to the MCU specific optimizations SDCC also does
+a host of standard optimizations like:
+
+* global sub expression elimination,
+
+* loop optimizations (loop invariant, strength reduction
+ of induction variables and loop reversing),
+
+* constant folding & propagation,
+
+* copy propagation,
+
+* dead code elimination
+
+* jumptables for switch statements.
+
+For the back-end SDCC uses a global register allocation scheme
+which should be well suited for other 8 bit MCUs.
+
+The peep hole optimizer uses a rule based substitution mechanism
+which is MCU independent.
+
+Supported data-types are:
+
+* char (8 bits, 1 byte),
+
+* short and int (16 bits, 2 bytes),
+
+* long (32 bit, 4 bytes)
+
+* float (4 byte IEEE).
+
+The compiler also allows inline assembler code to be embedded
+anywhere in a function. In addition, routines developed
+in assembly can also be called.
+
+SDCC also provides an option (--cyclomatic) to report the
+relative complexity of a function. These functions can then
be further optimized, or hand coded in assembly if needed.
+
+
SDCC also comes with a companion source level debugger SDCDB,
the debugger currently uses ucSim a freeware simulator for
-8051 and other micro-controllers. The latest version can
-be downloaded from [http://sdcc.sourceforge.net/] .
+8051 and other micro-controllers.
+
+The latest version can be downloaded from [http://sdcc.sourceforge.net/].
1.2 Open Source
use, share and improve what you give them. Help stamp out
software-hoarding!
-<pending: add a link to gnu>
-
1.3 Typographic conventions
Throughout this manual, we will use the following convention.
Code samples are printed in typewriter font. Interesting
items and new terms are printed in italicised type.
-1.4 Pending: compatibilaty with previous versions
+1.4 Compatibility with previous versions
-This version has numerous bug fixes comperated with the previous
-version. But we also introduced some incompatibilaties with
+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.
+the compiler more stable, efficient and ANSI compliant.
+
+* short is now equivalent to int (16 bits), it used to be
+ equivalent to char (8 bits)
-short char
-directory structure (2.7)
-vararg pars expl int unless casted
-never had a regextend
-no --noreparms anymore
+* the default directory where include, library and documention
+ files are stored is no in /usr/local/share
-more?
+* char type parameters to vararg functions are casted to
+ int unless explicitly casted, e.g.:
+ char a=3;
+ printf ("%d %c\n", a, (char)a);
+ will push a as an int and as a char resp.
+
+* option --regextend has been removed
+
+* option --noreparms has been removed
+
+<pending: more incompatibilities?>
1.5 System Requirements
What do you need before you start installation of SDCC? A
computer, and a desire to compute. The preferred method
of installation is to compile SDCC from source using GNU
-GCC and make. For Windows some pre-compiled binary distributions
+gcc and make. For Windows some pre-compiled binary distributions
are available for your convenience. You should have some
experience with command line tools and compiler use.
the latest unreleased software, the complete source package
is available directly by anonymous CVS on cvs.sdcc.sourceforge.net.
+1.7 Wishes for the future
+
+There are (and always will be) some things that could be
+done. Here are some I can think of:
+
+
+sdcc -c --model-large -o large _atoi.c (where large could
+be a different basename or a directory)
+
+
+char KernelFunction3(char p) at 0x340;
+
+If you can think of some more, please send them to the list.
+
+<pending: And then of course a proper index-table>
+
2 Installation
2.1 Linux/Unix Installation
6. Type "make". All of the source packages will compile, this
can take a while.
-7. Type "make install" as root. This copies the binary executables
+7. Type "make install" as root. This copies the binary executables,
+ the include files, the libraries and the documentation
to the install directories.
2.2 Windows Installation
SDCC binaries are commonly installed in a directory arrangement
like this:
-
+--------------------------------+-------------------------------------------+
| /usr/local/bin | Holds executables(sdcc, s51, aslink, ...) |
+--------------------------------+-------------------------------------------+
Make sure the compiler works on a very simple example. Type
in the following test.c program using your favorite editor:
-Compile this using the following command: "sdcc -c test.c"
+int test(int t) {
+ return t+3;
+}
+
+Compile this using the following command: "sdcc -c test.c".
If all goes well, the compiler will generate a test.asm
and test.rel file. Congratulations, you've just compiled
your first program with SDCC. We used the -c option to tell
The command "./configure --prefix=/usr/local"
will configure the compiler to be installed in directory
-/usr/local/bin.
+/usr/local.
2.8 Components of SDCC
for other processors, other packages from various developers
are included and may have their own sets of documentation.
-You might want to look at the various executables which are
-installed in the bin directory. At the time of this writing,
-we find the following programs:
+You might want to look at the files which are installed in
+<installdir>. At the time of this writing, we find the following
+programs:
+
+In <installdir>/bin:
+
+* sdcc - The compiler.
+
+* sdcpp - The C preprocessor.
+
+* asx8051 - The assembler for 8051 type processors.
+
+* as-z80, as-gbz80 - The Z80 and GameBoy Z80 assemblers.
+
+* aslink -The linker for 8051 type processors.
+
+* link-z80, link-gbz80 - The Z80 and GameBoy Z80 linkers.
+
+* s51 - The ucSim 8051 simulator.
-<pending: tabularize this>
+* sdcdb - The source debugger.
-sdcc - The compiler.
-sdcpp - The C preprocessor.
-asx8051 - The assembler for 8051 type processors.
-as-z80, as-gbz80 - The Z80 and GameBoy Z80 assemblers.
-aslink -The linker for 8051 type processors.
-link-z80, link-gbz80 - The Z80 and GameBoy Z80 linkers.
-s51 - The ucSim 8051 simulator.
-sdcdb - The source debugger.
-packihx - A tool to pack Intel hex files.
+* packihx - A tool to pack Intel hex files.
+
+In <installdir>/share/sdcc/include
+
+* the include files
+
+In <installdir>/share/sdcc/lib
+
+* the sources of the runtime library and the subdirs small
+ large and ds390 with the precompiled relocatables.
+
+In <installdir>/share/sdcc/doc
+
+* the documentation
As development for other processors proceeds, this list will
expand to include executables to support processors like
* The case labels are in numerical sequence, the labels need
not be in order, and the starting number need not be one
or zero.
-
-switch(i) {
+
+ switch(i) {
- switch (i) {
-case 4:...
+ switch (i) {
+ case 4:...
- case 1: ...
-case 5:...
+ case 1: ...
+ case 5:...
- case 2: ...
-case 3:...
+ case 2: ...
+ case 3:...
- case 3: ...
-case 6:...
+ case 3: ...
+ case 6:...
- case 4: ...
-}
+ case 4: ...
+ }
- }
-
-Both the above switch statements will be implemented using
-a jump-table.
+ }
+
+ Both the above switch statements will be implemented using
+ a jump-table.
* The number of case labels is at least three, since it takes
two conditional statements to handle the boundary conditions.
would result in:
-pop ar1
-; nop
-push ar1
+ pop ar1
+ ; nop
+ push ar1
with the restart option the rule will be applied again to
the resulting code and then all the pop-push pairs will
be eliminated to yield:
-; nop
-; nop
+ ; nop
+ ; nop
A conditional function can be attached to a rule. Attaching
rules are somewhat more involved, let me illustrate this
replace {
ljmp %5
-%2:} by {
+%2:
+} by {
sjmp %5
-%2:} if labelInRange
+%2:
+} if labelInRange
The optimizer does a look-up of a function name table defined
in function callFuncByName in the source file SDCCpeeph.c,
own rules in the default set there if you get tired of specifying
the --peep-file option.
-<pending: this is as far as I got>
-
4.2 Pragmas
SDCC supports the following #pragma directives. This directives
function, placing pragma's inside a function body could
have unpredictable results.
-eg
-
-#pragma SAVE /* save the current settings
-*/
+#pragma SAVE /* save the current settings */
#pragma NOGCSE /* turnoff global subexpression elimination
*/
#pragma NOINDUCTION /* turn off induction optimizations */
is allocated. It is strongly recommended that the SAVE and
RESTORE pragma's be used when changing options for a function.
-4.3 Library Routines
+4.3 <pending: this is messy and incomplete> Library Routines
The following library routines are provided for your convenience.
4.4 Interfacing with Assembly Routines
-4.5 Global Registers used for Parameter Passing
+4.4.1 Global Registers used for Parameter Passing
-By default the compiler uses the global registers "DPL,DPH,B,ACC"
-to pass the first parameter to a routine, the second parameter
-onwards is either allocated on the stack (for reentrant
-routines or --stack-auto is used) or in the internal / external
-ram (depending on the memory model).
+The compiler always uses the global registers DPL,DPH,B and
+ACC to pass the first parameter to a routine. The second
+parameter onwards is either allocated on the stack (for
+reentrant routines or if --stack-auto is used) or in the
+internal / external ram (depending on the memory model).
-4.5.1 Assembler Routine(non-reentrant)
+4.4.2 Assembler Routine(non-reentrant)
In the following example the function cfunc calls an assembler
routine asm_func, which takes two parameters.
extern int asm_func(unsigned char, unsigned char);
-
-int c_func (unsigned char i, unsigned char j)
-{
- return asm_func(i,j);
-}
-int main()
-{
- return c_func(10,9);
+int c_func (unsigned char i, unsigned char j)
+{
+ return asm_func(i,j);
+}
+
+int main()
+{
+ return c_func(10,9);
}
-The corresponding assembler function is:-
+The corresponding assembler function is:
- .globl _asm_func_PARM_2
+.globl _asm_func_PARM_2
.globl _asm_func
.area OSEG
-_asm_func_PARM_2:
-.ds 1
+_asm_func_PARM_2:
+ .ds 1
.area CSEG
_asm_func:
- mov
-a,dpl
- add
-a,_asm_func_PARM_2
- mov
-dpl,a
- mov
-dpl,#0x00
+ mov a,dpl
+ add a,_asm_func_PARM_2
+
+ mov dpl,a
+ mov dpl,#0x00
ret
Note here that the return values are placed in 'dpl' - One
for One bye parameter, "dptr"
if two bytes, "b,dptr"
for three bytes and "acc,b,dptr"
-for four bytes, the varaible name for the second parameter
+for four bytes, the varible name for the second parameter
will be _<function_name>_PARM_2.
-Assemble the assembler routine with the following command.
+Assemble the assembler routine with the following command:
asx8051 -losg asmfunc.asm
Then compile and link the assembler routine to the C source
-file with the following command,
+file with the following command:
sdcc cfunc.c asmfunc.rel
-4.5.2 Assembler Routine(reentrant)
+4.4.3 Assembler Routine(reentrant)
In this case the second parameter onwards will be passed
on the stack, the parameters are pushed from right to left
i.e. after the call the left most parameter will be on the
-top of the stack. Here is an example.
+top of the stack. Here is an example:
extern int asm_func(unsigned char, unsigned char);
-
-
int c_func (unsigned char i, unsigned char j) reentrant
{
- return asm_func(i,j);
+ return asm_func(i,j);
}
+
int main()
{
- return c_func(10,9);
+ return c_func(10,9);
}
-The corresponding assembler routine is.
+The corresponding assembler routine is:
- .globl _asm_func
+.globl _asm_func
_asm_func:
- push _bp
- mov _bp,sp
- mov r2,dpl
- mov a,_bp
- clr c
- add a,#0xfd
- mov r0,a
- add a,#0xfc
- mov r1,a
- mov a,@r0
- add a,r2
- mov dpl,a
- mov dph,#0x00
- mov sp,_bp
- pop _bp
- ret
+ push _bp
+ mov _bp,sp
+ mov r2,dpl
+ mov a,_bp
+ clr c
+ add a,#0xfd
+ mov r0,a
+ add a,#0xfc
+ mov r1,a
+ mov a,@r0
+ add a,r2
+ mov dpl,a
+ mov dph,#0x00
+ mov sp,_bp
+ pop _bp
+ ret
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.
-4.6 External Stack
+4.5 External Stack
The external stack is located at the start of the external
ram segment, and is 256 bytes in size. When --xstack option
the External Stack option, this port MAY NOT be used by
the application program.
-4.7 ANSI-Compliance
+4.6 ANSI-Compliance
Deviations from the compliancy.
-1. functions are not always reentrant.
+* functions are not always reentrant.
-2. structures cannot be assigned values directly, cannot be
+* structures cannot be assigned values directly, cannot be
passed as function parameters or assigned to each other
- and cannot be a return value from a function.
-
- eg
-
-struct s { ... };
-struct s s1, s2;
-foo()
-{
-...
-s1 = s2 ; /* is invalid in SDCC although allowed in ANSI
-*/
-...
-}
-
-struct s foo1 (struct s parms) /* is invalid in SDCC although
-allowed in ANSI */
-{
-struct s rets;
-...
-return rets;/* is invalid in SDCC although allowed in ANSI
-*/
-}
-
-1. 'long long' (64 bit integers) not supported.
-
-2. 'double' precision floating point not supported.
+ and cannot be a return value from a function, e.g.:
+
+ struct s { ... };
+ struct s s1, s2;
+ foo()
+ {
+ ...
+ s1 = s2 ; /* is invalid in SDCC although
+ allowed in ANSI */
+ ...
+ }
+ struct s foo1 (struct s parms) /* is invalid in SDCC although
+ allowed in ANSI */
+ {
+ struct s rets;
+ ...
+ return rets;/* is invalid in SDCC although
+ allowed in ANSI */
+ }
-3. integral promotions are suppressed. What does this mean
- ? The compiler will not implicitly promote an integer
- expression to a higher order integer, exception is an
- assignment or parameter passing.
+* 'long long' (64 bit integers) not supported.
-4. No support for setjmp and longjmp (for now).
+* 'double' precision floating point not supported.
-5. Old K&R style function declarations are NOT allowed.
+* No support for setjmp and longjmp (for now).
-foo(i,j) /* this old style of function declarations */
-int i,j; /* are valid in ANSI .. not valid in SDCC */
-{
-...
-}
+* Old K&R style function declarations are NOT allowed.
+
+ foo(i,j) /* this old style of function declarations */
+
+ int i,j; /* are valid in ANSI but not valid in SDCC */
+
+ {
+ ...
+ }
-1. functions declared as pointers must be dereferenced during
+* functions declared as pointers must be dereferenced during
the call.
-
+
int (*foo)();
+ ...
+ /* has to be called like this */
+ (*foo)(); /* ansi standard allows calls to be made like
+ 'foo()' */
- ...
- /* has to be called like this */
- (*foo)();/* ansi standard allows calls to be made like
-'foo()' */
-
-4.8 Cyclomatic Complexity
+4.7 Cyclomatic Complexity
Cyclomatic complexity of a function is defined as the number
of independent paths the program can take during execution
function. The accepted industry standard for complexity
number is 10, if the cyclomatic complexity reported by SDCC
exceeds 10 you should think about simplification of the
-function logic.
+function logic. Note that the complexity level is not related
+to the number of lines of code in a function. Large functions
+can have low complexity, and small functions can have large
+complexity levels.
+
+SDCC uses the following formula to compute the complexity:
-Note that the complexity level is not related to the number
-of lines of code in a function. Large functions can have
-low complexity, and small functions can have large complexity
-levels. SDCC uses the following formula to compute the complexity.
-complexity = (number of edges in control flow graph) -
- (number
+complexity = (number of edges in control flow graph) - (number
of nodes in control flow graph) + 2;
Having said that the industry standard is 10, you should
-be aware that in some cases it may unavoidable to have a
-complexity level of less than 10. For example if you have
+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
5 TIPS
-Here are a few guide-lines that will help the compiler generate
+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.
* Reducing the size of division, multiplication & modulus
operations can reduce code size substantially. Take the
following code for example.
-
+
foobar(unsigned int p1, unsigned char ch)
{
unsigned char ch1 = p1 % ch ;
....
}
-
+
For the modulus operation the variable ch will be promoted
to unsigned int first then the modulus operation will
- be performed (this will lead to a call to a support routine).
+ be performed (this will lead to a call to support routine
+ _muduint()), and the result will be casted to an int.
If the code is changed to
-
+
foobar(unsigned int p1, unsigned char ch)
{
- unsigned char ch1 = (unsigned char)p1
- % ch ;
+ unsigned char ch1 = (unsigned char)p1 % ch ;
....
}
-
+
It would substantially reduce the code generated (future
versions of the compiler will be smart enough to detect
such optimization oppurtunities).
-Notes on MCS51 memory layout(Trefor@magera.freeserve.co.uk)
+5.1 Notes on MCS51 memory layout
The 8051 family of micro controller have a minimum of 128
bytes of internal memory which is structured as follows
- Bytes 00-1F - 32 bytes to hold up to 4 banks of the registers
R7 to R7
-
- Bytes 20-2F - 16 bytes to hold 128 bit variables and
-
- Bytes 30-7F - 60 bytes for general purpose use.
Normally the SDCC compiler will only utilise the first bank
The amount of stack being used is affected by the use of
the "internal stack" to save registers before a subroutine
-call is made, - --stack-auto will declare parameters and
-local variables on the stack - the number of nested subroutines.
+call is made (--stack-auto will declare parameters and local
+variables on the stack) and the number of nested subroutines.
If you detect that the stack is over writing you data, then
the following can be done. --xstack will cause an external
stack to be used for saving registers and (if --stack-auto
is being used) storing parameters and local variables. However
-this will produce more and code which will be slower to
-execute.
+this will produce more code which will be slower to execute.
--stack-loc will allow you specify the start of the stack,
i.e. you could start it after any data in the general purpose
internal memory is to position the "near data" after the
last bank of used registers or, if you use bit variables,
after the last bit variable by using the --data-loc, e.g.
-if two register banks are being used and no data variables,
---data-loc 16, and - use the --stack-after-data option.
+if two register banks are being used and no bit variables,
+--data-loc 16, and use the --stack-after-data option.
If bit variables are being used, another method would be
to try and squeeze the data area in the unused register
description of each of the seven phases of the compiler
and its MCU dependency.
-1. Parsing the source and building the annotated parse tree.
+* 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.
-2. The second phase involves generating an intermediate code
+* The second phase involves generating an intermediate code
which can be easy manipulated during the later phases.
This phase is entirely MCU independent. The intermediate
code generation assumes the target machine has unlimited
iTemp. The compiler can be made to dump a human readable
form of the code generated by using the --dumpraw option.
-3. This phase does the bulk of the standard optimizations
+* This phase does the bulk of the standard optimizations
and is also MCU independent. This phase can be broken
- down into several sub-phases.
-
- * Break down intermediate code (iCode) into basic blocks.
-
- * Do control flow & data flow analysis on the basic blocks.
-
- * Do local common subexpression elimination, then global
- subexpression elimination
-
- * dead code elimination
-
- * loop optimizations
-
- * if loop optimizations caused any changes then do 'global
- subexpression elimination' and 'dead code elimination'
- again.
-
-4. This phase determines the live-ranges; by live range I
+ down into several sub-phases:
+
+ Break down intermediate code (iCode) into basic blocks.
+ Do control flow & data flow analysis on the basic blocks.
+ Do local common subexpression elimination, then global
+ subexpression elimination
+ Dead code elimination
+ Loop optimizations
+ If loop optimizations caused any changes then do 'global
+ subexpression elimination' and 'dead code elimination'
+ again.
+
+* This phase determines the live-ranges; by live range I
mean those iTemp variables defined by the compiler that
still survive after all the optimizations. Live range
analysis is essential for register allocation, since these
computation determines which of these iTemps will be assigned
to registers, and for how long.
-5. Phase five is register allocation. There are two parts
+* Phase five is register allocation. There are two parts
to this process.
+
+ The first part I call 'register packing' (for lack of a
+ better term). In this case several MCU specific expression
+ folding is done to reduce register pressure.
+
+ The second part is more MCU independent and deals with
+ allocating registers to the remaining live ranges. A lot
+ of MCU specific code does creep into this phase because
+ of the limited number of index registers available in
+ the 8051.
- (a) The first part I call 'register packing' (for lack of
- a better term). In this case several MCU specific expression
- folding is done to reduce register pressure.
-
- (b) 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.
-
-6. The Code generation phase is (unhappily), entirely MCU
+* 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.
-7. As mentioned in the optimization section the peep-hole
+* As mentioned in the optimization section the peep-hole
optimizer is rule based system, which can reprogrammed
for other MCUs.
7.1 Compiling for Debugging
-The --debug option must be specified for all files for which
-debug information is to be generated. The complier generates
-a .cdb file for each of these files. The linker updates
-the .cdb file with the address information. This .cdb is
-used by the debugger.
+The debug option must be specified for all files
+for which debug information is to be generated. The complier
+generates a .cdb file for each of these files. The linker
+updates the .cdb file with the address information. This
+.cdb is used by the debugger.
7.2 How the Debugger Works
7.3 Starting the Debugger
The debugger can be started using the following command line.
-(Assume the file you are debugging has
+(Assume the file you are debugging has the file name foo).
-the file name foo).
-
->sdcdb foo
+sdcdb foo
The debugger will look for the following files.
-1. foo.c - the source file.
+* foo.c - the source file.
-2. foo.cdb - the debugger symbol information file.
+* foo.cdb - the debugger symbol information file.
-3. foo.ihx - the intel hex format object file.
+* foo.ihx - the intel hex format object file.
7.4 Command Line Options.
please see the simulator docs for details.
* -X <Clock frequency > this options is passed to the simulator
- please see simulator docs for details.
+ please see the simulator docs for details.
-* -s <serial port file> passed to simulator see simulator
+* -s <serial port file> passed to simulator see the simulator
docs for details.
-* -S <serial in,out> passed to simulator see simulator docs
- for details.
+* -S <serial in,out> passed to simulator see the simulator
+ docs for details.
7.5 Debugger Commands.
As mention earlier the command interface for the debugger
has been deliberately kept as close the GNU debugger gdb,
-as possible, this will help int integration with existing
+as possible. This will help the integration with existing
graphical user interfaces (like ddd, xxgdb or xemacs) existing
for the GNU debugger.
7.5.1 break [line | file:line | function | file:function]
-Set breakpoint at specified line or function.
+Set breakpoint at specified line or function:
sdcdb>break 100
sdcdb>break foo.c:100
7.5.2 clear [line | file:line | function | file:function ]
-Clear breakpoint at specified line or function.
+Clear breakpoint at specified line or function:
sdcdb>clear 100
sdcdb>clear foo.c:100
7.6 Interfacing with XEmacs.
-Two files are (in emacs lisp) are provided for the interfacing
+Two files (in emacs lisp) are provided for the interfacing
with XEmacs, sdcdb.el and sdcdbsrc.el. These two files can
be found in the $(prefix)/bin directory after the installation
is complete. These files need to be loaded into XEmacs for
-the interface to work, this can be done at XEmacs startup
+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) (load-file sdcdbsrc.el)
-[ .xemacs is a lisp file so the () around the command is
-REQUIRED), the files can also be loaded dynamically while
-XEmacs is running, set the environment variable 'EMACSLOADPATH'
-to the installation bin directory [$(prefix)/bin], then
+(which can be found in your HOME directory):
+
+(load-file sdcdbsrc.el)
+
+.xemacs is a lisp file so the () around the command is REQUIRED.
+The files can also be loaded dynamically while XEmacs is
+running, set the environment variable 'EMACSLOADPATH' to
+the installation bin directory (<installdir>/bin), then
enter the following command ESC-x load-file sdcdbsrc. To
-start the interface enter the following command ESC-x sdcdbsrc,
-you will prompted to enter the file name to be debugged.
+start the interface enter the following command:
+
+ESC-x sdcdbsrc
+
+You will prompted to enter the file name to be debugged.
+
The command line options that are passed to the simulator
-directly are bound to default values in the file sdcdbsrc.el
-the variables are listed below these values maybe changed
+directly are bound to default values in the file sdcdbsrc.el.
+The variables are listed below, these values maybe changed
as required.
* sdcdbsrc-cpu-type '51
;; ?
sdcdb-whatis-c-sexp SDCDB
ptypecommand for data at
-;;
+;;
buffer point
;; x
sdcdbsrc-delete SDCDB
;; m
sdcdbsrc-frame SDCDB
Display current frame if no arg,
-;; given
+;; given
or display frame arg
-;; buffer
+;; buffer
point
;; !
sdcdbsrc-goto-sdcdb Goto
;; p
sdcdb-print-c-sexp SDCDB
print command for data at
-;;
+;;
buffer point
;; g
sdcdbsrc-goto-sdcdb Goto
SDCC can target both the Zilog Z80 and the Nintendo Gameboy's
Z80-like gbz80. The port is incomplete - long support is
incomplete (mul, div and mod are unimplimented), and both
-float and bitfield support is missing, but apart from that
-the code generated is correct.
+float and bitfield support is missing. Apart from that the
+code generated is correct.
As always, the code is the authoritave reference - see z80/ralloc.c
and z80/gen.c. The stack frame is similar to that generated
9 Support
-SDCC has grown to be large project, the compiler alone (without
-the Assembler Package, Preprocessor) is about 40,000 lines
-of code (blank stripped). The open source nature of this
-project is a key to its continued growth and support. You
-gain the benefit and support of many active software developers
-and end users. Is SDCC perfect? No, that's why we need your
-help. The developers take pride in fixing reported bugs.
-You can help by reporting the bugs and helping other SDCC
-users. There are lots of ways to contribute, and we encourage
-you to take part in making SDCC a great software package.
+SDCC has grown to be a large project. The compiler alone
+(without the preprocessor, assembler and linker) is about
+40,000 lines of code (blank stripped). The open source nature
+of this project is a key to its continued growth and support.
+You gain the benefit and support of many active software
+developers and end users. Is SDCC perfect? No, that's why
+we need your help. The developers take pride in fixing reported
+bugs. You can help by reporting the bugs and helping other
+SDCC users. There are lots of ways to contribute, and we
+encourage you to take part in making SDCC a great software
+package.
9.1 Reporting Bugs
the --dumpall option can sometimes be useful in locating
optimization problems.
-9.2 Acknowledgments
+10 Acknowledgments
-Sandeep Dutta(sandeep.dutta@usa.net) - SDCC, the compiler,
+Sandeep Dutta (sandeep.dutta@usa.net) - SDCC, the compiler,
MCS51 code generator, Debugger, AVR port
Alan Baldwin (baldwin@shop-pdp.kent.edu) - Initial version
of ASXXXX & ASLINK.
ASLINK for 8051
Dmitry S. Obukhov (dso@usa.net) - malloc & serial i/o routines.
-Daniel Drotos <drdani@mazsola.iit.uni-miskolc.hu> - for his
+Daniel Drotos (drdani@mazsola.iit.uni-miskolc.hu) - for his
Freeware simulator
Malini Dutta(malini_dutta@hotmail.com) - my wife for her
patience and support.
Unknown - for the GNU C - preprocessor.
Michael Hope - The Z80 and Z80GB port, 186 development
Kevin Vigor - The DS390 port.
-Johan Knol - DS390/TINI libs, lots of fixes and enhancements.
-Scott Datallo - PIC port.
-(Thanks to all the other volunteer developers who have helped
+Johan Knol - Lots of fixes and enhancements, DS390/TINI libs.
+Scott Datallo - The PIC port.
+
+Thanks to all the other volunteer developers who have helped
with coding, testing, web-page creation, distribution sets,
etc. You know who you are :-)
-This document initially written by Sandeep Dutta
+This document was initially written by Sandeep Dutta
All product names mentioned herein may be trademarks of their
respective companies.
projects / fw / sdcc / blobdiff