+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
- <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>
- <LINK HREF="SDCCUdoc.html#toc10" REL=contents>
-</HEAD>
-<BODY>
-<A HREF="SDCCUdoc-11.html">Next</A>
-<A HREF="SDCCUdoc-9.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc10">Contents</A>
-<HR>
-<H2><A NAME="Absolute Addressing"></A> <A NAME="s10">10. Absolute addressing.</A> </H2>
-
-<P>Data items can be assigned an absolute address with the at <address>
-keyword, in addition to a storage class.
-<P>
-<PRE>
-eg. xdata at 0x8000 unsigned char PORTA_8255 ;
-
-</PRE>
-<P>In the above example the PORTA_8255 will be allocated to the location 0x8000
-of the external ram.
-<P>Note that is this feature is provided to give the programmer access to
-memory mapped devices attached to the controller. The compiler does not actually
-reserve any space for variables declared in this way (they are implemented
-with an equate in the assembler), thus it is left to the programmer to make
-sure there are no overlaps with other variables that are declared without the
-absolute address, the assembler listing file (.lst) and the linker output files
-(<filename>.rst) and (<filename>.map) are a good places to look
-for such overlaps.
-<P>Absolute address can be specified for variables in all storage classes.
-<P>
-<PRE>
-eg.bit at 0x02 bvar;
-
-</PRE>
-<P>The above example will allocate the variable at offset 0x02 in the bit-addressable
-space. There is no real advantage to assigning absolute addresses to variables
-in this manner , unless you want strict control over all the variables allocated.
-<HR>
-<A HREF="SDCCUdoc-11.html">Next</A>
-<A HREF="SDCCUdoc-9.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc10">Contents</A>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
- <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>
- <LINK HREF="SDCCUdoc.html#toc11" REL=contents>
-</HEAD>
-<BODY>
-<A HREF="SDCCUdoc-12.html">Next</A>
-<A HREF="SDCCUdoc-10.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc11">Contents</A>
-<HR>
-<H2><A NAME="Interrupt Service Rouines"></A> <A NAME="s11">11. Interrupt Service Routines</A> </H2>
-
-<P>SDCC allows interrupt service routines to be coded in C, with some extended
-keywords.
-<P>
-<PRE>
-void timer_isr (void) interrupt 2 using 1
-{
-..
-}
-
-</PRE>
-<P>The number following the 'interrupt' keyword is the interrupt number this
-routine will service. The compiler will insert a call to this routine in the
-interrupt vector table for the interrupt number specified. The 'using' keyword
-is used to tell the compiler to use the specified register bank (8051 specific)
-when generating code for this function. Note that when some function is called
-from an interrupt service routine it should be preceded by a #pragma NOOVERLAY
-(if it is not reentrant) . A special note here, int (16 bit) and long (32 bit)
-integer division, multiplication & modulus operations are implemented using
-external support routines developed in ANSI-C, if an interrupt service routine
-needs to do any of these operations then the support routines (as mentioned
-in a following section) will have to recompiled using the --stack-auto option
-and the source file will need to be compiled using the --int-long-rent compiler
-option.
-<P>If you have multiple source files in your project, interrupt service routines
-can be present in any of them, but a prototype of the isr MUST be present in
-the file that contains the function 'main'.
-<P>Interrupt Numbers and the corresponding address & descriptions for
-the Standard 8051 are listed below. SDCC will automatically adjust the interrupt
-vector table to the maximum interrupt number specified.
-<P>
-<PRE>
-Interrupt # Description Vector Address
- 0 External
- 0 0x0003
- 1 Timer 0 0x000B
- 2
- External 1 0x0013
- 3 Timer 1 0x001B
-
- 4 Serial 0x0023
-
-</PRE>
-<P>If the interrupt service routine is defined without a register bank or
-with register bank 0 (using 0), the compiler will save the registers used by
-itself on the stack (upon entry and restore them at exit), however if such
-an interrupt service routine calls another function then the entire register
-bank will be saved on the stack. This scheme may be advantageous for small
-interrupt service routines which have low register usage.
-<P>If the interrupt service routine is defined to be using a specific register
-bank then only "a","b" & "dptr" are save and restored, if such an interrupt service
-routine calls another function (using another register bank) then the entire
-register bank of the called function will be saved on the stack. This scheme
-is recommended for larger interrupt service routines.
-<P>Calling other functions from an interrupt service routine is not recommended
-avoid it if possible.
-<HR>
-<A HREF="SDCCUdoc-12.html">Next</A>
-<A HREF="SDCCUdoc-10.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc11">Contents</A>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
- <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>
- <LINK HREF="SDCCUdoc.html#toc12" REL=contents>
-</HEAD>
-<BODY>
-<A HREF="SDCCUdoc-13.html">Next</A>
-<A HREF="SDCCUdoc-11.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc12">Contents</A>
-<HR>
-<H2><A NAME="Startup"></A> <A NAME="s12">12. Startup Code</A> </H2>
-
-<P>The compiler inserts a jump to the C routine <B>_sdcc__external__startup()</B>at the start of the CODE area. This routine can be found in the file <B>SDCCDIR/sdcc51lib/_startup.c</B>
-, by default this routine returns 0, if this routine returns a non-zero value
-, the static & global variable initialization will be skipped and the function
-main will be invoked, other wise static & global variables will be initialized
-before the function main is invoked.
-<HR>
-<A HREF="SDCCUdoc-13.html">Next</A>
-<A HREF="SDCCUdoc-11.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc12">Contents</A>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
- <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>
- <LINK HREF="SDCCUdoc.html#toc13" REL=contents>
-</HEAD>
-<BODY>
-<A HREF="SDCCUdoc-14.html">Next</A>
-<A HREF="SDCCUdoc-12.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc13">Contents</A>
-<HR>
-<H2><A NAME="Inline"></A> <A NAME="s13">13. Inline assembler code.</A> </H2>
-
-<P>SDCC allows the use of in-line assembler with a few restriction as regards
-labels. All labels defined within inline assembler code HAS TO BE of the form
-nnnnn$ where nnnn is a number less than 100 (which implies a limit of
-utmost 100 inline assembler labels per function). It is strongly recommended
-that each assembly instruction (including labels) be placed in a separate line
-( as the example shows). When the <B>--peep-asm</B> command line option is used, the
-inline assembler code will be passed through the peephole optimizer, this might
-cause some unexpected changes in the inline assembler code, please go throught
-the peephole optimizer rules defined in file 'SDCCpeeph.def' carefully before
-using this option.
-<P>
-<PRE>
-eg_asm
- mov b,#10
-00001$:
- djnz b,00001$
-
-_endasm ;
-
-</PRE>
-<P>The inline assembler code can contain any valid code understood by the
-assembler (this includes any assembler directives and comment lines ) . The
-compiler does not do any validation of the code within the _asm ... _endasm;
-keyword pair.
-<P>Inline assembler code cannot reference any C-Labels however it can reference
-labels defined by the inline assembler.
-<P>
-<PRE>
-egfoo() {
-... /* some c code */
-_asm
- ; some assembler code
-
- ljmp $0003
-_endasm ;
-... /* some more c code */
-clabel: /* inline
- assembler cannot reference this label */
-_asm
- $0003: ;label (can
- be reference by inline assembler only)
-_endasm ;
-...
-}
-
-</PRE>
-<P>In other words inline assembly code can access labels defined in inline
-assembly. The same goes the other way, ie. labels defines in inline assembly
-CANNOT be accessed by C statements.
-<HR>
-<A HREF="SDCCUdoc-14.html">Next</A>
-<A HREF="SDCCUdoc-12.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc13">Contents</A>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
- <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>
- <LINK HREF="SDCCUdoc.html#toc14" REL=contents>
-</HEAD>
-<BODY>
-<A HREF="SDCCUdoc-15.html">Next</A>
-<A HREF="SDCCUdoc-13.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc14">Contents</A>
-<HR>
-<H2><A NAME="int and long"></A> <A NAME="s14">14. int (16 bit) and long (32 bit ) support.</A> </H2>
-
-<P>For signed & unsigned int (16 bit) and long (32 bit) variables, division,
-multiplication and modulus operations are implemented by support routines.
-These support routines are all developed in ANSI-C to facilitate porting to
-other MCUs. The following files contain the described routine, all of them
-can be found in the directory SDCCDIR/sdcc51lib
-<P>
-<UL>
-<LI>_mulsint.c - signed 16 bit multiplication (calls _muluint)</LI>
-<LI>_muluint.c - unsigned 16 bit multiplication</LI>
-<LI>_divsint.c - signed 16 bit division (calls _divuint)</LI>
-<LI>_divuint.c - unsigned 16 bit division.</LI>
-<LI>_modsint.c - signed 16 bit modulus (call _moduint)</LI>
-<LI>_moduint.c - unsigned 16 bit modulus.</LI>
-<LI>_mulslong.c - signed 32 bit multiplication (calls _mululong)</LI>
-<LI>_mululong.c - unsigned32 bit multiplication.</LI>
-<LI>_divslong.c - signed 32 division (calls _divulong)</LI>
-<LI>_divulong.c - unsigned 32 division.</LI>
-<LI>_modslong.c - signed 32 bit modulus (calls _modulong).</LI>
-<LI>_modulong.c - unsigned 32 bit modulus.</LI>
-</UL>
-<P>All these routines are compiled as non-reentrant and small model. Since
-they are compiled as non-reentrant, interrupt service routines should not do
-any of the above operations, if this unavoidable then the above routines will
-need to ne compiled with the --stack-auto option, after which the source program
-will have to be compiled with --int-long-rent option.
-<HR>
-<A HREF="SDCCUdoc-15.html">Next</A>
-<A HREF="SDCCUdoc-13.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc14">Contents</A>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
- <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>
- <LINK HREF="SDCCUdoc.html#toc15" REL=contents>
-</HEAD>
-<BODY>
-<A HREF="SDCCUdoc-16.html">Next</A>
-<A HREF="SDCCUdoc-14.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc15">Contents</A>
-<HR>
-<H2><A NAME="Float"></A> <A NAME="s15">15. Floating point support</A> </H2>
-
-<P>SDCC supports IEEE (single precision 4bytes) floating point numbers.The
-floating point support routines are derived from gcc's floatlib.c and consists
-of the following routines.
-<P>
-<UL>
-<LI>_fsadd.c - add floating point numbers.</LI>
-<LI>_fssub.c - subtract floating point numbers</LI>
-<LI>_fsdiv.c - divide floating point numbers</LI>
-<LI>_fsmul.c - multiply floating point numbers</LI>
-<LI>_fs2uchar.c - convert floating point to unsigned char</LI>
-<LI>_fs2char.c - convert floating point to signed char.</LI>
-<LI>_fs2uint.c - convert floating point to unsigned int.</LI>
-<LI>_fs2int.c - convert floating point to signed int.</LI>
-<LI>_fs2ulong.c - convert floating point to unsigned long.</LI>
-<LI>_fs2long.c - convert floating point to signed long.</LI>
-<LI>_uchar2fs.c - convert unsigned char to floating point</LI>
-<LI>_char2fs.c - convert char to floating point number</LI>
-<LI>_uint2fs.c - convert unsigned int to floating point</LI>
-<LI>_int2fs.c - convert int to floating point numbers</LI>
-<LI>_ulong2fs.c - convert unsigned long to floating point number</LI>
-<LI>_long2fs.c - convert long to floating point number.</LI>
-</UL>
-<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)
-<HR>
-<A HREF="SDCCUdoc-16.html">Next</A>
-<A HREF="SDCCUdoc-14.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc15">Contents</A>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
- <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>
- <LINK HREF="SDCCUdoc.html#toc16" REL=contents>
-</HEAD>
-<BODY>
-<A HREF="SDCCUdoc-17.html">Next</A>
-<A HREF="SDCCUdoc-15.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc16">Contents</A>
-<HR>
-<H2><A NAME="Memory Models"></A> <A NAME="s16">16. Memory Models</A> </H2>
-
-<P>SDCC allows two memory models, modules compiled with different memory models
-should be combined together, the results would be unpredictable. The support
-routines supplied with the compiler are compiled in small-model by default,
-and will need to be recompiled using the large model if the large model is
-used. In general the use of the large model is discouraged.
-<P>When the large model is used all variables declared without a storage class
-will be allocated into the external ram, this includes all parameters and local
-variables (for non-reentrant functions). When the small model is used variables
-without storage class are allocated in the internal ram.
-<P>Judicious usage of the processor specific storage classes and the 'reentrant'
-function type will yield much more efficient code, than using the large-model.
-Several optimizations are disabled when the program is compiled using the large
-model, it is therefore strongly recommdended that the small model be used unless
-absolutely required.
-<HR>
-<A HREF="SDCCUdoc-17.html">Next</A>
-<A HREF="SDCCUdoc-15.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc16">Contents</A>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
- <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>
-</HEAD>
-<BODY>
-<A HREF="SDCCUdoc-18.html">Next</A>
-<A HREF="SDCCUdoc-16.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc17">Contents</A>
-<HR>
-<H2><A NAME="--model-flat24"></A> <A NAME="s17">17. Flat 24 bit addressing model.</A> </H2>
-
-<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>
-<A HREF="SDCCUdoc.html#toc17">Contents</A>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
- <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>
-</HEAD>
-<BODY>
-<A HREF="SDCCUdoc-19.html">Next</A>
-<A HREF="SDCCUdoc-17.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc18">Contents</A>
-<HR>
-<H2><A NAME="Defines."></A> <A NAME="s18">18. Defines created by the compiler.</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>
-<HR>
-<A HREF="SDCCUdoc-19.html">Next</A>
-<A HREF="SDCCUdoc-17.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc18">Contents</A>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
- <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>
-</HEAD>
-<BODY>
-<A HREF="SDCCUdoc-20.html">Next</A>
-<A HREF="SDCCUdoc-18.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc19">Contents</A>
-<HR>
-<H2><A NAME="Pragmaa"></A> <A NAME="s19">19. Pragmas</A> </H2>
-
-<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>
-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>
-<A HREF="SDCCUdoc.html#toc19">Contents</A>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
- <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>
-</HEAD>
-<BODY>
-<A HREF="SDCCUdoc-21.html">Next</A>
-<A HREF="SDCCUdoc-19.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc20">Contents</A>
-<HR>
-<H2><A NAME="Library"></A> <A NAME="s20">20. Library routines.</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>
-<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.
-
-</PRE>
-<HR>
-<A HREF="SDCCUdoc-21.html">Next</A>
-<A HREF="SDCCUdoc-19.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc20">Contents</A>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
- <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>
-</HEAD>
-<BODY>
-<A HREF="SDCCUdoc-22.html">Next</A>
-<A HREF="SDCCUdoc-20.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc21">Contents</A>
-<HR>
-<H2><A NAME="Interface_asm"></A> <A NAME="s21">21. Interfacing with assembly routines.</A> </H2>
-
-<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>
-<A HREF="SDCCUdoc.html#toc21">Contents</A>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
- <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>
-</HEAD>
-<BODY>
-<A HREF="SDCCUdoc-23.html">Next</A>
-<A HREF="SDCCUdoc-21.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc22">Contents</A>
-<HR>
-<H2><A NAME="xstack"></A> <A NAME="s22">22. External Stack.</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.
-<HR>
-<A HREF="SDCCUdoc-23.html">Next</A>
-<A HREF="SDCCUdoc-21.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc22">Contents</A>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
- <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>
-</HEAD>
-<BODY>
-<A HREF="SDCCUdoc-24.html">Next</A>
-<A HREF="SDCCUdoc-22.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc23">Contents</A>
-<HR>
-<H2><A NAME="ANSI_Compliance"></A> <A NAME="s23">23. ANSI-Compliance.</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>
-<HR>
-<A HREF="SDCCUdoc-24.html">Next</A>
-<A HREF="SDCCUdoc-22.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc23">Contents</A>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
- <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>
-</HEAD>
-<BODY>
-<A HREF="SDCCUdoc-25.html">Next</A>
-<A HREF="SDCCUdoc-23.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc24">Contents</A>
-<HR>
-<H2><A NAME="Cyclomatic"></A> <A NAME="s24">24. Cyclomatic Complexity</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>
-<PRE>
-complexity = (number of edges in control flow graph) -
- (number
- of nodes in control flow graph) + 2;
-
-</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-25.html">Next</A>
-<A HREF="SDCCUdoc-23.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc24">Contents</A>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
- <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>
-</HEAD>
-<BODY>
-<A HREF="SDCCUdoc-26.html">Next</A>
-<A HREF="SDCCUdoc-24.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc25">Contents</A>
-<HR>
-<H2><A NAME="Tips"></A> <A NAME="s25">25. TIPS</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>
-<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 ;
- ....
-}
-
-</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.
-<HR>
-<A HREF="SDCCUdoc-26.html">Next</A>
-<A HREF="SDCCUdoc-24.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc25">Contents</A>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
- <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>
-</HEAD>
-<BODY>
-<A HREF="SDCCUdoc-27.html">Next</A>
-<A HREF="SDCCUdoc-25.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc26">Contents</A>
-<HR>
-<H2><A NAME="Retargetting"></A> <A NAME="s26">26. Retargetting for other MCUs.</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>
-<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>
-<A HREF="SDCCUdoc.html#toc26">Contents</A>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
- <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>
-</HEAD>
-<BODY>
-<A HREF="SDCCUdoc-28.html">Next</A>
-<A HREF="SDCCUdoc-26.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc27">Contents</A>
-<HR>
-<H2><A NAME="Bugs"></A> <A NAME="s27">27. Reporting Bugs</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.
-<HR>
-<A HREF="SDCCUdoc-28.html">Next</A>
-<A HREF="SDCCUdoc-26.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc27">Contents</A>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
- <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>
-</HEAD>
-<BODY>
-<A HREF="SDCCUdoc-29.html">Next</A>
-<A HREF="SDCCUdoc-27.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc28">Contents</A>
-<HR>
-<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>
-<A HREF="SDCCUdoc.html#toc28">Contents</A>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
- <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>
-<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="Conclusion"></A> <A NAME="s29">29. 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).
-<HR>
-<A HREF="SDCCUdoc-30.html">Next</A>
-<A HREF="SDCCUdoc-28.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc29">Contents</A>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
- <TITLE>SDCC Compiler User Guide: Acknowledgments</TITLE>
- <LINK HREF="SDCCUdoc-31.html" REL=next>
- <LINK HREF="SDCCUdoc-29.html" REL=previous>
- <LINK HREF="SDCCUdoc.html#toc30" REL=contents>
-</HEAD>
-<BODY>
-<A HREF="SDCCUdoc-31.html">Next</A>
-<A HREF="SDCCUdoc-29.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc30">Contents</A>
-<HR>
-<H2><A NAME="Acknowledgements"></A> <A NAME="s30">30. Acknowledgments</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.
-<HR>
-<A HREF="SDCCUdoc-31.html">Next</A>
-<A HREF="SDCCUdoc-29.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc30">Contents</A>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
- <TITLE>SDCC Compiler User Guide: Appendix A: The Z80 and gbz80 port</TITLE>
- <LINK HREF="SDCCUdoc-30.html" REL=previous>
- <LINK HREF="SDCCUdoc.html#toc31" REL=contents>
-</HEAD>
-<BODY>
-Next
-<A HREF="SDCCUdoc-30.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc31">Contents</A>
-<HR>
-<H2><A NAME="s31">31. Appendix A: The Z80 and gbz80 port</A> </H2>
-
-<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>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>9
-<P>
-<HR>
-Next
-<A HREF="SDCCUdoc-30.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc31">Contents</A>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
- <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>
- <LINK HREF="SDCCUdoc.html#toc5" REL=contents>
-</HEAD>
-<BODY>
-<A HREF="SDCCUdoc-6.html">Next</A>
-<A HREF="SDCCUdoc-4.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc5">Contents</A>
-<HR>
-<H2><A NAME="Language Extension"></A> <A NAME="s5">5. Language Extensions</A> </H2>
-
-<H2><A NAME="Storage Classes"></A> <A NAME="ss5.1">5.1 Storage Classes.</A>
- </H2>
-
-<P>In addition to the ANSI storage classes SDCC allows the following 8051
-specific storage classes.
-<H3><A NAME="xdata"></A> xdata. </H3>
-
-<P>Variables declared with this storage class will be placed in the extern
-RAM. This is the <B>default</B> storage class for Large Memory model .
-<P>eg. xdata unsigned char xduc;
-<H3><A NAME="data"></A> data </H3>
-
-<P>This is the <B>default</B> storage class for Small Memory model. Variables declared
-with this storage class will be allocated in the internal RAM.
-<P>eg. data int iramdata;
-<H3><A NAME="idata"></A> idata </H3>
-
-<P>Variables declared with this storage class will be allocated into the indirectly
-addressable portion of the internal ram of a 8051 .
-<P>eg.idata int idi;
-<H3><A NAME="bit"></A> bit </H3>
-
-<P>This is a data-type and a storage class specifier. When a variable is declared
-as a bit , it is allocated into the bit addressable memory of 8051.
-<P>eg.bit iFlag;
-<H3><A NAME="sfr / sbit"></A> sfr / sbit </H3>
-
-<P>Like the bit keyword, sfr / sbit signifies both a data-type and storage
-class, they are used to describe the special function registers and special
-bit variables of a 8051.
-<P>eg.
-<P>sfr at 0x80 P0; /* special function register P0 at location 0x80 */
-<P>sbit at 0xd7 CY; /* CY (Carry Flag) */
-<HR>
-<A HREF="SDCCUdoc-6.html">Next</A>
-<A HREF="SDCCUdoc-4.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc5">Contents</A>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
- <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>
- <LINK HREF="SDCCUdoc.html#toc6" REL=contents>
-</HEAD>
-<BODY>
-<A HREF="SDCCUdoc-7.html">Next</A>
-<A HREF="SDCCUdoc-5.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc6">Contents</A>
-<HR>
-<H2><A NAME="Optimizations"></A> <A NAME="s6">6. Optimizations</A> </H2>
-
-<P>SDCC performs a a host of standard optimizations in addition to some MCU
-specific optimizations.
-<H2><A NAME="Sub-expression Elimination"></A> <A NAME="ss6.1">6.1 Sub-expression elimination</A>
- </H2>
-
-<P>The compiler does local and global common subexpression elimination.
-<P><CODE>eg. </CODE>
-<P>
-<PRE>
-i = x + y + 1;
-j = x + y;
-
-</PRE>
-<P>will be translated to
-<P>
-<PRE>
-iTemp = x + y
-i = iTemp + 1
-j = iTemp
-
-</PRE>
-<P>Some subexpressions are not as obvious as the above example.
-<P>eg.
-<P>
-<PRE>
-a->b[i].c = 10;
-a->b[i].d = 11;
-
-</PRE>
-<P>In this case the address arithmetic a->b[i] will be computed
-only once; the equivalent code in C would be.
-<P>
-<PRE>
-iTemp = a->b[i];
-iTemp.c = 10;
-iTemp.d = 11;
-
-</PRE>
-<P>The compiler will try to keep these temporary variables in registers.
-<H2><A NAME="Dead-code elimination"></A> <A NAME="ss6.2">6.2 Dead-Code elimination.</A>
- </H2>
-
-<P>eg.
-<P>
-<PRE>
-int global;
-void f () {
- int i;
- i = 1; /* dead store */
- global
- = 1; /* dead store */
- global = 2;
- return;
- global = 3; /* unreachable
- */
-}
-
-</PRE>
-<P>will be changed to
-<P>
-<PRE>
-int global; void f ()
-{
- global = 2;
- return;
-}
-
-</PRE>
-<H2><A NAME="Copy-Propagation"></A> <A NAME="ss6.3">6.3 Copy-Propagation:</A>
- </H2>
-
-<P>eg.
-<P>
-<PRE>
-int f() {
- int i, j;
- i = 10;
- j = i;
- return j;
-}
-
-</PRE>
-<P>will be changed to
-<P>
-<PRE>
-int f() {
- int i,j;
- i = 10;
- j = 10;
- return 10;
-
-}
-
-</PRE>
-<P>Note: the dead stores created by this copy propagation will be eliminated
-by dead-code elimination .
-<H2><A NAME="Loop Optimizations"></A> <A NAME="ss6.4">6.4 Loop optimizations</A>
- </H2>
-
-<P>Two types of loop optimizations are done by SDCC loop invariant lifting
-and strength reduction of loop induction variables.In addition to the strength
-reduction the optimizer marks the induction variables and the register allocator
-tries to keep the induction variables in registers for the duration of the
-loop. Because of this preference of the register allocator , loop induction
-optimization causes an increase in register pressure, which may cause unwanted
-spilling of other temporary variables into the stack / data space . The compiler
-will generate a warning message when it is forced to allocate extra space either
-on the stack or data space. If this extra space allocation is undesirable then
-induction optimization can be eliminated either for the entire source file
-( with --noinduction option) or for a given function only (#pragma NOINDUCTION).
-<H3><A NAME="Loop Invariant"></A> Loop Invariant: </H3>
-
-<P>eg
-<P>
-<PRE>
-for (i = 0 ; i < 100 ; i ++)
- f += k + l;
-
-</PRE>
-<P>changed to
-<P>
-<PRE>
-itemp = k + l;
-for ( i = 0; i < 100; i++ ) f += itemp;
-
-</PRE>
-<P>As mentioned previously some loop invariants are not as apparent, all static
-address computations are also moved out of the loop.
-<H3><A NAME="Strength Reduction"></A> Strength reduction : </H3>
-
-<P>This optimization substitutes an expression by a cheaper expression.
-<P>eg.
-<P>
-<PRE>
-for (i=0;i < 100; i++) ar[i*5] = i*3;
-
-</PRE>
-<P>changed to
-<P>
-<PRE>
-itemp1 = 0;
-itemp2 = 0;
-for (i=0;i< 100;i++) {
- ar[itemp1]
- = itemp2;
- itemp1 += 5;
- itemp2 += 3;
-}
-
-</PRE>
-<P>The more expensive multiplication is changed to a less expensive addition.
-<H3><A NAME="Loop reversing"></A> Loop reversing: </H3>
-
-<P>This optimization is done to reduce the overhead of checking loop boundaries
-for every iteration. Some simple loops can be reversed and implemented using
-a "decrement and jump if not zero" instruction. SDCC checks for the following
-criterion to determine if a loop is reversible (note: more sophisticated compiers
-use data-dependency analysis to make this determination, SDCC uses a more simple
-minded analysis).
-<P>
-<UL>
-<LI>The 'for' loop is of the form
-"for ( <symbol> = <expression>
-; <sym> [< | <=] <expression> ; [<sym>++
-| <sym> += 1])
-<for body>"</LI>
-<LI>The <for body> does not contain "continue" or 'break".</LI>
-<LI>All goto's are contained within the loop.</LI>
-<LI>No function calls within the loop.</LI>
-<LI>The loop control variable <sym> is not assigned any value within
-the loop</LI>
-<LI>The loop control variable does NOT participate in any arithmetic operation
-within the loop.</LI>
-<LI>There are NO switch statements in the loop.</LI>
-</UL>
-<P>Note djnz instruction can be used for 8-bit values ONLY, therefore it is
-advantageous to declare loop control symbols as either 'char' or 'short', ofcourse
-this may not be possible on all situations.
-<H2><A NAME="Algebraic Simplifications"></A> <A NAME="ss6.5">6.5 Algebraic simplifications:</A>
- </H2>
-
-<P>SDCC does numerous algebraic simplifications, the following is a small
-sub-set of these optimizations.
-<P>
-<PRE>
-eg
-i = j + 0 ; /* changed to */ i = j;
-i /= 2; /* changed to */ i >>=
- 1;
-i = j - j ; /* changed to */ i = 0;
-i = j / 1 ; /* changed to */ i = j;
-
-</PRE>
-<P>Note the subexpressions given above are generally introduced by macro expansions
-or as a result of copy/constant propagation.
-<H2><A NAME="Switch Statement"></A> <A NAME="ss6.6">6.6 'switch' statements.</A>
- </H2>
-
-<P>SDCC changes switch statements to jump tables when the following conditions
-are true.
-<P>
-<UL>
-<LI>The case labels are in numerical sequence , the labels need not be in order,
-and the starting number need not be one or zero.</LI>
-</UL>
-<P>eg
-<P>
-<PRE>
-switch(i) { switch (i) {
-case 4:...
- case 1: ...
-case 5:... case
- 2: ...
-case 3:... case 3: ...
-case 6:...
- case 4: ...
-} }
-
-</PRE>
-<P>Both the above switch statements will be implemented using a jump-table.
-<P>
-<UL>
-<LI>The number of case labels is at least three, since it takes two conditional
-statements to handle the boundary conditions.</LI>
-<LI>The number of case labels is less than 84, since each label takes 3 bytes
-and a jump-table can be utmost 256 bytes long. </LI>
-</UL>
-<P>Switch statements which have gaps in the numeric sequence or those that
-have more that 84 case labels can be split into more than one switch statement
-for efficient code generation.
-<P>eg
-<P>
-<PRE>
-switch (i) {
-case 1: ...
-case 2: ...
-case 3: ...
-case 4: ...
-case
- 9: ...
-case 10: ...
-case 11: ...
-case 12: ...
-}
-
-</PRE>
-<P>If the above switch statement is broken down into two switch statements
-<P>
-<PRE>
-switch (i) {
-case 1: ...
-case 2: ...
-case 3: ...
-case 4: ...
-}switch (i) {
-case 9: ...
-case 10: ...
-case 11: ...
-case 12:...
-
-}
-
-</PRE>
-<P>then both the switch statements will be implemented using jump-tables whereas
-the unmodified switch statement will not be .
-<H2><A NAME="bit shifting"></A> <A NAME="ss6.7">6.7 bit-shifting operations.</A>
- </H2>
-
-<P>Bit shifting is one of the most frequently used operation in embedded programming
-. SDCC tries to implement bit-shift operations in the most efficient way possible.
-<P>eg.
-<P>
-<PRE>
-unsigned short i;...
-i>>= 4;
-..
-
-</PRE>
-<P>generates the following code.
-<P>
-<PRE>
-mov a,_i
-swap a
-anl a,#0x0f
-mov _i,a
-
-</PRE>
-<P>In general SDCC will never setup a loop if the shift count is known. Another
-example
-<P>
-<PRE>
-unsigned int i;
-...
-i >>= 9;
-...
-
-</PRE>
-<P>will generate
-<P>
-<PRE>
-mov a,(_i + 1)
-mov (_i + 1),#0x00
-clr c
-rrc a
-mov _i,a
-
-</PRE>
-<P>Note that SDCC stores numbers in little-endian format (i.e. lowest order
-first)
-<H3><A NAME="bit rotation"></A> Bit-rotation: </H3>
-
-<P>A special case of the bit-shift operation is bit rotation, SDCC recognizes
-the following expression to be a left bit-rotation.
-<P>
-<PRE>
-unsigned char i;
-...
-i = ( ( i << 1) | ( i >> 7));
-...
-
-</PRE>
-<P>will generate the following code.
-<P>
-<PRE>
-mov a,_i
-rl a
-mov _i,a
-
-</PRE>
-<P>SDCC uses pattern matching on the parse tree to determine this operation
-.Variations of this case will also be recognized as bit-rotation i.e i = ((i
->> 7) | (i << 1)); /* left-bit rotation */
-<H2><A NAME="Highest Order Bit"></A> <A NAME="ss6.8">6.8 Highest Order Bit.</A>
- </H2>
-
-<P>It is frequently required to obtain the highest order bit of an integral
-type (int,long,short or char types). SDCC recognizes the following expression
-to yield the highest order bit and generates optimized code for it.
-<P>
-<PRE>
-eg
-unsigned int gint;
-foo () {
-unsigned char hob;
- ...
- hob
- = (gint >> 15) & 1;
- ..
-}
-
-</PRE>
-<P>Will generate the following code.
-<P>
-<PRE>
- 61 ; hob.c 7
- 000A E5*01
- 62 mov a,(_gint + 1)
- 000C 33 63 rlc
- a
- 000D E4 64 clr a
- 000E 13
- 65 rrc a
- 000F F5*02 66 mov _foo_hob_1_1,a
-
-</PRE>
-<P>Variations of this case however will NOT be recognized . It is a standard
-C expression , so I heartily recommend this be the only way to get the highest
-order bit, (it is portable). Of course it will be recognized even if it is
-embedded in other expressions.
-<P>
-<PRE>
-eg.xyz = gint + ((gint >> 15) & 1);
-
-</PRE>
-<P>will still be recognized.
-<H2><A NAME="Peep-Hole"></A> <A NAME="ss6.9">6.9 Peep-hole optimizer.</A>
- </H2>
-
-<P>The compiler uses a rule based , pattern matching and re-writing mechanism
-for peep-hole optimization . It is inspired by 'copt' a peep-hole optimizer
-by Christopher W. Fraser (cwfraser@microsoft.com). A default set of rules are
-compiled into the compiler, additional rules may be added with the --peep-file
-<filename> option. The rule language is best illustrated with examples.
-<P>
-<PRE>
-replace {
-mov %1,a
-mov a,%1 } by { mov %1,a
- }
-
-</PRE>
-<P>The above rule will the following assembly sequence
-<P>
-<PRE>
-mov r1,a
-mov a,r1
-
-</PRE>
-<P>to
-<P>
-<PRE>
-mov r1,a
-
-</PRE>
-<P>Note: All occurrences of a '%n' ( pattern variable ) must denote
-the same string. With the above rule, the assembly sequence
-<P>
-<PRE>
-mov r1,a
-mov a,r2
-
-</PRE>
-<P>will remain unmodified. Other special case optimizations may be added by
-the user (via --peep-file option), eg. some variants of the 8051 MCU allow
-only 'AJMP' and 'ACALL' , the following two rules will change all 'LJMP' &
-'LCALL' to 'AJMP' & 'ACALL'.
-<P>
-<PRE>
-replace { lcall %1 } by { acall %1 }
-
-replace { ljmp %1 } by { ajmp %1 }
-
-</PRE>
-<P>The inline-assembler' code is also passed through the peep hole optimizer,
-thus the peephole optimizer can also be used as an assembly level macro expander.
-The rules themselves are MCU dependent whereas the rule language infra-structure
-is MCU independent. Peephole optimization rules for other MCU can be easily
-programmed using the rule language.
-<P>The syntax for a rule is as follows ,
-<P>
-<PRE>
-rule := replace [ restart ] '{' <assembly sequence>
- '\n'
- '}' by '{' '\n'
-
- <assembly sequence> '\n'
-
- '}' [if <functionName> ] '\n'
-<assembly
- sequence> := assembly instruction (each instruction including labels must
- be on a separate line).
-
-</PRE>
-<P>The optimizer will apply to the rules one by one from the top in the sequence
-of their appearance, it will terminate when all rules are exhausted. If the
-'restart' option is specified, then the optimizer will start matching the rules
-again from the top, this option for a rule is expensive (performance), it is
-intended to be used in situations where a transformation will trigger the same
-rule again. A good example of this the following rule.
-<P>
-<PRE>
-replace restart {
-pop %1
-push %1 } by {
-
-; nop
-}
-
-</PRE>
-<P>Note that the replace pattern cannot be a blank, but can be a comment line.
-Without the 'restart' option only the inner most 'pop' 'push' pair would be
-eliminated. i.e.
-<P>
-<PRE>
-pop ar1
-pop ar2
-push ar2
-push ar1
-
-</PRE>
-<P>would result in
-<P>
-<PRE>
-pop ar1
-; nop
-push ar1
-
-</PRE>
-<P>with the 'restart' option the rule will be applied again to the resulting
-code and the all the 'pop' 'push' pairs will be eliminated to yield
-<P>
-<PRE>
-; nop
-; nop
-
-</PRE>
-<P>A conditional function can be attached to a rule. Attaching rules are somewhat
-more involved, let me illustrate this with an example.
-<P>
-<PRE>
-replace {
- ljmp %5
-%2:} by {
- sjmp
- %5
-%2:} if labelInRange
-
-</PRE>
-<P>The optimizer does a look-up of a function name table defined in function
-'callFuncByName' in the source file SDCCpeeph.c , with the name 'labelInRange',
-if it finds a corresponding entry the function is called. Note there can be
-no parameters specified for these functions, in this case the use of '%5'
-is crucial, since the function labelInRange expects to find the label in that
-particular variable (the hash table containing the variable bindings is passed
-as a parameter). If you want to code more such functions , take a close look
-at the function labelInRange and the calling mechanism in source file SDCCpeeph.c.
-I know this whole thing is a little kludgey , may be some day we will have
-some better means. If you are looking at this file, you will also see the default
-rules that are compiled into the compiler, you can your own rules in the default
-set there if you get tired of specifying the --peep-file option.
-<HR>
-<A HREF="SDCCUdoc-7.html">Next</A>
-<A HREF="SDCCUdoc-5.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc6">Contents</A>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
- <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>
- <LINK HREF="SDCCUdoc.html#toc7" REL=contents>
-</HEAD>
-<BODY>
-<A HREF="SDCCUdoc-8.html">Next</A>
-<A HREF="SDCCUdoc-6.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc7">Contents</A>
-<HR>
-<H2><A NAME="Pointers"></A> <A NAME="s7">7. Pointers</A> </H2>
-
-<P>SDCC allows (via language extensions) pointers to explicitly point to any
-of the memory spaces of the 8051. In addition to the explicit pointers, the
-compiler also allows a _generic class of pointers which can be used to point
-to any of the memory spaces.
-<P>Pointer declaration examples.
-<P>
-<PRE>
-/* pointer physically in xternal ram pointing to object in internal ram
- */
-data unsigned char * xdata p;
-/* pointer physically in code rom pointing to data in xdata space */
-xdata
- unsigned char * code p;
-/* pointer physically in code space pointing to data in code space */
-code
- unsigned char * code p;
-
-/* the folowing is a generic pointer physically located
- in xdata space */
-char * xdata p;
-
-</PRE>
-<P>Well you get the idea. For compatibility with the previous version of the
-compiler, the following syntax for pointer declaration is also supported. Note
-the above examples will be portable to other commercially available compilers.
-<P>
-<PRE>
-unsigned char _xdata *ucxdp; /* pointer to data in external ram */
-unsigned
- char _data *ucdp ; /* pointer to data in internal ram */
-unsigned char _code
- *uccp ; /* pointer to data in R/O code space */
-unsigned char _idata *uccp;
- /* pointer to upper 128 bytes of ram */
-
-</PRE>
-<P>All unqualified pointers are treated as 3 - byte '_generic' pointers. These
-type of pointers can also to be explicitly declared.
-<P>
-<PRE>
-unsigned char _generic *ucgp;
-
-</PRE>
-<P>The highest order byte of the generic pointers contains the data space
-information. Assembler support routines are called whenever data is stored
-or retrieved using _generic pointers. These are useful for developing reusable
-library routines. Explicitly specifying the pointer type will generate the
-most efficient code. Pointers declared using a mixture of OLD/NEW style could
-have unpredictable results.
-<HR>
-<A HREF="SDCCUdoc-8.html">Next</A>
-<A HREF="SDCCUdoc-6.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc7">Contents</A>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
- <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>
- <LINK HREF="SDCCUdoc.html#toc8" REL=contents>
-</HEAD>
-<BODY>
-<A HREF="SDCCUdoc-9.html">Next</A>
-<A HREF="SDCCUdoc-7.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc8">Contents</A>
-<HR>
-<H2><A NAME="Auto Variables"></A> <A NAME="s8">8. Parameters & Local Variables</A> </H2>
-
-<P>Automatic (local) variables and parameters to functions can either be placed
-on the stack or in data-space. The default action of the compiler is to place
-these variables in the internal RAM ( for small model) or external RAM (for
-Large model). They can be placed on the stack either by using the --stack-auto
-compiler option or by using the 'reentrant' keyword in the function declaration.
-<P><CODE>eg</CODE>
-<P>
-<PRE>
-unsigned short foo( short i) reentrant {
-...
-}
-
-</PRE>
-<P>Note that when the parameters & local variables are declared in the
-internal/external ram the functions are non-reentrant. Since stack space on
-8051 is limited the 'reentrant' keyword or the --stack-auto option should be
-used sparingly. Note the reentrant keyword just means that the parameters &
-local variables will be allocated to the stack, it DOES NOT mean that the function
-is register bank independent.
-<P>When compiled with the default option (i.e. non-reentrant ), local variables
-can be assigned storage classes and absolute addresses.
-<P><CODE>eg</CODE>
-<P>
-<PRE>
-unsigned short foo() {
- xdata unsigned short i;
- bit bvar;
-
- data at 0x31 unsiged short j;
-...
-}
-
-</PRE>
-<P>In the above example the variable i will be allocated in the external ram,
-bvar in bit addressable space and j in internal ram. When compiled with the
---stack-auto or when a function is declared as 'reentrant' local variables
-cannot be assigned storage classes or absolute addresses.
-<P>Parameters however are not allowed any storage class, (storage classes
-for parameters will be ignored), their allocation is governed by the memory
-model in use , and the reentrancy options.
-<H2><A NAME="Overlaying"></A> <A NAME="ss8.1">8.1 Overlaying</A>
- </H2>
-
-<P>For non-reentrant functions SDCC will try to reduce internal ram space
-usage by overlaying parameters and local variables of a function (if possible).
-Parameters and local variables of a function will be allocated to an overlayable
-segment if the function has no other function calls and the function is non-reentrant
-and the memory model is small. If an explicit storage class is specified for
-a local variable , it will NOT be overplayed.
-<P>Note that the compiler (not the linkage editor) makes the decision for
-overlaying the data items. Functions that are called from an interrupt service
-routine should be preceded by a #pragma NOOVERLAY if they are not reentrant
-Along the same lines the compiler does not do any processing with the inline
-assembler code so the compiler might incorrectly assign local variables and
-parameters of a function into the overlay segment if the only function call
-from a function is from inline assembler code, it is safe to use the #pragma
-NOOVERLAY for functions which call other functions using inline assembler code.
-<P>Parameters and Local variables of functions that contain 16 or 32 bit multiplication
-or division will NOT be overlayed since these are implemented using external
-functions.
-<P>eg.
-<P>
-<PRE>
-#pragma SAVE
-#pragma NOOVERLAY
-void set_error( unsigned short
- errcd)
-{
- P3 = errcd;
-}
-#pragma RESTORE
-void some_isr
- () interrupt 2 using 1
-{
- ...
- set_error(10);
- ...
-}
-
-</PRE>
-<P>In the above example the parameter errcd for the function set_error would
-be assigned to the overlayable segment (if the #pragma NOOVERLAY was not
-present) , this could cause unpredictable runtime behavior. The pragma NOOVERLAY
-ensures that the parameters and local variables for the function are NOT overlayed.
-<HR>
-<A HREF="SDCCUdoc-9.html">Next</A>
-<A HREF="SDCCUdoc-7.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc8">Contents</A>
-</BODY>
-</HTML>
+++ /dev/null
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML>
-<HEAD>
- <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>
- <LINK HREF="SDCCUdoc.html#toc9" REL=contents>
-</HEAD>
-<BODY>
-<A HREF="SDCCUdoc-10.html">Next</A>
-<A HREF="SDCCUdoc-8.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc9">Contents</A>
-<HR>
-<H2><A NAME="Critical"></A> <A NAME="s9">9. critical Functions.</A> </H2>
-
-<P>A special keyword may be associated with a function declaring it as 'critical'.
-SDCC will generate code to disable all interrupts upon entry to a critical
-function and enable them back before returning . Note that nesting critical
-functions may cause unpredictable results.
-<P>eg
-<P>
-<PRE>
-int foo () critical
-{
-...
-...
-}
-
-</PRE>
-<P>The critical attribute maybe used with other attributes like reentrant.
-<HR>
-<A HREF="SDCCUdoc-10.html">Next</A>
-<A HREF="SDCCUdoc-8.html">Previous</A>
-<A HREF="SDCCUdoc.html#toc9">Contents</A>
-</BODY>
-</HTML>
projects / fw / sdcc / commitdiff