<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
<TITLE>SDCC Compiler User Guide: Introduction</TITLE>
<LINK HREF="SDCCUdoc-2.html" REL=next>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
<TITLE>SDCC Compiler User Guide: Absolute addressing.</TITLE>
<LINK HREF="SDCCUdoc-11.html" REL=next>
<LINK HREF="SDCCUdoc-9.html" REL=previous>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
<TITLE>SDCC Compiler User Guide: Interrupt Service Routines</TITLE>
<LINK HREF="SDCCUdoc-12.html" REL=next>
<LINK HREF="SDCCUdoc-10.html" REL=previous>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
<TITLE>SDCC Compiler User Guide: Startup Code</TITLE>
<LINK HREF="SDCCUdoc-13.html" REL=next>
<LINK HREF="SDCCUdoc-11.html" REL=previous>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
<TITLE>SDCC Compiler User Guide: Inline assembler code.</TITLE>
<LINK HREF="SDCCUdoc-14.html" REL=next>
<LINK HREF="SDCCUdoc-12.html" REL=previous>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
<TITLE>SDCC Compiler User Guide: int (16 bit) and long (32 bit ) support.</TITLE>
<LINK HREF="SDCCUdoc-15.html" REL=next>
<LINK HREF="SDCCUdoc-13.html" REL=previous>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
<TITLE>SDCC Compiler User Guide: Floating point support</TITLE>
<LINK HREF="SDCCUdoc-16.html" REL=next>
<LINK HREF="SDCCUdoc-14.html" REL=previous>
<P>Note if all these routines are used simultaneously the data space might
overflow. For serious floating point usage it is strongly recommended that
the Large model be used (in which case the floating point routines mentioned
-above will need to recompiled with the --model-Large option).
+above will need to recompiled with the --model-Large option)
<HR>
<A HREF="SDCCUdoc-16.html">Next</A>
<A HREF="SDCCUdoc-14.html">Previous</A>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
<TITLE>SDCC Compiler User Guide: Memory Models</TITLE>
<LINK HREF="SDCCUdoc-17.html" REL=next>
<LINK HREF="SDCCUdoc-15.html" REL=previous>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
- <TITLE>SDCC Compiler User Guide: Defines created by the compiler.</TITLE>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
+ <TITLE>SDCC Compiler User Guide: Flat 24 bit addressing model.</TITLE>
<LINK HREF="SDCCUdoc-18.html" REL=next>
<LINK HREF="SDCCUdoc-16.html" REL=previous>
<LINK HREF="SDCCUdoc.html#toc17" REL=contents>
<A HREF="SDCCUdoc-16.html">Previous</A>
<A HREF="SDCCUdoc.html#toc17">Contents</A>
<HR>
-<H2><A NAME="Defines."></A> <A NAME="s17">17. Defines created by the compiler.</A> </H2>
+<H2><A NAME="--model-flat24"></A> <A NAME="s17">17. Flat 24 bit addressing model.</A> </H2>
-<P>The compiler creates the following #defines .
-<P>
-<UL>
-<LI>SDCC - this Symbol is always defined.</LI>
-<LI>SDCC_STACK_AUTO - this symbol is defined when --stack-auto option is used.</LI>
-<LI>SDCC_MODEL_SMALL - when small model is used.</LI>
-<LI>SDCC_MODEL_LARGE - when --model-large is used.</LI>
-<LI>SDCC_USE_XSTACK - when --xstack option is used.</LI>
-</UL>
+<P>This option generates code for the 24 bit contiguous addressing mode of
+the Dallas DS80C390 part. In this mode, up to four meg of external RAM or code
+space can be directly addressed. See the data sheets at www.dalsemi.com for
+further information on this part.
+<P>Note that the compiler does not generate any code to place the processor
+into this mode (it defaults to 8051 compatible mode). Boot loader or similar
+code must ensure that the processor is in 24 bit contiguous addressing mode
+before calling the SDCC startup code.
+<P>Like the --model-large option, variables will by default be placed into
+the XDATA segment. However, a current limitation is that the compiler will
+spill variables into the DATA segment when it runs out of registers. This means
+that compiling complex code can rapidly fill up the DATA segment. This limitation
+is being worked on, and should be addressed in the next release of sdcc.
+<P>Segments may be placed anywhere in the 4 meg address space using the usual
+--*-loc options. Note that if any segments are located above 64K, the -r flag
+must be passed to the linker to generate the proper segment relocations, and
+the Intel HEX output format must be used. The -r flag can be passed to the
+linker by using the option -Wl-r on the sdcc command line.
+<P>--stack-10bit:
+<P>This option generates code for the 10 bit stack mode of the Dallas DS80C390
+part. In this mode, the stack is located in the lower 1K of the internal RAM,
+which is mapped to 0x400000.
+<P>With this option, sdcc will generate the proper addressing for stack variables.
+<P>Note that the support is incomplete, since it still uses a single byte
+as the stack pointer. This means that only the lower 256 bytes of the potential
+1K stack space can actually be used. However, this does allow you to reclaim
+the precious 256 bytes of low RAM for use for the DATA and IDATA segments.
+<P>The compiler will not generate any code to put the processor into 10 bit
+stack mode. It is important to ensure that the processor is in this mode before
+calling any re-entrant functions compiled with this option.
+<P>In principle, this should work with the --stack-auto option, but that has
+not been tested. It is incompatible with the --xstack option. It also only
+makes sense if the processor is in 24 bit contiguous addressing mode (see the
+--model-flat24 option).
<HR>
<A HREF="SDCCUdoc-18.html">Next</A>
<A HREF="SDCCUdoc-16.html">Previous</A>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
- <TITLE>SDCC Compiler User Guide: Pragmas</TITLE>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
+ <TITLE>SDCC Compiler User Guide: Defines created by the compiler.</TITLE>
<LINK HREF="SDCCUdoc-19.html" REL=next>
<LINK HREF="SDCCUdoc-17.html" REL=previous>
<LINK HREF="SDCCUdoc.html#toc18" REL=contents>
<A HREF="SDCCUdoc-17.html">Previous</A>
<A HREF="SDCCUdoc.html#toc18">Contents</A>
<HR>
-<H2><A NAME="Pragmaa"></A> <A NAME="s18">18. Pragmas</A> </H2>
+<H2><A NAME="Defines."></A> <A NAME="s18">18. Defines created by the compiler.</A> </H2>
-<P>SDCC supports the following #pragma directives. This directives are
-applicable only at a function level.
+<P>The compiler creates the following #defines .
<P>
<UL>
-<LI><B>SAVE</B>
-<A NAME="pragma save"></A> - this will save all the current options .</LI>
-<LI><B>RESTORE </B>
-<A NAME="pragma restore"></A> - will restore the saved options from the last save. Note that
-SAVES & RESTOREs cannot be nested. SDCC uses the same buffer to save the
-options each time a SAVE is called.</LI>
-<LI><B>NOGCSE</B>
-<A NAME="pragma nogcse"></A> - will stop global subexpression elimination.</LI>
-<LI><B>NOINDUCTION</B>
-<A NAME="pragma noinduction"></A> - will stop loop induction optimizations .</LI>
-<LI><B>NOJTBOUND</B>
-<A NAME="pragma nojtbound"></A> - will not generate code for boundary value checking , when switch
-statements are turned into jump-tables.</LI>
-<LI><B>NOOVERLAY </B>
-<A NAME="pragma nooverlay"></A> - the compiler will not overlay the parameters and local variables
-of a function.</LI>
-<LI><B>NOLOOPREVERSE</B>
-<A NAME="pragma noloopreverse"></A> - Will not do loop reversal optimization</LI>
-<LI><B>EXCLUDE NONE | {acc[,b[,dpl[,dph]]]</B>
-<A NAME="pragma exclude"></A>
-- The exclude pragma disables generation of pair of push/pop instruction in
-ISR function (using interrupt keyword). The directive should be placed immediately
-before the ISR function definition and it affects ALL ISR functions following
-it. To enable the normal register saving for ISR functions use "#pragma
-EXCLUDE none"</LI>
-<LI><B>CALLEE-SAVES function1[,function2[,function3...]]</B>
-<A NAME="pragma callee-saves"></A> -
-The compiler by default uses a caller saves convention for register saving
-across function calls, however this can cause unneccessary register pushing
-& popping when calling small functions from larger functions. This option
-can be used to switch the register saving convention for the function names
-specified. The compiler will not save registers when calling these functions,
-extra code will be generated at the entry & exit 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. In future
-the compiler (with interprocedural analysis) will be able to determine the
-appropriate scheme to use for each function call. If --callee-saves
-<A HREF="SDCCUdoc-4.html#--callee-saves"></A> command
-line option is used, the function names specified in #pragma CALLEE-SAVES
-is appended to the list of functions specified inthe command line.</LI>
+<LI>SDCC - this Symbol is always defined.</LI>
+<LI>SDCC_STACK_AUTO - this symbol is defined when --stack-auto option is used.</LI>
+<LI>SDCC_MODEL_SMALL - when small model is used.</LI>
+<LI>SDCC_MODEL_LARGE - when --model-large is used.</LI>
+<LI>SDCC_USE_XSTACK - when --xstack option is used.</LI>
</UL>
-<P>The pragma's are intended to be used to turn-off certain optimizations
-which might cause the compiler to generate extra stack / data space to store
-compiler generated temporary variables. This usually happens in large functions.
-Pragma directives should be used as shown in the following example, they are
-used to control options & 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.
-<P>
-<PRE>
-eg#pragma SAVE /* save the current settings */
-#pragma NOGCSE
- /* turnoff global subexpression elimination */
-#pragma NOINDUCTION /*
- turn off induction optimizations */
-int foo ()
-{
- ...
- /* large
- code */
- ...
-}
-#pragma RESTORE /* turn the optimizations back
- on */
-
-</PRE>
-<P>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.
<HR>
<A HREF="SDCCUdoc-19.html">Next</A>
<A HREF="SDCCUdoc-17.html">Previous</A>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
- <TITLE>SDCC Compiler User Guide: Library routines.</TITLE>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
+ <TITLE>SDCC Compiler User Guide: Pragmas</TITLE>
<LINK HREF="SDCCUdoc-20.html" REL=next>
<LINK HREF="SDCCUdoc-18.html" REL=previous>
<LINK HREF="SDCCUdoc.html#toc19" REL=contents>
<A HREF="SDCCUdoc-18.html">Previous</A>
<A HREF="SDCCUdoc.html#toc19">Contents</A>
<HR>
-<H2><A NAME="Library"></A> <A NAME="s19">19. Library routines.</A> </H2>
+<H2><A NAME="Pragmaa"></A> <A NAME="s19">19. Pragmas</A> </H2>
-<P>The following library routines are provided for your convenience.
-<P><B>stdio.h </B>- Contains the following functions printf & sprintf these routines
-are developed by Martijn van Balen <balen@natlab.research.philips.com>.
+<P>SDCC supports the following #pragma directives. This directives are
+applicable only at a function level.
<P>
+<UL>
+<LI><B>SAVE</B>
+<A NAME="pragma save"></A> - this will save all the current options .</LI>
+<LI><B>RESTORE </B>
+<A NAME="pragma restore"></A> - will restore the saved options from the last save. Note that
+SAVES & RESTOREs cannot be nested. SDCC uses the same buffer to save the
+options each time a SAVE is called.</LI>
+<LI><B>NOGCSE</B>
+<A NAME="pragma nogcse"></A> - will stop global subexpression elimination.</LI>
+<LI><B>NOINDUCTION</B>
+<A NAME="pragma noinduction"></A> - will stop loop induction optimizations .</LI>
+<LI><B>NOJTBOUND</B>
+<A NAME="pragma nojtbound"></A> - will not generate code for boundary value checking , when switch
+statements are turned into jump-tables.</LI>
+<LI><B>NOOVERLAY </B>
+<A NAME="pragma nooverlay"></A> - the compiler will not overlay the parameters and local variables
+of a function.</LI>
+<LI><B>NOLOOPREVERSE</B>
+<A NAME="pragma noloopreverse"></A> - Will not do loop reversal optimization</LI>
+<LI><B>EXCLUDE NONE | {acc[,b[,dpl[,dph]]]</B>
+<A NAME="pragma exclude"></A>
+- The exclude pragma disables generation of pair of push/pop instruction in
+ISR function (using interrupt keyword). The directive should be placed immediately
+before the ISR function definition and it affects ALL ISR functions following
+it. To enable the normal register saving for ISR functions use "#pragma
+EXCLUDE none"</LI>
+<LI><B>CALLEE-SAVES function1[,function2[,function3...]]</B>
+<A NAME="pragma callee-saves"></A> -
+The compiler by default uses a caller saves convention for register saving
+across function calls, however this can cause unneccessary register pushing
+& popping when calling small functions from larger functions. This option
+can be used to switch the register saving convention for the function names
+specified. The compiler will not save registers when calling these functions,
+extra code will be generated at the entry & exit 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. In future
+the compiler (with interprocedural analysis) will be able to determine the
+appropriate scheme to use for each function call. If --callee-saves
+<A HREF="SDCCUdoc-4.html#--callee-saves"></A> command
+line option is used, the function names specified in #pragma CALLEE-SAVES
+is appended to the list of functions specified inthe command line.</LI>
+</UL>
+<P>The pragma's are intended to be used to turn-off certain optimizations
+which might cause the compiler to generate extra stack / data space to store
+compiler generated temporary variables. This usually happens in large functions.
+Pragma directives should be used as shown in the following example, they are
+used to control options & 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.
<P>
<PRE>
-%[flags][width][b|B|l|L]type flags: - left justify output in specified field width
-
- + prefix output with +/- sign if output is signed
- type
- space prefix output with a blank if it's a signed
- positive value
- width: specifies minimum number of characters
- outputted for numbers
- or strings.
-
- - For numbers, spaces are added on the left when needed.
-
- If width starts with a zero character, zeroes and used
-
- instead of spaces.
- - For strings, spaces are are
- added on the left or right (when
- flag '-' is used)
- when needed.
-
- b/B: byte argument
- (used by d, u, o, x, X)
- l/L: long argument (used by d,
- u, o, x, X)
- type: d decimal number
- u
- unsigned decimal number
- o unsigned octal number
-
- x unsigned hexadecimal number (0-9, a-f)
- X
- unsigned hexadecimal number (0-9, A-F)
- c character
-
- s string (generic pointer)
- p
- generic pointer (I:data/idata, C:code, X:xdata, P:paged)
-
- f float (still to be implemented)
-
-</PRE>
-<P>Also contains a very simple version of printf (<B>printf_small</B>). This simplified
-version of printf supports only the following formats.
-<P>
-<PRE>
-format output type argument-type <bf>
-%d decimal
- int
-%ld decimal long
-%hd decimal short/char
-
-%x hexadecimal int
-%lx hexadecimal long
-
-%hx hexadecimal short/char
-%o octal int
-
-%lo octal long
-%ho octal short/char
-
-%c character char/short
-%s character _generic
- pointer
- <p><tt>The routine is <tt><bf>very stack intesive , --stack-after-data parameter should
- be used when using this routine, the routine also takes about 1K of code space
- .It also expects an external function named putchar(char ) to be present (this
- can be changed). When using the %s format the string / pointer should
- be cast to a generic pointer. eg.
+eg#pragma SAVE /* save the current settings */
+#pragma NOGCSE
+ /* turnoff global subexpression elimination */
+#pragma NOINDUCTION /*
+ turn off induction optimizations */
+int foo ()
+{
+ ...
+ /* large
+ code */
+ ...
+}
+#pragma RESTORE /* turn the optimizations back
+ on */
</PRE>
+<P>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.
<HR>
<A HREF="SDCCUdoc-20.html">Next</A>
<A HREF="SDCCUdoc-18.html">Previous</A>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
<TITLE>SDCC Compiler User Guide: Installation </TITLE>
<LINK HREF="SDCCUdoc-3.html" REL=next>
<LINK HREF="SDCCUdoc-1.html" REL=previous>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
- <TITLE>SDCC Compiler User Guide: Interfacing with assembly routines.</TITLE>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
+ <TITLE>SDCC Compiler User Guide: Library routines.</TITLE>
<LINK HREF="SDCCUdoc-21.html" REL=next>
<LINK HREF="SDCCUdoc-19.html" REL=previous>
<LINK HREF="SDCCUdoc.html#toc20" REL=contents>
<A HREF="SDCCUdoc-19.html">Previous</A>
<A HREF="SDCCUdoc.html#toc20">Contents</A>
<HR>
-<H2><A NAME="Interface_asm"></A> <A NAME="s20">20. Interfacing with assembly routines.</A> </H2>
+<H2><A NAME="Library"></A> <A NAME="s20">20. Library routines.</A> </H2>
-<H2><A NAME="ss20.1">20.1 Global registers used for parameter passing.</A>
- </H2>
-
-<P>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).
-<H3>Assembler routine non-reentrant </H3>
-
-<P>In the following example the function<B> cfunc</B> calls an assembler routine
-<B>asm_func</B>, which takes two parameters.
-<P>extern int asm_func( unsigned short, unsigned short);
-<P>
-<PRE>
-
-int c_func (unsigned short i, unsigned short j)
-{
- return
- asm_func(i,j);
-}
-int main()
-{
- return c_func(10,9);
-}
-
-</PRE>
-<P>The corresponding assembler function is:-
-<P>
-<PRE>
- .globl _asm_func_PARM_2
- .globl _asm_func
- .area
- OSEG
-_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
- ret
-
-</PRE>
-<P>Note here that the return 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.
-<P>The parameter naming convention is <B>_<function_name>_PARM_<n>,</B>
-where n is the parameter number starting from 1, and counting from the left.
-The first parameter is passed in "dpl" for One bye parameter, "dptr" if two bytes,
-"b,dptr" for three bytes and "acc,b,dptr" for four bytes, the <CODE></CODE><CODE><B>varaible name for
-the second parameter will be _<function_name>_PARM_2.</B></CODE>
-<P>Assemble the assembler routine with the following command.
-<P>
-<PRE>
-asx8051 -losg asmfunc.asm
-
-</PRE>
-<P>Then compile and link the assembler routine to the C source file with the
-following command,
-<P>
-<PRE>
-sdcc cfunc.c asmfunc.rel
-
-</PRE>
-<H3>Assembler routine is reentrant </H3>
-
-<P>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.
-<P>extern int asm_func( unsigned short, unsigned short);
-<P>
-<PRE>
- int c_func (unsigned short i, unsigned short j) reentrant
-{
-
- return asm_func(i,j);
-}
-int main()
-{
- return c_func(10,9);
-
-}
-
-</PRE>
-<P>The corresponding assembler routine is.
-<P>
-<PRE>
- .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
-
-</PRE>
-<P>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.
-<H2><A NAME="ss20.2">20.2 With --noregparms option.</A>
- </H2>
-
-<P>When the source is compiled with --noregparms option , space is allocated
-for each of the parameters passed to a routine.
-<H3>Assembler routine non-reentrant. </H3>
-
-<P>In the following example the function<B> cfunc</B> calls an assembler routine
-<B>asm_func</B>, which takes two parameters.
-<P>
-<PRE>
-extern int asm_func( unsigned short, unsigned short);
-int c_func (unsigned short i, unsigned short j)
-{
- return
- asm_func(i,j);
-}
-int main()
-{
- return c_func(10,9);
-}
-
-</PRE>
-<P>The corresponding assembler function is:-
-<P>
-<PRE>
- .globl _asm_func_PARM_1
- .globl _asm_func_PARM_2
-
- .globl _asm_func
- .area OSEG
-_asm_func_PARM_1: .ds 1
-_asm_func_PARM_2:
- .ds 1
- .area CSEG
-_asm_func:
- mov a,_asm_func_PARM_1
-
- add a,_asm_func_PARM_2
- mov dpl,a
- mov
- dpl,#0x00
- ret
-
-</PRE>
-<P>Note here that the return 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.
-<P>The parameter naming convention is <B>_<function_name>_PARM_<n>,</B>
-where n is the parameter number starting from 1, and counting from the left.
-i.e. the <CODE></CODE><CODE><B>left-most parameter name will be _<function_name>_PARM_1.</B></CODE>
-<P>Assemble the assembler routine with the following command.
+<P>The following library routines are provided for your convenience.
+<P><B>stdio.h </B>- Contains the following functions printf & sprintf these routines
+are developed by Martijn van Balen <balen@natlab.research.philips.com>.
<P>
-<PRE>
-asx8051 -losg asmfunc.asm
-
-</PRE>
-<P>Then compile and link the assembler routine to the C source file with the
-following command,
<P>
<PRE>
-sdcc cfunc.c asmfunc.rel
+%[flags][width][b|B|l|L]type flags: - left justify output in specified field width
+
+ + prefix output with +/- sign if output is signed
+ type
+ space prefix output with a blank if it's a signed
+ positive value
+ width: specifies minimum number of characters
+ outputted for numbers
+ or strings.
+
+ - For numbers, spaces are added on the left when needed.
+
+ If width starts with a zero character, zeroes and used
+
+ instead of spaces.
+ - For strings, spaces are are
+ added on the left or right (when
+ flag '-' is used)
+ when needed.
+
+ b/B: byte argument
+ (used by d, u, o, x, X)
+ l/L: long argument (used by d,
+ u, o, x, X)
+ type: d decimal number
+ u
+ unsigned decimal number
+ o unsigned octal number
+
+ x unsigned hexadecimal number (0-9, a-f)
+ X
+ unsigned hexadecimal number (0-9, A-F)
+ c character
+
+ s string (generic pointer)
+ p
+ generic pointer (I:data/idata, C:code, X:xdata, P:paged)
+
+ f float (still to be implemented)
</PRE>
-<H3>Assembler routine is reentrant. </H3>
-
-<P>In this case the parameters 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.
-<P>extern int asm_func( unsigned short, unsigned short);
+<P>Also contains a very simple version of printf (<B>printf_small</B>). This simplified
+version of printf supports only the following formats.
<P>
<PRE>
- int c_func (unsigned short i, unsigned short j) reentrant
-{
-
- return asm_func(i,j);
-}
-int main()
-{
- return c_func(10,9);
-
-}
-
-</PRE>
-<P>The corresponding assembler routine is.
-<P>
-<PRE>
- .globl _asm_func
-_asm_func:
- push _bp
- mov _bp,sp
-
- mov a,_bp
- clr c
- add a,#0xfd
- mov
- r0,a
- mov a,_bp
- clr c
- add a,#0xfc
-
- mov r1,a
- mov a,@r0
- add a,@r1
- mov dpl,a
-
- mov dph,#0x00
- mov sp,_bp
- pop _bp
- ret
+format output type argument-type <bf>
+%d decimal
+ int
+%ld decimal long
+%hd decimal short/char
+
+%x hexadecimal int
+%lx hexadecimal long
+
+%hx hexadecimal short/char
+%o octal int
+
+%lo octal long
+%ho octal short/char
+
+%c character char/short
+%s character _generic
+ pointer
+ <p><tt>The routine is <tt><bf>very stack intesive , --stack-after-data parameter should
+ be used when using this routine, the routine also takes about 1K of code space
+ .It also expects an external function named putchar(char ) to be present (this
+ can be changed). When using the %s format the string / pointer should
+ be cast to a generic pointer. eg.
</PRE>
-<P>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.
<HR>
<A HREF="SDCCUdoc-21.html">Next</A>
<A HREF="SDCCUdoc-19.html">Previous</A>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
- <TITLE>SDCC Compiler User Guide: External Stack.</TITLE>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
+ <TITLE>SDCC Compiler User Guide: Interfacing with assembly routines.</TITLE>
<LINK HREF="SDCCUdoc-22.html" REL=next>
<LINK HREF="SDCCUdoc-20.html" REL=previous>
<LINK HREF="SDCCUdoc.html#toc21" REL=contents>
<A HREF="SDCCUdoc-20.html">Previous</A>
<A HREF="SDCCUdoc.html#toc21">Contents</A>
<HR>
-<H2><A NAME="xstack"></A> <A NAME="s21">21. External Stack.</A> </H2>
+<H2><A NAME="Interface_asm"></A> <A NAME="s21">21. Interfacing with assembly routines.</A> </H2>
-<P>The external stack is located at the start of the external ram segment
-, and is 256 bytes in size. When --xstack option is used to compile the program
-, the parameters and local variables of all reentrant functions are allocated
-in this area. This option is provided for programs with large stack space requirements.
-When used with the --stack-auto option, all parameters and local variables
-are allocated on the external stack (note support libraries will need to be
-recompiled with the same options).
-<P>The compiler outputs the higher order address byte of the external ram
-segment into PORT P2, therefore when using the External Stack option, this
-port MAY NOT be used by the application program.
+<H2><A NAME="ss21.1">21.1 Global registers used for parameter passing.</A>
+ </H2>
+
+<P>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).
+<H3>Assembler routine non-reentrant </H3>
+
+<P>In the following example the function<B> cfunc</B> calls an assembler routine
+<B>asm_func</B>, which takes two parameters.
+<P>extern int asm_func( unsigned short, unsigned short);
+<P>
+<PRE>
+
+int c_func (unsigned short i, unsigned short j)
+{
+ return
+ asm_func(i,j);
+}
+int main()
+{
+ return c_func(10,9);
+}
+
+</PRE>
+<P>The corresponding assembler function is:-
+<P>
+<PRE>
+ .globl _asm_func_PARM_2
+ .globl _asm_func
+ .area
+ OSEG
+_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
+ ret
+
+</PRE>
+<P>Note here that the return 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.
+<P>The parameter naming convention is <B>_<function_name>_PARM_<n>,</B>
+where n is the parameter number starting from 1, and counting from the left.
+The first parameter is passed in "dpl" for One bye parameter, "dptr" if two bytes,
+"b,dptr" for three bytes and "acc,b,dptr" for four bytes, the <CODE></CODE><CODE><B>varaible name for
+the second parameter will be _<function_name>_PARM_2.</B></CODE>
+<P>Assemble the assembler routine with the following command.
+<P>
+<PRE>
+asx8051 -losg asmfunc.asm
+
+</PRE>
+<P>Then compile and link the assembler routine to the C source file with the
+following command,
+<P>
+<PRE>
+sdcc cfunc.c asmfunc.rel
+
+</PRE>
+<H3>Assembler routine is reentrant </H3>
+
+<P>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.
+<P>extern int asm_func( unsigned short, unsigned short);
+<P>
+<PRE>
+ int c_func (unsigned short i, unsigned short j) reentrant
+{
+
+ return asm_func(i,j);
+}
+int main()
+{
+ return c_func(10,9);
+
+}
+
+</PRE>
+<P>The corresponding assembler routine is.
+<P>
+<PRE>
+ .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
+
+</PRE>
+<P>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.
+<H2><A NAME="ss21.2">21.2 With --noregparms option.</A>
+ </H2>
+
+<P>When the source is compiled with --noregparms option , space is allocated
+for each of the parameters passed to a routine.
+<H3>Assembler routine non-reentrant. </H3>
+
+<P>In the following example the function<B> cfunc</B> calls an assembler routine
+<B>asm_func</B>, which takes two parameters.
+<P>
+<PRE>
+extern int asm_func( unsigned short, unsigned short);
+int c_func (unsigned short i, unsigned short j)
+{
+ return
+ asm_func(i,j);
+}
+int main()
+{
+ return c_func(10,9);
+}
+
+</PRE>
+<P>The corresponding assembler function is:-
+<P>
+<PRE>
+ .globl _asm_func_PARM_1
+ .globl _asm_func_PARM_2
+
+ .globl _asm_func
+ .area OSEG
+_asm_func_PARM_1: .ds 1
+_asm_func_PARM_2:
+ .ds 1
+ .area CSEG
+_asm_func:
+ mov a,_asm_func_PARM_1
+
+ add a,_asm_func_PARM_2
+ mov dpl,a
+ mov
+ dpl,#0x00
+ ret
+
+</PRE>
+<P>Note here that the return 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.
+<P>The parameter naming convention is <B>_<function_name>_PARM_<n>,</B>
+where n is the parameter number starting from 1, and counting from the left.
+i.e. the <CODE></CODE><CODE><B>left-most parameter name will be _<function_name>_PARM_1.</B></CODE>
+<P>Assemble the assembler routine with the following command.
+<P>
+<PRE>
+asx8051 -losg asmfunc.asm
+
+</PRE>
+<P>Then compile and link the assembler routine to the C source file with the
+following command,
+<P>
+<PRE>
+sdcc cfunc.c asmfunc.rel
+
+</PRE>
+<H3>Assembler routine is reentrant. </H3>
+
+<P>In this case the parameters 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.
+<P>extern int asm_func( unsigned short, unsigned short);
+<P>
+<PRE>
+ int c_func (unsigned short i, unsigned short j) reentrant
+{
+
+ return asm_func(i,j);
+}
+int main()
+{
+ return c_func(10,9);
+
+}
+
+</PRE>
+<P>The corresponding assembler routine is.
+<P>
+<PRE>
+ .globl _asm_func
+_asm_func:
+ push _bp
+ mov _bp,sp
+
+ mov a,_bp
+ clr c
+ add a,#0xfd
+ mov
+ r0,a
+ mov a,_bp
+ clr c
+ add a,#0xfc
+
+ mov r1,a
+ mov a,@r0
+ add a,@r1
+ mov dpl,a
+
+ mov dph,#0x00
+ mov sp,_bp
+ pop _bp
+ ret
+
+</PRE>
+<P>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.
<HR>
<A HREF="SDCCUdoc-22.html">Next</A>
<A HREF="SDCCUdoc-20.html">Previous</A>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
- <TITLE>SDCC Compiler User Guide: ANSI-Compliance.</TITLE>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
+ <TITLE>SDCC Compiler User Guide: External Stack.</TITLE>
<LINK HREF="SDCCUdoc-23.html" REL=next>
<LINK HREF="SDCCUdoc-21.html" REL=previous>
<LINK HREF="SDCCUdoc.html#toc22" REL=contents>
<A HREF="SDCCUdoc-21.html">Previous</A>
<A HREF="SDCCUdoc.html#toc22">Contents</A>
<HR>
-<H2><A NAME="ANSI_Compliance"></A> <A NAME="s22">22. ANSI-Compliance.</A> </H2>
+<H2><A NAME="xstack"></A> <A NAME="s22">22. External Stack.</A> </H2>
-<P>Deviations from the compliancy.
-<P>
-<OL>
-<LI>functions are not always reentrant.</LI>
-<LI>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.
-<PRE>
-eg
-
-</PRE>
-</LI>
-</OL>
-<P>
-<PRE>
-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 */
-}
-
-</PRE>
-<P>
-<OL>
-<LI>'long long' (64 bit integers) not supported.</LI>
-<LI>'double' precision floating point not supported.</LI>
-<LI>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. </LI>
-<LI>No support for setjmp and longjmp (for now).</LI>
-<LI>Old K&R style function declarations are NOT allowed.</LI>
-</OL>
-<P>
-<PRE>
-foo( i,j) /* this old style of function declarations */
-int i,j; /* are
- valid in ANSI .. not valid in SDCC */
-{
-...
-}
-
-</PRE>
-<P>
-<OL>
-<LI>functions declared as pointers must be dereferenced during the call.
-<PRE>
-int (*foo)();
-
-</PRE>
-</LI>
-</OL>
-<P>
-<PRE>
- ...
- /* has to be called like this */
- (*foo)();/* ansi standard
- allows calls to be made like 'foo()' */
-
-</PRE>
+<P>The external stack is located at the start of the external ram segment
+, and is 256 bytes in size. When --xstack option is used to compile the program
+, the parameters and local variables of all reentrant functions are allocated
+in this area. This option is provided for programs with large stack space requirements.
+When used with the --stack-auto option, all parameters and local variables
+are allocated on the external stack (note support libraries will need to be
+recompiled with the same options).
+<P>The compiler outputs the higher order address byte of the external ram
+segment into PORT P2, therefore when using the External Stack option, this
+port MAY NOT be used by the application program.
<HR>
<A HREF="SDCCUdoc-23.html">Next</A>
<A HREF="SDCCUdoc-21.html">Previous</A>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
- <TITLE>SDCC Compiler User Guide: Cyclomatic Complexity</TITLE>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
+ <TITLE>SDCC Compiler User Guide: ANSI-Compliance.</TITLE>
<LINK HREF="SDCCUdoc-24.html" REL=next>
<LINK HREF="SDCCUdoc-22.html" REL=previous>
<LINK HREF="SDCCUdoc.html#toc23" REL=contents>
<A HREF="SDCCUdoc-22.html">Previous</A>
<A HREF="SDCCUdoc.html#toc23">Contents</A>
<HR>
-<H2><A NAME="Cyclomatic"></A> <A NAME="s23">23. Cyclomatic Complexity</A> </H2>
+<H2><A NAME="ANSI_Compliance"></A> <A NAME="s23">23. ANSI-Compliance.</A> </H2>
-<P>Cyclomatic complexity of a function is defined as the number of independent
-paths the program can take during execution of the function. This is an important
-number since it defines the number test cases you have to generate to validate
-the function . The accepted industry standard for complexity number is 10,
-if the cyclomatic complexity reported by SDCC exceeds 10 you should think about
-simplification of the function logic.
-<P>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.
+<P>Deviations from the compliancy.
<P>
+<OL>
+<LI>functions are not always reentrant.</LI>
+<LI>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.
<PRE>
-complexity = (number of edges in control flow graph) -
- (number
- of nodes in control flow graph) + 2;
+eg
+
+</PRE>
+</LI>
+</OL>
+<P>
+<PRE>
+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 */
+}
+
+</PRE>
+<P>
+<OL>
+<LI>'long long' (64 bit integers) not supported.</LI>
+<LI>'double' precision floating point not supported.</LI>
+<LI>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. </LI>
+<LI>No support for setjmp and longjmp (for now).</LI>
+<LI>Old K&R style function declarations are NOT allowed.</LI>
+</OL>
+<P>
+<PRE>
+foo( i,j) /* this old style of function declarations */
+int i,j; /* are
+ valid in ANSI .. not valid in SDCC */
+{
+...
+}
+
+</PRE>
+<P>
+<OL>
+<LI>functions declared as pointers must be dereferenced during the call.
+<PRE>
+int (*foo)();
+
+</PRE>
+</LI>
+</OL>
+<P>
+<PRE>
+ ...
+ /* has to be called like this */
+ (*foo)();/* ansi standard
+ allows calls to be made like 'foo()' */
</PRE>
-<P>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 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.
<HR>
<A HREF="SDCCUdoc-24.html">Next</A>
<A HREF="SDCCUdoc-22.html">Previous</A>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
- <TITLE>SDCC Compiler User Guide: TIPS</TITLE>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
+ <TITLE>SDCC Compiler User Guide: Cyclomatic Complexity</TITLE>
<LINK HREF="SDCCUdoc-25.html" REL=next>
<LINK HREF="SDCCUdoc-23.html" REL=previous>
<LINK HREF="SDCCUdoc.html#toc24" REL=contents>
<A HREF="SDCCUdoc-23.html">Previous</A>
<A HREF="SDCCUdoc.html#toc24">Contents</A>
<HR>
-<H2><A NAME="Tips"></A> <A NAME="s24">24. TIPS</A> </H2>
+<H2><A NAME="Cyclomatic"></A> <A NAME="s24">24. Cyclomatic Complexity</A> </H2>
-<P>Here are a few guide-lines that will help the compiler generate more efficient
-code, some of the tips are specific to this compiler others are generally good
-programming practice.
+<P>Cyclomatic complexity of a function is defined as the number of independent
+paths the program can take during execution of the function. This is an important
+number since it defines the number test cases you have to generate to validate
+the function . The accepted industry standard for complexity number is 10,
+if the cyclomatic complexity reported by SDCC exceeds 10 you should think about
+simplification of the function logic.
+<P>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.
<P>
-<UL>
-<LI>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 a 'short' or
-'char' instead of an 'int'.</LI>
-<LI>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.</LI>
-<LI>NEVER jump into a LOOP.</LI>
-<LI>Declare the variables to be local whenever possible, especially loop control
-variables (induction).</LI>
-<LI>Since the compiler does not do implicit integral promotion, the programmer
-should do an explicit cast when integral promotion is required.</LI>
-<LI>Reducing the size of division , multiplication & modulus operations
-can reduce code size substantially. Take the following code for example.
<PRE>
-foobar( unsigned int p1, unsigned char ch)
-{
- unsigned char ch1
- = p1 % ch ;
- ....
-}
-
+complexity = (number of edges in control flow graph) -
+ (number
+ of nodes in control flow graph) + 2;
+
</PRE>
-
-<P>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). If the code is changed to
-
-<P>
-<PRE>
-foobar( unsigned int p1, unsigned char ch)
-{
- unsigned char ch1
- = (unsigned char)p1 % ch ;
- ....
-}
-
-</PRE>
-<P>It would substantially reduce the code generated (future versions of the
-compiler will be smart enough to detect such optimization oppurtunities).
-</LI>
-</UL>
-<P><B>Notes from an USER ( Trefor@magera.freeserve.co.uk )</B>
-<P>The 8051 family of micro controller have a minimum of 128 bytes of internal
-memory which is structured as follows
-<P>- Bytes 00-1F - 32 bytes to hold up to 4 banks of the registers R7 to R7
-<P>
-<P>- Bytes 20-2F - 16 bytes to hold 128 bit variables and
-<P>- Bytes 30-7F - 60 bytes for general purpose use.
-<P>Normally the SDCC compiler will only utilise the first bank of registers,
-but it is possible to specify that other banks of registers should be used
-in interrupt routines. By default, the compiler will place the stack after
-the last bank of used registers, i.e. if the first 2 banks of registers are
-used, it will position the base of the internal stack at address 16 (0X10).
-This implies that as the stack grows, it will use up the remaining register
-banks, and the 16 bytes used by the 128 bit variables, and 60 bytes for general
-purpose use.
-<P>By default, the compiler uses the 60 general purpose bytes to hold "near
-data". The compiler/optimiser may also declare some Local Variables in
-this area to hold local data.
-<P>If any of the 128 bit variables are used, or near data is being used then
-care needs to be taken to ensure that the stack does not grow so much that
-it starts to over write either your bit variables or "near data".
-There is no runtime checking to prevent this from happening.
-<P>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.
-<P>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.
-<P>--stack-loc will allow you specify the start of the stack, i.e. you could
-start it after any data in the general purpose area. However this may waste
-the memory not used by the register banks and if the size of the "near
-data" increases, it may creep into the bottom of the stack.
-<P>--stack-after-data, similar to the --stack-loc, but it automatically places
-the stack after the end of the "near data". Again this could waste
-any spare register space.
-<P>--data-loc allows you to specify the start address of the near data. This
-could be used to move the "near data" further away from the stack
-giving it more room to grow. This will only work if no bit variables are being
-used and the stack can grow to use the bit variable space.
-<P>Conclusion.
-<P>If you find that the stack is over writing your bit variables or "near
-data" then the approach which best utilised the 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.
-<P>If bit variables are being used, another method would be to try and squeeze
-the data area in the unused register banks if it will fit, and start the stack
-after the last bit variable.
+<P>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 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.
<HR>
<A HREF="SDCCUdoc-25.html">Next</A>
<A HREF="SDCCUdoc-23.html">Previous</A>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
- <TITLE>SDCC Compiler User Guide: Retargetting for other MCUs.</TITLE>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
+ <TITLE>SDCC Compiler User Guide: TIPS</TITLE>
<LINK HREF="SDCCUdoc-26.html" REL=next>
<LINK HREF="SDCCUdoc-24.html" REL=previous>
<LINK HREF="SDCCUdoc.html#toc25" REL=contents>
<A HREF="SDCCUdoc-24.html">Previous</A>
<A HREF="SDCCUdoc.html#toc25">Contents</A>
<HR>
-<H2><A NAME="Retargetting"></A> <A NAME="s25">25. Retargetting for other MCUs.</A> </H2>
+<H2><A NAME="Tips"></A> <A NAME="s25">25. TIPS</A> </H2>
-<P>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.
+<P>Here are a few guide-lines that will help the compiler generate more efficient
+code, some of the tips are specific to this compiler others are generally good
+programming practice.
<P>
-<OL>
-<LI>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.</LI>
-<LI>The second phase involves generating an intermediate code which can be
-easy manipulated during the later phases. This phase is entirely MCU independent.
-The intermediate code generation assumes the target machine has unlimited number
-of registers, and designates them with the name iTemp. The compiler can be
-made to dump a human readable form of the code generated by using the --dumpraw
-option.</LI>
-<LI>This phase does the bulk of the standard optimizations and is also MCU
-independent. This phase can be broken down into several sub-phases.
<UL>
-<LI>Break down intermediate code (iCode) into basic blocks.</LI>
-<LI>Do control flow & data flow analysis on the basic blocks.</LI>
-<LI>Do local common subexpression elimination, then global subexpression elimination</LI>
-<LI>dead code elimination</LI>
-<LI>loop optimizations</LI>
-<LI>if loop optimizations caused any changes then do 'global subexpression
-elimination' and 'dead code elimination' again.</LI>
-</UL>
-</LI>
-<LI>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.</LI>
-<LI>Phase five is register allocation. There are two parts to this process
-.
-<OL>
-<LI>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.</LI>
-<LI>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.</LI>
-</OL>
+<LI>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 a 'short' or
+'char' instead of an 'int'.</LI>
+<LI>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.</LI>
+<LI>NEVER jump into a LOOP.</LI>
+<LI>Declare the variables to be local whenever possible, especially loop control
+variables (induction).</LI>
+<LI>Since the compiler does not do implicit integral promotion, the programmer
+should do an explicit cast when integral promotion is required.</LI>
+<LI>Reducing the size of division , multiplication & modulus operations
+can reduce code size substantially. Take the following code for example.
+<PRE>
+foobar( unsigned int p1, unsigned char ch)
+{
+ unsigned char ch1
+ = p1 % ch ;
+ ....
+}
+
+</PRE>
+
+<P>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). If the code is changed to
+
+<P>
+<PRE>
+foobar( unsigned int p1, unsigned char ch)
+{
+ unsigned char ch1
+ = (unsigned char)p1 % ch ;
+ ....
+}
+
+</PRE>
+<P>It would substantially reduce the code generated (future versions of the
+compiler will be smart enough to detect such optimization oppurtunities).
</LI>
-<LI>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.</LI>
-<LI>As mentioned in the optimization section the peep-hole optimizer is rule
-based system, which can reprogrammed for other MCUs.</LI>
-</OL>
+</UL>
+<P><B>Notes from an USER ( Trefor@magera.freeserve.co.uk )</B>
+<P>The 8051 family of micro controller have a minimum of 128 bytes of internal
+memory which is structured as follows
+<P>- Bytes 00-1F - 32 bytes to hold up to 4 banks of the registers R7 to R7
+<P>
+<P>- Bytes 20-2F - 16 bytes to hold 128 bit variables and
+<P>- Bytes 30-7F - 60 bytes for general purpose use.
+<P>Normally the SDCC compiler will only utilise the first bank of registers,
+but it is possible to specify that other banks of registers should be used
+in interrupt routines. By default, the compiler will place the stack after
+the last bank of used registers, i.e. if the first 2 banks of registers are
+used, it will position the base of the internal stack at address 16 (0X10).
+This implies that as the stack grows, it will use up the remaining register
+banks, and the 16 bytes used by the 128 bit variables, and 60 bytes for general
+purpose use.
+<P>By default, the compiler uses the 60 general purpose bytes to hold "near
+data". The compiler/optimiser may also declare some Local Variables in
+this area to hold local data.
+<P>If any of the 128 bit variables are used, or near data is being used then
+care needs to be taken to ensure that the stack does not grow so much that
+it starts to over write either your bit variables or "near data".
+There is no runtime checking to prevent this from happening.
+<P>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.
+<P>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.
+<P>--stack-loc will allow you specify the start of the stack, i.e. you could
+start it after any data in the general purpose area. However this may waste
+the memory not used by the register banks and if the size of the "near
+data" increases, it may creep into the bottom of the stack.
+<P>--stack-after-data, similar to the --stack-loc, but it automatically places
+the stack after the end of the "near data". Again this could waste
+any spare register space.
+<P>--data-loc allows you to specify the start address of the near data. This
+could be used to move the "near data" further away from the stack
+giving it more room to grow. This will only work if no bit variables are being
+used and the stack can grow to use the bit variable space.
+<P>Conclusion.
+<P>If you find that the stack is over writing your bit variables or "near
+data" then the approach which best utilised the 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.
+<P>If bit variables are being used, another method would be to try and squeeze
+the data area in the unused register banks if it will fit, and start the stack
+after the last bit variable.
<HR>
<A HREF="SDCCUdoc-26.html">Next</A>
<A HREF="SDCCUdoc-24.html">Previous</A>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
- <TITLE>SDCC Compiler User Guide: Reporting Bugs</TITLE>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
+ <TITLE>SDCC Compiler User Guide: Retargetting for other MCUs.</TITLE>
<LINK HREF="SDCCUdoc-27.html" REL=next>
<LINK HREF="SDCCUdoc-25.html" REL=previous>
<LINK HREF="SDCCUdoc.html#toc26" REL=contents>
<A HREF="SDCCUdoc-25.html">Previous</A>
<A HREF="SDCCUdoc.html#toc26">Contents</A>
<HR>
-<H2><A NAME="Bugs"></A> <A NAME="s26">26. Reporting Bugs</A> </H2>
+<H2><A NAME="Retargetting"></A> <A NAME="s26">26. Retargetting for other MCUs.</A> </H2>
-<P>Shoot of an email to 'sandeep.dutta@usa.net', as a matter of principle
-I always reply to all email's sent to me. Bugs will be fixed ASAP. When reporting
-a bug , it is useful to include a small snippet of code that is causing the
-problem, if possible compile your program with the --dumpall option and send
-the dump files along with the bug report.
+<P>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.
+<P>
+<OL>
+<LI>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.</LI>
+<LI>The second phase involves generating an intermediate code which can be
+easy manipulated during the later phases. This phase is entirely MCU independent.
+The intermediate code generation assumes the target machine has unlimited number
+of registers, and designates them with the name iTemp. The compiler can be
+made to dump a human readable form of the code generated by using the --dumpraw
+option.</LI>
+<LI>This phase does the bulk of the standard optimizations and is also MCU
+independent. This phase can be broken down into several sub-phases.
+<UL>
+<LI>Break down intermediate code (iCode) into basic blocks.</LI>
+<LI>Do control flow & data flow analysis on the basic blocks.</LI>
+<LI>Do local common subexpression elimination, then global subexpression elimination</LI>
+<LI>dead code elimination</LI>
+<LI>loop optimizations</LI>
+<LI>if loop optimizations caused any changes then do 'global subexpression
+elimination' and 'dead code elimination' again.</LI>
+</UL>
+</LI>
+<LI>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.</LI>
+<LI>Phase five is register allocation. There are two parts to this process
+.
+<OL>
+<LI>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.</LI>
+<LI>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.</LI>
+</OL>
+</LI>
+<LI>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.</LI>
+<LI>As mentioned in the optimization section the peep-hole optimizer is rule
+based system, which can reprogrammed for other MCUs.</LI>
+</OL>
<HR>
<A HREF="SDCCUdoc-27.html">Next</A>
<A HREF="SDCCUdoc-25.html">Previous</A>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
- <TITLE>SDCC Compiler User Guide: SDCDB - Source level debugger.</TITLE>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
+ <TITLE>SDCC Compiler User Guide: Reporting Bugs</TITLE>
<LINK HREF="SDCCUdoc-28.html" REL=next>
<LINK HREF="SDCCUdoc-26.html" REL=previous>
<LINK HREF="SDCCUdoc.html#toc27" REL=contents>
<A HREF="SDCCUdoc-26.html">Previous</A>
<A HREF="SDCCUdoc.html#toc27">Contents</A>
<HR>
-<H2><A NAME="s27">27. SDCDB - Source level debugger.</A> </H2>
+<H2><A NAME="Bugs"></A> <A NAME="s27">27. Reporting Bugs</A> </H2>
-<P>SDCC is distributed with a source level debugger. The debugger uses a command
-line interface, the command repertoire of the debugger has been kept as close
-to gdb ( the GNU debugger) as possible. The configuration and build process
-of the compiler see Installation
-<A HREF="SDCCUdoc-2.html#Installation"></A> also builds and installs the debugger in
-the target directory specified during configuration. The debugger allows you
-debug BOTH at the C source and at the ASM source level.
-<H2><A NAME="ss27.1">27.1 Compiling for debugging.</A>
- </H2>
-
-<P>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 .
-<H2><A NAME="ss27.2">27.2 How the debugger works.</A>
- </H2>
-
-<P>When the --debug option is specified the compiler generates extra symbol
-information some of which are put into the the assembler source and some are
-put into the .cdb file, the linker updates the .cdb file with the address information
-for the symbols. The debugger reads the symbolic information generated by the
-compiler & the address information generated by the linker. It uses the
-SIMULATOR (Daniel's S51) to execute the program, the program execution is controlled
-by the debugger. When a command is issued for the debugger, it translates it
-into appropriate commands for the simulator .
-<H2><A NAME="ss27.3">27.3 Starting the debugger.</A>
- </H2>
-
-<P>The debugger can be started using the following command line. (Assume the
-file you are debugging has
-<P>the file name foo).
-<P>
-<PRE>
->sdcdb foo
-
-</PRE>
-<P>The debugger will look for the following files.
-<P>
-<OL>
-<LI>foo.c - the source file.</LI>
-<LI>foo.cdb - the debugger symbol information file.</LI>
-<LI>foo.ihx - the intel hex format object file.</LI>
-</OL>
-<H2><A NAME="ss27.4">27.4 Command line options.</A>
- </H2>
-
-<P>
-<UL>
-<LI>--directory=<source file directory> this option can used to specify
-the directory search list. The debugger will look into the directory list specified
-for source , cdb & ihx files. The items in the directory list must be separated
-by ':' , e.g. if the source files can be in the directories /home/src1 and
-/home/src2, the --directory option should be --directory=/home/src1:/home/src2
-. Note there can be no spaces in the option. </LI>
-<LI>-cd <directory> - change to the <directory>.</LI>
-<LI>-fullname - used by GUI front ends.</LI>
-<LI>-cpu <cpu-type> - this argument is passed to the simulator please
-see the simulator docs for details.</LI>
-<LI>-X <Clock frequency > this options is passed to the simulator please
-see simulator docs for details.</LI>
-<LI>-s <serial port file> passed to simulator see simulator docs for
-details.</LI>
-<LI>-S <serial in,out> passed to simulator see simulator docs for details.</LI>
-</UL>
-<H2><A NAME="ss27.5">27.5 Debugger Commands.</A>
- </H2>
-
-<P>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 graphical user interfaces (like ddd, xxgdb or xemacs) existing
-for the GNU debugger.
-<H3>break [line | file:line | function | file:function] </H3>
-
-<P>Set breakpoint at specified line or function.
-<P>
-<PRE>
-sdcdb>break 100
-sdcdb>break foo.c:100
-sdcdb>break funcfoo
-sdcdb>break
- foo.c:funcfoo
-
-</PRE>
-<H3>clear [line | file:line | function | file:function ] </H3>
-
-<P>Clear breakpoint at specified line or function.
-<P>
-<PRE>
-sdcdb>clear 100
-sdcdb>clear foo.c:100
-sdcdb>clear funcfoo
-sdcdb>clear
- foo.c:funcfoo
-
-</PRE>
-<H3>continue </H3>
-
-<P>Continue program being debugged, after breakpoint.
-<H3>finish </H3>
-
-<P>Execute till the end of the current function.
-<H3>delete [n] </H3>
-
-<P>Delete breakpoint number 'n'. If used without any option clear ALL user
-defined break points.
-<H3>info [break | stack | frame | registers ] </H3>
-
-<P>
-<UL>
-<LI>info break - list all breakpoints</LI>
-<LI>info stack - show the function call stack.</LI>
-<LI>info frame - show information about the current execution frame.</LI>
-<LI>info registers - show content of all registers.</LI>
-</UL>
-<H3>step </H3>
-
-<P>Step program until it reaches a different source line.
-<H3>next </H3>
-
-<P>Step program, proceeding through subroutine calls.
-<H3>run </H3>
-
-<P>Start debugged program.
-<H3>ptype variable </H3>
-
-<P>Print type information of the variable.
-<H3>print variable </H3>
-
-<P>print value of variable.
-<H3>file filename </H3>
-
-<P>load the given file name. Note this is an alternate method of loading file
-for debugging.
-<H3>frame </H3>
-
-<P>print information about current frame.
-<H3>set srcmode </H3>
-
-<P>Toggle between C source & assembly source.
-<H3>! simulator command </H3>
-
-<P>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.
-<H3>quit. </H3>
-
-<P>"Watch me now. Iam going Down. My name is Bobby Brown"
-<H2><A NAME="ss27.6">27.6 Interfacing with XEmacs.</A>
- </H2>
-
-<P>Two files are (in emacs lisp) are provided for the interfacing with XEmacs,
-sdcdb.el and sdcdbsrc.el. These two files can be found in the $(prefix)/bin
-directory after the installation is complete. These files need to be loaded
-into XEmacs for the interface to work, this can be done at XEmacs startup time
-by inserting the following into your '.xemacs' file (which can be found in
-your HOME directory) (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 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.
-<P>The command line options that are passed to the simulator directly are
-bound to default values in the file sdcdbsrc.el the variables are listed below
-these values maybe changed as required.
-<P>
-<UL>
-<LI>sdcdbsrc-cpu-type '51</LI>
-<LI>sdcdbsrc-frequency '11059200</LI>
-<LI>sdcdbsrc-serial nil</LI>
-</UL>
-<P>The following is a list of key mapping for the debugger interface.
-<P>
-<PRE>
-
-;; Current Listing ::
-;;key binding Comment
-
-;;--- ------- -------
-;;
-;; n
- sdcdb-next-from-src SDCDB next command
-;; b sdcdb-back-from-src SDCDB
- back command
-;; c sdcdb-cont-from-src SDCDB continue
- command
-;; s sdcdb-step-from-src SDCDB step command
-
-;; ? sdcdb-whatis-c-sexp SDCDB ptypecommand for data
- at
-;; buffer point
-;; x
- sdcdbsrc-delete SDCDB Delete all breakpoints if no arg
-;; given
- or delete arg (C-u arg x)
-;; m sdcdbsrc-frame SDCDB
- Display current frame if no arg,
-;; given
- or display frame arg
-;; buffer
- point
-;; ! sdcdbsrc-goto-sdcdb Goto the SDCDB output
- buffer
-;; p sdcdb-print-c-sexp SDCDB print command
- for data at
-;; buffer point
-;;
- g sdcdbsrc-goto-sdcdb Goto the SDCDB output buffer
-;;
- t sdcdbsrc-mode Toggles Sdcdbsrc mode (turns it
- off)
-;;
-;; C-c C-f sdcdb-finish-from-src SDCDB finish command
-
-;;
-;; C-x SPC sdcdb-break Set break for line with
- point
-;; ESC t sdcdbsrc-mode Toggle Sdcdbsrc mode
-
-;; ESC m sdcdbsrc-srcmode Toggle list mode
-;;
-
-
-</PRE>
+<P>Shoot of an email to 'sandeep.dutta@usa.net', as a matter of principle
+I always reply to all email's sent to me. Bugs will be fixed ASAP. When reporting
+a bug , it is useful to include a small snippet of code that is causing the
+problem, if possible compile your program with the --dumpall option and send
+the dump files along with the bug report.
<HR>
<A HREF="SDCCUdoc-28.html">Next</A>
<A HREF="SDCCUdoc-26.html">Previous</A>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
- <TITLE>SDCC Compiler User Guide: Conclusion</TITLE>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
+ <TITLE>SDCC Compiler User Guide: SDCDB - Source level debugger.</TITLE>
<LINK HREF="SDCCUdoc-29.html" REL=next>
<LINK HREF="SDCCUdoc-27.html" REL=previous>
<LINK HREF="SDCCUdoc.html#toc28" REL=contents>
<A HREF="SDCCUdoc-27.html">Previous</A>
<A HREF="SDCCUdoc.html#toc28">Contents</A>
<HR>
-<H2><A NAME="Conclusion"></A> <A NAME="s28">28. Conclusion</A> </H2>
-
-<P>SDCC is a large project , the compiler alone (without the Assembler Package
-, Preprocessor & garbage collector) is about 40,000 lines of code (blank
-stripped). As with any project of this size there are bound to be bugs, I am
-more than willing to work to fix these bugs , of course all the source code
-is included with the package.
-<P>Where does it go from here ? I am planning to target the Atmel AVR 8-bit
-MCUs which seems to have a lot of users. I am also planning to include an alias
-analysis system with this compiler (it does not currently have one).
+<H2><A NAME="s28">28. SDCDB - Source level debugger.</A> </H2>
+
+<P>SDCC is distributed with a source level debugger. The debugger uses a command
+line interface, the command repertoire of the debugger has been kept as close
+to gdb ( the GNU debugger) as possible. The configuration and build process
+of the compiler see Installation
+<A HREF="SDCCUdoc-2.html#Installation"></A> also builds and installs the debugger in
+the target directory specified during configuration. The debugger allows you
+debug BOTH at the C source and at the ASM source level.
+<H2><A NAME="ss28.1">28.1 Compiling for debugging.</A>
+ </H2>
+
+<P>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 .
+<H2><A NAME="ss28.2">28.2 How the debugger works.</A>
+ </H2>
+
+<P>When the --debug option is specified the compiler generates extra symbol
+information some of which are put into the the assembler source and some are
+put into the .cdb file, the linker updates the .cdb file with the address information
+for the symbols. The debugger reads the symbolic information generated by the
+compiler & the address information generated by the linker. It uses the
+SIMULATOR (Daniel's S51) to execute the program, the program execution is controlled
+by the debugger. When a command is issued for the debugger, it translates it
+into appropriate commands for the simulator .
+<H2><A NAME="ss28.3">28.3 Starting the debugger.</A>
+ </H2>
+
+<P>The debugger can be started using the following command line. (Assume the
+file you are debugging has
+<P>the file name foo).
+<P>
+<PRE>
+>sdcdb foo
+
+</PRE>
+<P>The debugger will look for the following files.
+<P>
+<OL>
+<LI>foo.c - the source file.</LI>
+<LI>foo.cdb - the debugger symbol information file.</LI>
+<LI>foo.ihx - the intel hex format object file.</LI>
+</OL>
+<H2><A NAME="ss28.4">28.4 Command line options.</A>
+ </H2>
+
+<P>
+<UL>
+<LI>--directory=<source file directory> this option can used to specify
+the directory search list. The debugger will look into the directory list specified
+for source , cdb & ihx files. The items in the directory list must be separated
+by ':' , e.g. if the source files can be in the directories /home/src1 and
+/home/src2, the --directory option should be --directory=/home/src1:/home/src2
+. Note there can be no spaces in the option. </LI>
+<LI>-cd <directory> - change to the <directory>.</LI>
+<LI>-fullname - used by GUI front ends.</LI>
+<LI>-cpu <cpu-type> - this argument is passed to the simulator please
+see the simulator docs for details.</LI>
+<LI>-X <Clock frequency > this options is passed to the simulator please
+see simulator docs for details.</LI>
+<LI>-s <serial port file> passed to simulator see simulator docs for
+details.</LI>
+<LI>-S <serial in,out> passed to simulator see simulator docs for details.</LI>
+</UL>
+<H2><A NAME="ss28.5">28.5 Debugger Commands.</A>
+ </H2>
+
+<P>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 graphical user interfaces (like ddd, xxgdb or xemacs) existing
+for the GNU debugger.
+<H3>break [line | file:line | function | file:function] </H3>
+
+<P>Set breakpoint at specified line or function.
+<P>
+<PRE>
+sdcdb>break 100
+sdcdb>break foo.c:100
+sdcdb>break funcfoo
+sdcdb>break
+ foo.c:funcfoo
+
+</PRE>
+<H3>clear [line | file:line | function | file:function ] </H3>
+
+<P>Clear breakpoint at specified line or function.
+<P>
+<PRE>
+sdcdb>clear 100
+sdcdb>clear foo.c:100
+sdcdb>clear funcfoo
+sdcdb>clear
+ foo.c:funcfoo
+
+</PRE>
+<H3>continue </H3>
+
+<P>Continue program being debugged, after breakpoint.
+<H3>finish </H3>
+
+<P>Execute till the end of the current function.
+<H3>delete [n] </H3>
+
+<P>Delete breakpoint number 'n'. If used without any option clear ALL user
+defined break points.
+<H3>info [break | stack | frame | registers ] </H3>
+
+<P>
+<UL>
+<LI>info break - list all breakpoints</LI>
+<LI>info stack - show the function call stack.</LI>
+<LI>info frame - show information about the current execution frame.</LI>
+<LI>info registers - show content of all registers.</LI>
+</UL>
+<H3>step </H3>
+
+<P>Step program until it reaches a different source line.
+<H3>next </H3>
+
+<P>Step program, proceeding through subroutine calls.
+<H3>run </H3>
+
+<P>Start debugged program.
+<H3>ptype variable </H3>
+
+<P>Print type information of the variable.
+<H3>print variable </H3>
+
+<P>print value of variable.
+<H3>file filename </H3>
+
+<P>load the given file name. Note this is an alternate method of loading file
+for debugging.
+<H3>frame </H3>
+
+<P>print information about current frame.
+<H3>set srcmode </H3>
+
+<P>Toggle between C source & assembly source.
+<H3>! simulator command </H3>
+
+<P>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.
+<H3>quit. </H3>
+
+<P>"Watch me now. Iam going Down. My name is Bobby Brown"
+<H2><A NAME="ss28.6">28.6 Interfacing with XEmacs.</A>
+ </H2>
+
+<P>Two files are (in emacs lisp) are provided for the interfacing with XEmacs,
+sdcdb.el and sdcdbsrc.el. These two files can be found in the $(prefix)/bin
+directory after the installation is complete. These files need to be loaded
+into XEmacs for the interface to work, this can be done at XEmacs startup time
+by inserting the following into your '.xemacs' file (which can be found in
+your HOME directory) (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 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.
+<P>The command line options that are passed to the simulator directly are
+bound to default values in the file sdcdbsrc.el the variables are listed below
+these values maybe changed as required.
+<P>
+<UL>
+<LI>sdcdbsrc-cpu-type '51</LI>
+<LI>sdcdbsrc-frequency '11059200</LI>
+<LI>sdcdbsrc-serial nil</LI>
+</UL>
+<P>The following is a list of key mapping for the debugger interface.
+<P>
+<PRE>
+
+;; Current Listing ::
+;;key binding Comment
+
+;;--- ------- -------
+;;
+;; n
+ sdcdb-next-from-src SDCDB next command
+;; b sdcdb-back-from-src SDCDB
+ back command
+;; c sdcdb-cont-from-src SDCDB continue
+ command
+;; s sdcdb-step-from-src SDCDB step command
+
+;; ? sdcdb-whatis-c-sexp SDCDB ptypecommand for data
+ at
+;; buffer point
+;; x
+ sdcdbsrc-delete SDCDB Delete all breakpoints if no arg
+;; given
+ or delete arg (C-u arg x)
+;; m sdcdbsrc-frame SDCDB
+ Display current frame if no arg,
+;; given
+ or display frame arg
+;; buffer
+ point
+;; ! sdcdbsrc-goto-sdcdb Goto the SDCDB output
+ buffer
+;; p sdcdb-print-c-sexp SDCDB print command
+ for data at
+;; buffer point
+;;
+ g sdcdbsrc-goto-sdcdb Goto the SDCDB output buffer
+;;
+ t sdcdbsrc-mode Toggles Sdcdbsrc mode (turns it
+ off)
+;;
+;; C-c C-f sdcdb-finish-from-src SDCDB finish command
+
+;;
+;; C-x SPC sdcdb-break Set break for line with
+ point
+;; ESC t sdcdbsrc-mode Toggle Sdcdbsrc mode
+
+;; ESC m sdcdbsrc-srcmode Toggle list mode
+;;
+
+
+</PRE>
<HR>
<A HREF="SDCCUdoc-29.html">Next</A>
<A HREF="SDCCUdoc-27.html">Previous</A>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
- <TITLE>SDCC Compiler User Guide: Acknowledgments</TITLE>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
+ <TITLE>SDCC Compiler User Guide: Conclusion</TITLE>
+ <LINK HREF="SDCCUdoc-30.html" REL=next>
<LINK HREF="SDCCUdoc-28.html" REL=previous>
<LINK HREF="SDCCUdoc.html#toc29" REL=contents>
</HEAD>
<BODY>
-Next
+<A HREF="SDCCUdoc-30.html">Next</A>
<A HREF="SDCCUdoc-28.html">Previous</A>
<A HREF="SDCCUdoc.html#toc29">Contents</A>
<HR>
-<H2><A NAME="Acknowledgements"></A> <A NAME="s29">29. Acknowledgments</A> </H2>
+<H2><A NAME="Conclusion"></A> <A NAME="s29">29. Conclusion</A> </H2>
-<P>Alan Baldwin (baldwin@shop-pdp.kent.edu) - Initial version of ASXXXX &
-ASLINK.
-<P>John Hartman (jhartman@compuserve.com) - Porting ASXXX & ASLINK for
-8051
-<P>Dmitry S. Obukhov (dso@usa.net) - malloc & serial i/o routines.
-<P>Daniel Drotos <drdani@mazsola.iit.uni-miskolc.hu> - for his Freeware
-simulator
-<P>Jans J Boehm(boehm@sgi.com) and Alan J Demers - Conservative garbage collector
-for C & C++.
-<P>Malini Dutta(malini_dutta@hotmail.com) - my wife for her patience and support.
-<P>Unknown - for the GNU C - preprocessor.
-<P>
+<P>SDCC is a large project , the compiler alone (without the Assembler Package
+, Preprocessor & garbage collector) is about 40,000 lines of code (blank
+stripped). As with any project of this size there are bound to be bugs, I am
+more than willing to work to fix these bugs , of course all the source code
+is included with the package.
+<P>Where does it go from here ? I am planning to target the Atmel AVR 8-bit
+MCUs which seems to have a lot of users. I am also planning to include an alias
+analysis system with this compiler (it does not currently have one).
<HR>
-Next
+<A HREF="SDCCUdoc-30.html">Next</A>
<A HREF="SDCCUdoc-28.html">Previous</A>
<A HREF="SDCCUdoc.html#toc29">Contents</A>
</BODY>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
<TITLE>SDCC Compiler User Guide: Compiling.</TITLE>
<LINK HREF="SDCCUdoc-4.html" REL=next>
<LINK HREF="SDCCUdoc-2.html" REL=previous>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
<TITLE>SDCC Compiler User Guide: Command Line options</TITLE>
<LINK HREF="SDCCUdoc-5.html" REL=next>
<LINK HREF="SDCCUdoc-3.html" REL=previous>
<LI><B>--model-small</B>
<A NAME="--model-small"></A> Generate code for Small Model programs see section Memory
Models for more details. This is the default model.</LI>
+<LI><B>--model-flat24</B>
+<A HREF="SDCCUdoc-17.html#--model-flat24">--model-flat24</A>Generate code for Small Model programs see section Memory
+Models for more details. This is the default model.</LI>
<LI><B>--stack-auto</B>
<A NAME="--stack-auto"></A> All functions in the source file will be compiled as reentrant,
i.e. the parameters and local variables will be allocated on the stack. see
option. If the project consists of multiple source files then all the source
file should be compiled with the same --callee-saves option string. Also see
Pragma Directive
-<A HREF="SDCCUdoc-18.html#Pragmaa"></A> CALLEE-SAVES.
-<A HREF="SDCCUdoc-18.html#pragma callee-saves"></A> .</LI>
+<A HREF="SDCCUdoc-19.html#Pragmaa"></A> CALLEE-SAVES.
+<A HREF="SDCCUdoc-19.html#pragma callee-saves"></A> .</LI>
<LI><B>--debug </B>
<A NAME="--debug"></A> When this option is used the compiler will generate debug information
, that can be used with the SDCDB. The debug information is collected in a
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
<TITLE>SDCC Compiler User Guide: Language Extensions</TITLE>
<LINK HREF="SDCCUdoc-6.html" REL=next>
<LINK HREF="SDCCUdoc-4.html" REL=previous>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
<TITLE>SDCC Compiler User Guide: Optimizations</TITLE>
<LINK HREF="SDCCUdoc-7.html" REL=next>
<LINK HREF="SDCCUdoc-5.html" REL=previous>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
<TITLE>SDCC Compiler User Guide: Pointers</TITLE>
<LINK HREF="SDCCUdoc-8.html" REL=next>
<LINK HREF="SDCCUdoc-6.html" REL=previous>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
<TITLE>SDCC Compiler User Guide: Parameters & Local Variables</TITLE>
<LINK HREF="SDCCUdoc-9.html" REL=next>
<LINK HREF="SDCCUdoc-7.html" REL=previous>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
<TITLE>SDCC Compiler User Guide: critical Functions.</TITLE>
<LINK HREF="SDCCUdoc-10.html" REL=next>
<LINK HREF="SDCCUdoc-8.html" REL=previous>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
<TITLE>SDCC Compiler User Guide</TITLE>
<LINK HREF="SDCCUdoc-1.html" REL=next>
<H2><A NAME="toc16">16.</A> <A HREF="SDCCUdoc-16.html">Memory Models</A></H2>
<P>
-<H2><A NAME="toc17">17.</A> <A HREF="SDCCUdoc-17.html">Defines created by the compiler.</A></H2>
+<H2><A NAME="toc17">17.</A> <A HREF="SDCCUdoc-17.html">Flat 24 bit addressing model.</A></H2>
<P>
-<H2><A NAME="toc18">18.</A> <A HREF="SDCCUdoc-18.html">Pragmas</A></H2>
+<H2><A NAME="toc18">18.</A> <A HREF="SDCCUdoc-18.html">Defines created by the compiler.</A></H2>
<P>
-<H2><A NAME="toc19">19.</A> <A HREF="SDCCUdoc-19.html">Library routines.</A></H2>
+<H2><A NAME="toc19">19.</A> <A HREF="SDCCUdoc-19.html">Pragmas</A></H2>
+
+<P>
+<H2><A NAME="toc20">20.</A> <A HREF="SDCCUdoc-20.html">Library routines.</A></H2>
<P>
<PRE>
<P>Have not had time to do the more involved routines like printf, will get
to them shortly.
<P>
-<H2><A NAME="toc20">20.</A> <A HREF="SDCCUdoc-20.html">Interfacing with assembly routines.</A></H2>
+<H2><A NAME="toc21">21.</A> <A HREF="SDCCUdoc-21.html">Interfacing with assembly routines.</A></H2>
<UL>
-<LI><A HREF="SDCCUdoc-20.html#ss20.1">20.1 Global registers used for parameter passing.</A>
-<LI><A HREF="SDCCUdoc-20.html#ss20.2">20.2 With --noregparms option.</A>
+<LI><A HREF="SDCCUdoc-21.html#ss21.1">21.1 Global registers used for parameter passing.</A>
+<LI><A HREF="SDCCUdoc-21.html#ss21.2">21.2 With --noregparms option.</A>
<P>
-<H2><A NAME="toc21">21.</A> <A HREF="SDCCUdoc-21.html">External Stack.</A></H2>
+<H2><A NAME="toc22">22.</A> <A HREF="SDCCUdoc-22.html">External Stack.</A></H2>
<P>
-<H2><A NAME="toc22">22.</A> <A HREF="SDCCUdoc-22.html">ANSI-Compliance.</A></H2>
+<H2><A NAME="toc23">23.</A> <A HREF="SDCCUdoc-23.html">ANSI-Compliance.</A></H2>
<P>
-<H2><A NAME="toc23">23.</A> <A HREF="SDCCUdoc-23.html">Cyclomatic Complexity</A></H2>
+<H2><A NAME="toc24">24.</A> <A HREF="SDCCUdoc-24.html">Cyclomatic Complexity</A></H2>
<P>
-<H2><A NAME="toc24">24.</A> <A HREF="SDCCUdoc-24.html">TIPS</A></H2>
+<H2><A NAME="toc25">25.</A> <A HREF="SDCCUdoc-25.html">TIPS</A></H2>
<P>
-<H2><A NAME="toc25">25.</A> <A HREF="SDCCUdoc-25.html">Retargetting for other MCUs.</A></H2>
+<H2><A NAME="toc26">26.</A> <A HREF="SDCCUdoc-26.html">Retargetting for other MCUs.</A></H2>
<P>
-<H2><A NAME="toc26">26.</A> <A HREF="SDCCUdoc-26.html">Reporting Bugs</A></H2>
+<H2><A NAME="toc27">27.</A> <A HREF="SDCCUdoc-27.html">Reporting Bugs</A></H2>
<P>
-<H2><A NAME="toc27">27.</A> <A HREF="SDCCUdoc-27.html">SDCDB - Source level debugger.</A></H2>
+<H2><A NAME="toc28">28.</A> <A HREF="SDCCUdoc-28.html">SDCDB - Source level debugger.</A></H2>
<UL>
-<LI><A HREF="SDCCUdoc-27.html#ss27.1">27.1 Compiling for debugging.</A>
-<LI><A HREF="SDCCUdoc-27.html#ss27.2">27.2 How the debugger works.</A>
-<LI><A HREF="SDCCUdoc-27.html#ss27.3">27.3 Starting the debugger.</A>
-<LI><A HREF="SDCCUdoc-27.html#ss27.4">27.4 Command line options.</A>
-<LI><A HREF="SDCCUdoc-27.html#ss27.5">27.5 Debugger Commands.</A>
-<LI><A HREF="SDCCUdoc-27.html#ss27.6">27.6 Interfacing with XEmacs.</A>
+<LI><A HREF="SDCCUdoc-28.html#ss28.1">28.1 Compiling for debugging.</A>
+<LI><A HREF="SDCCUdoc-28.html#ss28.2">28.2 How the debugger works.</A>
+<LI><A HREF="SDCCUdoc-28.html#ss28.3">28.3 Starting the debugger.</A>
+<LI><A HREF="SDCCUdoc-28.html#ss28.4">28.4 Command line options.</A>
+<LI><A HREF="SDCCUdoc-28.html#ss28.5">28.5 Debugger Commands.</A>
+<LI><A HREF="SDCCUdoc-28.html#ss28.6">28.6 Interfacing with XEmacs.</A>
+<P>
+<H2><A NAME="toc29">29.</A> <A HREF="SDCCUdoc-29.html">Conclusion</A></H2>
+
<P>
-<H2><A NAME="toc28">28.</A> <A HREF="SDCCUdoc-28.html">Conclusion</A></H2>
+<H2><A NAME="toc30">30.</A> <A HREF="SDCCUdoc-30.html">Acknowledgments</A></H2>
<P>
-<H2><A NAME="toc29">29.</A> <A HREF="SDCCUdoc-29.html">Acknowledgments</A></H2>
+<H2><A NAME="toc31">31.</A> <A HREF="SDCCUdoc-31.html">Appendix A: The Z80 and gbz80 port</A></H2>
<HR>
<A HREF="SDCCUdoc-1.html">Next</A>
-#LyX 1.1 created this file. For more info see http://www.lyx.org/
+#This file was created by <sandeep> Sun Mar 26 12:40:23 2000
+#LyX 1.0 (C) 1995-1999 Matthias Ettrich and the LyX Team
\lyxformat 2.15
\textclass linuxdoc
\language english
\layout Itemize
+\series bold
+\size large
+\bar under
+--model-flat24
+\series default
+\emph on
+\bar default
+
+\size default
+\emph default
+
+\begin_inset LatexCommand \ref[--model-flat24]{--model-flat24}
+
+\end_inset
+
+Generate code for Small Model programs see section Memory Models for more
+ details.
+ This is the default model.
+\layout Itemize
+
+
\series bold
\size large
\bar under
overflow.
For serious floating point usage it is strongly recommended that the Large
model be used (in which case the floating point routines mentioned above
- will need to recompiled with the --model-Large option).
+ will need to recompiled with the --model-Large option)
\layout Section
Memory Models
be used unless absolutely required.
\layout Section
+Flat 24 bit addressing model.
+\begin_inset LatexCommand \label{--model-flat24}
+
+\end_inset
+
+
+\layout Standard
+
+This option generates code for the 24 bit contiguous addressing mode of
+ the Dallas DS80C390 part.
+ In this mode, up to four meg of external RAM or code space can be directly
+ addressed.
+ See the data sheets at www.dalsemi.com for further information on this part.
+\layout Standard
+
+Note that the compiler does not generate any code to place the processor
+ into this mode (it defaults to 8051 compatible mode).
+ Boot loader or similar code must ensure that the processor is in 24 bit
+ contiguous addressing mode before calling the SDCC startup code.
+\layout Standard
+
+Like the --model-large option, variables will by default be placed into
+ the XDATA segment.
+ However, a current limitation is that the compiler will spill variables
+ into the DATA segment when it runs out of registers.
+ This means that compiling complex code can rapidly fill up the DATA segment.
+ This limitation is being worked on, and should be addressed in the next
+ release of sdcc.
+\layout Standard
+
+Segments may be placed anywhere in the 4 meg address space using the usual
+ --*-loc options.
+ Note that if any segments are located above 64K, the -r flag must be passed
+ to the linker to generate the proper segment relocations, and the Intel
+ HEX output format must be used.
+ The -r flag can be passed to the linker by using the option -Wl-r on the
+ sdcc command line.
+\layout Standard
+
+--stack-10bit:
+\layout Standard
+
+This option generates code for the 10 bit stack mode of the Dallas DS80C390
+ part.
+ In this mode, the stack is located in the lower 1K of the internal RAM,
+ which is mapped to 0x400000.
+\layout Standard
+
+With this option, sdcc will generate the proper addressing for stack variables.
+\layout Standard
+
+Note that the support is incomplete, since it still uses a single byte as
+ the stack pointer.
+ This means that only the lower 256 bytes of the potential 1K stack space
+ can actually be used.
+ However, this does allow you to reclaim the precious 256 bytes of low RAM
+ for use for the DATA and IDATA segments.
+\layout Standard
+
+The compiler will not generate any code to put the processor into 10 bit
+ stack mode.
+ It is important to ensure that the processor is in this mode before calling
+ any re-entrant functions compiled with this option.
+\layout Standard
+
+In principle, this should work with the --stack-auto option, but that has
+ not been tested.
+ It is incompatible with the --xstack option.
+ It also only makes sense if the processor is in 24 bit contiguous addressing
+ mode (see the --model-flat24 option).
+\layout Section
+
Defines created by the compiler.
\begin_inset LatexCommand \label{Defines.}
\layout Standard
-\begin_inset LatexCommand \index{}
+\begin_inset LatexCommand \index
\end_inset
<!doctype linuxdoc system>
-<!-- LinuxDoc file was created by LyX 1.0 (C) 1995-1999 by <sandeep> Thu Oct 14 02:37:55 1999
+<!-- LinuxDoc file was created by LyX 1.0 (C) 1995-1999 by <sandeep> Sun Mar 26 12:40:33 2000
-->
<linuxdoc>
should be compiled with this option. In addition the standard library routines
are compiled with small model , they will need to be recompiled.
<item><bf>--model-small</bf> <label id="--model-small" >Generate code for Small Model programs see section Memory
+ Models for more details. This is the default model.
+ <item><bf>--model-flat24</bf> <ref id="--model-flat24" name="--model-flat24" >Generate code for Small Model programs see section Memory
Models for more details. This is the default model.
<item><bf>--stack-auto</bf> <label id="--stack-auto" >All functions in the source file will be compiled as reentrant,
i.e. the parameters and local variables will be allocated on the stack. see
<p>Note if all these routines are used simultaneously the data space might
overflow. For serious floating point usage it is strongly recommended that
the Large model be used (in which case the floating point routines mentioned
- above will need to recompiled with the --model-Large option).
+ above will need to recompiled with the --model-Large option)
</p>
<sect>Memory Models<label id="Memory Models" >
<p>SDCC allows two memory models, modules compiled with different memory models
model, it is therefore strongly recommdended that the small model be used unless
absolutely required.
</p>
+ <sect>Flat 24 bit addressing model.<label id="--model-flat24" >
+ <p>This option generates code for the 24 bit contiguous addressing mode of
+ the Dallas DS80C390 part. In this mode, up to four meg of external RAM or code
+ space can be directly addressed. See the data sheets at www.dalsemi.com for
+ further information on this part.
+ </p>
+ <p>Note that the compiler does not generate any code to place the processor
+ into this mode (it defaults to 8051 compatible mode). Boot loader or similar
+ code must ensure that the processor is in 24 bit contiguous addressing mode
+ before calling the SDCC startup code.
+ </p>
+ <p>Like the --model-large option, variables will by default be placed into
+ the XDATA segment. However, a current limitation is that the compiler will
+ spill variables into the DATA segment when it runs out of registers. This means
+ that compiling complex code can rapidly fill up the DATA segment. This limitation
+ is being worked on, and should be addressed in the next release of sdcc.
+ </p>
+ <p>Segments may be placed anywhere in the 4 meg address space using the usual
+ --*-loc options. Note that if any segments are located above 64K, the -r flag
+ must be passed to the linker to generate the proper segment relocations, and
+ the Intel HEX output format must be used. The -r flag can be passed to the
+ linker by using the option -Wl-r on the sdcc command line.
+ </p>
+ <p>--stack-10bit:
+ </p>
+ <p>This option generates code for the 10 bit stack mode of the Dallas DS80C390
+ part. In this mode, the stack is located in the lower 1K of the internal RAM,
+ which is mapped to 0x400000.
+ </p>
+ <p>With this option, sdcc will generate the proper addressing for stack variables.
+ </p>
+ <p>Note that the support is incomplete, since it still uses a single byte
+ as the stack pointer. This means that only the lower 256 bytes of the potential
+ 1K stack space can actually be used. However, this does allow you to reclaim
+ the precious 256 bytes of low RAM for use for the DATA and IDATA segments.
+ </p>
+ <p>The compiler will not generate any code to put the processor into 10 bit
+ stack mode. It is important to ensure that the processor is in this mode before
+ calling any re-entrant functions compiled with this option.
+ </p>
+ <p>In principle, this should work with the --stack-auto option, but that has
+ not been tested. It is incompatible with the --xstack option. It also only
+ makes sense if the processor is in 24 bit contiguous addressing mode (see the
+ --model-flat24 option).
+ </p>
<sect>Defines created by the compiler.<label id="Defines." >
<p>The compiler creates the following #defines .
</p>
</p>
<p>Unknown - for the GNU C - preprocessor.
</p>
+ <sect>Appendix A: The Z80 and gbz80 port
+ <p>2.2.0 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.
+ </p>
+ <p>As always, the code is the authoritave reference - see z80/ralloc.c and
+ z80/gen.c. The stack frame is similar to that generated by the IAR Z80 compiler.
+ IX is used as the base pointer, HL is used as a temporary register, and BC
+ and DE are available for holding varibles. IY is currently unusued. Return
+ values are stored in HL. One bad side effect of using IX as the base pointer
+ is that a functions stack frame is limited to 127 bytes - this will be fixed
+ in a later version.bc
+ </p>
+ <p>9
+ </p>
<p>
</p>
projects / fw / sdcc / commitdiff