From: kbongers Date: Mon, 2 Jul 2001 06:09:40 +0000 (+0000) Subject: Go to single file .html X-Git-Url: https://git.gag.com/?a=commitdiff_plain;h=02d4f3e2b701dcdb88981a3292d226fc818b93b7;p=fw%2Fsdcc Go to single file .html git-svn-id: https://sdcc.svn.sourceforge.net/svnroot/sdcc/trunk/sdcc@992 4a8a32a2-be11-0410-ad9d-d568d2c75423 --- diff --git a/doc/SDCCUdoc-10.html b/doc/SDCCUdoc-10.html deleted file mode 100644 index fb3fef79..00000000 --- a/doc/SDCCUdoc-10.html +++ /dev/null @@ -1,48 +0,0 @@ - - - - - SDCC Compiler User Guide: Absolute addressing. - - - - - -Next -Previous -Contents -
-

10. Absolute addressing.

- -

Data items can be assigned an absolute address with the at <address> -keyword, in addition to a storage class. -

-

-eg. xdata at 0x8000 unsigned char PORTA_8255 ;
- 
-
-

In the above example the PORTA_8255 will be allocated to the location 0x8000 -of the external ram. -

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. -

Absolute address can be specified for variables in all storage classes. -

-

-eg.bit at 0x02 bvar;
- 
-
-

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. -

-Next -Previous -Contents - - diff --git a/doc/SDCCUdoc-11.html b/doc/SDCCUdoc-11.html deleted file mode 100644 index 6a2fb5f0..00000000 --- a/doc/SDCCUdoc-11.html +++ /dev/null @@ -1,77 +0,0 @@ - - - - - SDCC Compiler User Guide: Interrupt Service Routines - - - - - -Next -Previous -Contents -
-

11. Interrupt Service Routines

- -

SDCC allows interrupt service routines to be coded in C, with some extended -keywords. -

-

-void timer_isr (void) interrupt 2 using 1 
-{ 
-.. 
-}
- 
-
-

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. -

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'. -

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. -

-

-Interrupt #         Description           Vector Address 
-   0                External
- 0            0x0003 
-   1                Timer 0               0x000B 
-   2
-                External 1            0x0013 
-   3                Timer 1               0x001B
- 
-   4                Serial                0x0023
- 
-
-

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. -

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. -

Calling other functions from an interrupt service routine is not recommended -avoid it if possible. -

-Next -Previous -Contents - - diff --git a/doc/SDCCUdoc-12.html b/doc/SDCCUdoc-12.html deleted file mode 100644 index 60249336..00000000 --- a/doc/SDCCUdoc-12.html +++ /dev/null @@ -1,27 +0,0 @@ - - - - - SDCC Compiler User Guide: Startup Code - - - - - -Next -Previous -Contents -
-

12. Startup Code

- -

The compiler inserts a jump to the C routine _sdcc__external__startup()at the start of the CODE area. This routine can be found in the file SDCCDIR/sdcc51lib/_startup.c -, 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. -

-Next -Previous -Contents - - diff --git a/doc/SDCCUdoc-13.html b/doc/SDCCUdoc-13.html deleted file mode 100644 index ffad944f..00000000 --- a/doc/SDCCUdoc-13.html +++ /dev/null @@ -1,71 +0,0 @@ - - - - - SDCC Compiler User Guide: Inline assembler code. - - - - - -Next -Previous -Contents -
-

13. Inline assembler code.

- -

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 --peep-asm 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. -

-

-eg_asm 
-         mov b,#10 
-00001$: 
-         djnz b,00001$
- 
-_endasm ;
- 
-
-

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. -

Inline assembler code cannot reference any C-Labels however it can reference -labels defined by the inline assembler. -

-

-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 ; 
-... 
-}
- 
-
-

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. -

-Next -Previous -Contents - - diff --git a/doc/SDCCUdoc-14.html b/doc/SDCCUdoc-14.html deleted file mode 100644 index d8e4f1a0..00000000 --- a/doc/SDCCUdoc-14.html +++ /dev/null @@ -1,47 +0,0 @@ - - - - - SDCC Compiler User Guide: int (16 bit) and long (32 bit ) support. - - - - - -Next -Previous -Contents -
-

14. int (16 bit) and long (32 bit ) support.

- -

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 -

-

-

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. -

-Next -Previous -Contents - - diff --git a/doc/SDCCUdoc-15.html b/doc/SDCCUdoc-15.html deleted file mode 100644 index 0cf81b23..00000000 --- a/doc/SDCCUdoc-15.html +++ /dev/null @@ -1,48 +0,0 @@ - - - - - SDCC Compiler User Guide: Floating point support - - - - - -Next -Previous -Contents -
-

15. Floating point support

- -

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. -

-

-

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) -

-Next -Previous -Contents - - diff --git a/doc/SDCCUdoc-16.html b/doc/SDCCUdoc-16.html deleted file mode 100644 index 2502743f..00000000 --- a/doc/SDCCUdoc-16.html +++ /dev/null @@ -1,36 +0,0 @@ - - - - - SDCC Compiler User Guide: Memory Models - - - - - -Next -Previous -Contents -
-

16. Memory Models

- -

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. -

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. -

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. -

-Next -Previous -Contents - - diff --git a/doc/SDCCUdoc-17.html b/doc/SDCCUdoc-17.html deleted file mode 100644 index 482dbfeb..00000000 --- a/doc/SDCCUdoc-17.html +++ /dev/null @@ -1,56 +0,0 @@ - - - - - SDCC Compiler User Guide: Flat 24 bit addressing model. - - - - - -Next -Previous -Contents -
-

17. Flat 24 bit addressing model.

- -

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. -

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. -

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. -

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. -

--stack-10bit: -

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. -

With this option, sdcc will generate the proper addressing for stack variables. -

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. -

The compiler will not generate any code to put the processor into 10 bit -stack mode. It is important to ensure that the processor is in this mode before -calling any re-entrant functions compiled with this option. -

In principle, this should work with the --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). -

-Next -Previous -Contents - - diff --git a/doc/SDCCUdoc-18.html b/doc/SDCCUdoc-18.html deleted file mode 100644 index d9b24711..00000000 --- a/doc/SDCCUdoc-18.html +++ /dev/null @@ -1,31 +0,0 @@ - - - - - SDCC Compiler User Guide: Defines created by the compiler. - - - - - -Next -Previous -Contents -
-

18. Defines created by the compiler.

- -

The compiler creates the following #defines . -

-

-
-Next -Previous -Contents - - diff --git a/doc/SDCCUdoc-19.html b/doc/SDCCUdoc-19.html deleted file mode 100644 index 8c23bdee..00000000 --- a/doc/SDCCUdoc-19.html +++ /dev/null @@ -1,95 +0,0 @@ - - - - - SDCC Compiler User Guide: Pragmas - - - - - -Next -Previous -Contents -
-

19. Pragmas

- -

SDCC supports the following #pragma directives. This directives are -applicable only at a function level. -

-

-

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. -

-

-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 */
- 
-
-

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. -

-Next -Previous -Contents - - diff --git a/doc/SDCCUdoc-20.html b/doc/SDCCUdoc-20.html deleted file mode 100644 index aaeeb627..00000000 --- a/doc/SDCCUdoc-20.html +++ /dev/null @@ -1,98 +0,0 @@ - - - - - SDCC Compiler User Guide: Library routines. - - - - - -Next -Previous -Contents -
-

20. Library routines.

- -

The following library routines are provided for your convenience. -

stdio.h - Contains the following functions printf & sprintf these routines -are developed by Martijn van Balen <balen@natlab.research.philips.com>. -

-

-

-%[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)
- 
-
-

Also contains a very simple version of printf (printf_small). This simplified -version of printf supports only the following formats. -

-

-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.
- 
-
-
-Next -Previous -Contents - - diff --git a/doc/SDCCUdoc-21.html b/doc/SDCCUdoc-21.html deleted file mode 100644 index 142442f1..00000000 --- a/doc/SDCCUdoc-21.html +++ /dev/null @@ -1,257 +0,0 @@ - - - - - SDCC Compiler User Guide: Interfacing with assembly routines. - - - - - -Next -Previous -Contents -
-

21. Interfacing with assembly routines.

- -

21.1 Global registers used for parameter passing. -

- -

By default the compiler uses the global registers "DPL,DPH,B,ACC" to pass -the first parameter to a routine, the second parameter onwards is either allocated -on the stack (for reentrant routines or --stack-auto is used) or in the internal -/ external ram (depending on the memory model). -

Assembler routine non-reentrant

- -

In the following example the function cfunc calls an assembler routine -asm_func, which takes two parameters. -

extern int asm_func( unsigned short, unsigned short); -

-

- 
-int c_func (unsigned short i, unsigned short j) 
-{ 
-        return
- asm_func(i,j); 
-} 
-int main() 
-{ 
-   return c_func(10,9); 
-}
- 
-
-

The corresponding assembler function is:- -

-

-        .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
- 
-
-

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. -

The parameter naming convention is _<function_name>_PARM_<n>, -where n is the parameter number starting from 1, and counting from the left. -The first parameter is passed in "dpl" for One bye parameter, "dptr" if two bytes, -"b,dptr" for three bytes and "acc,b,dptr" for four bytes, the varaible name for -the second parameter will be _<function_name>_PARM_2. -

Assemble the assembler routine with the following command. -

-

-asx8051 -losg asmfunc.asm
- 
-
-

Then compile and link the assembler routine to the C source file with the -following command, -

-

-sdcc cfunc.c asmfunc.rel
- 
-
-

Assembler routine is reentrant

- -

In this case the second parameter onwards will be passed on the stack , -the parameters are pushed from right to left i.e. after the call the left most -parameter will be on the top of the stack. Here is an example. -

extern int asm_func( unsigned short, unsigned short); -

-

- int c_func (unsigned short i, unsigned short j) reentrant 
-{ 
-       
- return asm_func(i,j); 
-} 
-int main() 
-{ 
-   return c_func(10,9);
- 
-}
- 
-
-

The corresponding assembler routine is. -

-

-        .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
- 
-
-

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. -

21.2 With --noregparms option. -

- -

When the source is compiled with --noregparms option , space is allocated -for each of the parameters passed to a routine. -

Assembler routine non-reentrant.

- -

In the following example the function cfunc calls an assembler routine -asm_func, which takes two parameters. -

-

-extern int asm_func( unsigned short, unsigned short); 
-int c_func (unsigned short i, unsigned short j) 
-{ 
-        return
- asm_func(i,j); 
-} 
-int main() 
-{ 
-   return c_func(10,9); 
-}
- 
-
-

The corresponding assembler function is:- -

-

-        .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
- 
-
-

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. -

The parameter naming convention is _<function_name>_PARM_<n>, -where n is the parameter number starting from 1, and counting from the left. -i.e. the left-most parameter name will be _<function_name>_PARM_1. -

Assemble the assembler routine with the following command. -

-

-asx8051 -losg asmfunc.asm
- 
-
-

Then compile and link the assembler routine to the C source file with the -following command, -

-

-sdcc cfunc.c asmfunc.rel
- 
-
-

Assembler routine is reentrant.

- -

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. -

extern int asm_func( unsigned short, unsigned short); -

-

- int c_func (unsigned short i, unsigned short j) reentrant 
-{ 
-       
- return asm_func(i,j); 
-} 
-int main() 
-{ 
-   return c_func(10,9);
- 
-}
- 
-
-

The corresponding assembler routine is. -

-

-        .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
- 
-
-

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. -

-Next -Previous -Contents - - diff --git a/doc/SDCCUdoc-22.html b/doc/SDCCUdoc-22.html deleted file mode 100644 index ea3a751b..00000000 --- a/doc/SDCCUdoc-22.html +++ /dev/null @@ -1,32 +0,0 @@ - - - - - SDCC Compiler User Guide: External Stack. - - - - - -Next -Previous -Contents -
-

22. External Stack.

- -

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). -

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. -

-Next -Previous -Contents - - diff --git a/doc/SDCCUdoc-23.html b/doc/SDCCUdoc-23.html deleted file mode 100644 index 79155e3e..00000000 --- a/doc/SDCCUdoc-23.html +++ /dev/null @@ -1,91 +0,0 @@ - - - - - SDCC Compiler User Guide: ANSI-Compliance. - - - - - -Next -Previous -Contents -
-

23. ANSI-Compliance.

- -

Deviations from the compliancy. -

-

    -
  1. functions are not always reentrant.
    2. -
  2. structures cannot be assigned values directly, cannot be passed as function -parameters or assigned to each other and cannot be a return value from a function. -
    -eg
-  
-
    -
    3. -
-

-

-struct s { ... }; 
-struct s s1, s2; 
-foo() 
-{ 
-... 
-s1 =
- s2 ; /* is invalid in SDCC although allowed in ANSI */ 
-... 
-}struct s foo1 (struct s parms) /* is invalid in SDCC although allowed in
- ANSI */ 
-{ 
-struct s rets; 
-... 
-return rets;/* is invalid in SDCC although
- allowed in ANSI */ 
-}
- 
-
-

-

    -
  1. 'long long' (64 bit integers) not supported.
    2. -
  2. 'double' precision floating point not supported.
    3. -
  3. integral promotions are suppressed. What does this mean ? The compiler -will not implicitly promote an integer expression to a higher order integer, -exception is an assignment or parameter passing.
    4. -
  4. No support for setjmp and longjmp (for now).
    5. -
  5. Old K&R style function declarations are NOT allowed.
    6. -
-

-

-foo( i,j) /* this old style of function declarations */ 
-int i,j; /* are
- valid in ANSI .. not valid in SDCC */ 
-{ 
-... 
-}
- 
-
-

-

    -
  1. functions declared as pointers must be dereferenced during the call. -
    -int (*foo)();
-  
-
    -
    2. -
-

-

-   ... 
-   /* has to be called like this */ 
-   (*foo)();/* ansi standard
- allows calls to be made like 'foo()' */
- 
-
-
-Next -Previous -Contents - - diff --git a/doc/SDCCUdoc-24.html b/doc/SDCCUdoc-24.html deleted file mode 100644 index b57f4cca..00000000 --- a/doc/SDCCUdoc-24.html +++ /dev/null @@ -1,46 +0,0 @@ - - - - - SDCC Compiler User Guide: Cyclomatic Complexity - - - - - -Next -Previous -Contents -
-

24. Cyclomatic Complexity

- -

Cyclomatic complexity of a function is defined as the number of independent -paths the program can take during execution of the function. This is an important -number since it defines the number test cases you have to generate to validate -the function . The accepted industry standard for complexity number is 10, -if the cyclomatic complexity reported by SDCC exceeds 10 you should think about -simplification of the function logic. -

Note that the complexity level is not related to the number of lines of -code in a function. Large functions can have low complexity, and small functions -can have large complexity levels. SDCC uses the following formula to compute -the complexity. -

-

-complexity = (number of edges in control flow graph) - 
-             (number
- of nodes in control flow graph) + 2;
- 
-
-

Having said that the industry standard is 10, you should be aware that -in some cases it 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. -

-Next -Previous -Contents - - diff --git a/doc/SDCCUdoc-25.html b/doc/SDCCUdoc-25.html deleted file mode 100644 index c42b795f..00000000 --- a/doc/SDCCUdoc-25.html +++ /dev/null @@ -1,118 +0,0 @@ - - - - - SDCC Compiler User Guide: TIPS - - - - - -Next -Previous -Contents -
-

25. TIPS

- -

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. -

-

-

Notes from an USER ( Trefor@magera.freeserve.co.uk ) -

The 8051 family of micro controller have a minimum of 128 bytes of internal -memory which is structured as follows -

- Bytes 00-1F - 32 bytes to hold up to 4 banks of the registers R7 to R7 -

-

- Bytes 20-2F - 16 bytes to hold 128 bit variables and -

- Bytes 30-7F - 60 bytes for general purpose use. -

Normally the SDCC compiler will only utilise the first bank 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. -

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. -

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. -

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. -

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. -

--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. -

--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. -

--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. -

Conclusion. -

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. -

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. -

-Next -Previous -Contents - - diff --git a/doc/SDCCUdoc-26.html b/doc/SDCCUdoc-26.html deleted file mode 100644 index 5a4ab36f..00000000 --- a/doc/SDCCUdoc-26.html +++ /dev/null @@ -1,73 +0,0 @@ - - - - - SDCC Compiler User Guide: Retargetting for other MCUs. - - - - - -Next -Previous -Contents -
-

26. Retargetting for other MCUs.

- -

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. -

-

    -
  1. Parsing the source and building the annotated parse tree. This phase is -largely MCU independent (except for the language extensions). Syntax & -semantic checks are also done in this phase , along with some initial optimizations -like back patching labels and the pattern matching optimizations like bit-rotation -etc.
    2. -
  2. 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.
    3. -
  3. This phase does the bulk of the standard optimizations and is also MCU -independent. This phase can be broken down into several sub-phases. -
      -
    • Break down intermediate code (iCode) into basic blocks.
      • -
    • Do control flow & data flow analysis on the basic blocks.
      • -
    • Do local common subexpression elimination, then global subexpression elimination
      • -
    • dead code elimination
      • -
    • loop optimizations
      • -
    • if loop optimizations caused any changes then do 'global subexpression -elimination' and 'dead code elimination' again.
      • -
    -
    4. -
  4. This phase determines the live-ranges; by live range I mean those iTemp -variables defined by the compiler that still survive after all the optimizations. -Live range analysis is essential for register allocation, since these computation -determines which of these iTemps will be assigned to registers, and for how -long.
    5. -
  5. Phase five is register allocation. There are two parts to this process -. -
      -
    1. 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.
      2. -
    2. 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.
      3. -
    -
    6. -
  6. The Code generation phase is (unhappily), entirely MCU dependent and very -little (if any at all) of this code can be reused for other MCU. However the -scheme for allocating a homogenized assembler operand for each iCode operand -may be reused.
    7. -
  7. As mentioned in the optimization section the peep-hole optimizer is rule -based system, which can reprogrammed for other MCUs.
    8. -
-
-Next -Previous -Contents - - diff --git a/doc/SDCCUdoc-27.html b/doc/SDCCUdoc-27.html deleted file mode 100644 index 7c2da075..00000000 --- a/doc/SDCCUdoc-27.html +++ /dev/null @@ -1,27 +0,0 @@ - - - - - SDCC Compiler User Guide: Reporting Bugs - - - - - -Next -Previous -Contents -
-

27. Reporting Bugs

- -

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. -

-Next -Previous -Contents - - diff --git a/doc/SDCCUdoc-28.html b/doc/SDCCUdoc-28.html deleted file mode 100644 index f5247e32..00000000 --- a/doc/SDCCUdoc-28.html +++ /dev/null @@ -1,247 +0,0 @@ - - - - - SDCC Compiler User Guide: SDCDB - Source level debugger. - - - - - -Next -Previous -Contents -
-

28. SDCDB - Source level debugger.

- -

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 - 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. -

28.1 Compiling for debugging. -

- -

The --debug option must be specified for all files for which debug information -is to be generated. The complier generates a .cdb file for each of these files. -The linker updates the .cdb file with the address information. This .cdb is -used by the debugger . -

28.2 How the debugger works. -

- -

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 . -

28.3 Starting the debugger. -

- -

The debugger can be started using the following command line. (Assume the -file you are debugging has -

the file name foo). -

-

->sdcdb foo
- 
-
-

The debugger will look for the following files. -

-

    -
  1. foo.c - the source file.
    2. -
  2. foo.cdb - the debugger symbol information file.
    3. -
  3. foo.ihx - the intel hex format object file.
    4. -
-

28.4 Command line options. -

- -

-

-

28.5 Debugger Commands. -

- -

As mention earlier the command interface for the debugger has been deliberately -kept as close the GNU debugger gdb , as possible, this will help int integration -with existing graphical user interfaces (like ddd, xxgdb or xemacs) existing -for the GNU debugger. -

break [line | file:line | function | file:function]

- -

Set breakpoint at specified line or function. -

-

-sdcdb>break 100 
-sdcdb>break foo.c:100
-sdcdb>break funcfoo
-sdcdb>break
- foo.c:funcfoo
- 
-
-

clear [line | file:line | function | file:function ]

- -

Clear breakpoint at specified line or function. -

-

-sdcdb>clear 100
-sdcdb>clear foo.c:100
-sdcdb>clear funcfoo
-sdcdb>clear
- foo.c:funcfoo
- 
-
-

continue

- -

Continue program being debugged, after breakpoint. -

finish

- -

Execute till the end of the current function. -

delete [n]

- -

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

info [break | stack | frame | registers ]

- -

-

-

step

- -

Step program until it reaches a different source line. -

next

- -

Step program, proceeding through subroutine calls. -

run

- -

Start debugged program. -

ptype variable

- -

Print type information of the variable. -

print variable

- -

print value of variable. -

file filename

- -

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

frame

- -

print information about current frame. -

set srcmode

- -

Toggle between C source & assembly source. -

! simulator command

- -

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

quit.

- -

"Watch me now. Iam going Down. My name is Bobby Brown" -

28.6 Interfacing with XEmacs. -

- -

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. -

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. -

-

-

The following is a list of key mapping for the debugger interface. -

-

- 
-;; 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 
-;; 
-
- 
-
-
-Next -Previous -Contents - - diff --git a/doc/SDCCUdoc-29.html b/doc/SDCCUdoc-29.html deleted file mode 100644 index e05b0642..00000000 --- a/doc/SDCCUdoc-29.html +++ /dev/null @@ -1,30 +0,0 @@ - - - - - SDCC Compiler User Guide: Conclusion - - - - - -Next -Previous -Contents -
-

29. Conclusion

- -

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. -

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). -

-Next -Previous -Contents - - diff --git a/doc/SDCCUdoc-30.html b/doc/SDCCUdoc-30.html deleted file mode 100644 index 199c6aaf..00000000 --- a/doc/SDCCUdoc-30.html +++ /dev/null @@ -1,33 +0,0 @@ - - - - - SDCC Compiler User Guide: Acknowledgments - - - - - -Next -Previous -Contents -
-

30. Acknowledgments

- -

Alan Baldwin (baldwin@shop-pdp.kent.edu) - Initial version of ASXXXX & -ASLINK. -

John Hartman (jhartman@compuserve.com) - Porting ASXXX & ASLINK for -8051 -

Dmitry S. Obukhov (dso@usa.net) - malloc & serial i/o routines. -

Daniel Drotos <drdani@mazsola.iit.uni-miskolc.hu> - for his Freeware -simulator -

Jans J Boehm(boehm@sgi.com) and Alan J Demers - Conservative garbage collector -for C & C++. -

Malini Dutta(malini_dutta@hotmail.com) - my wife for her patience and support. -

Unknown - for the GNU C - preprocessor. -

-Next -Previous -Contents - - diff --git a/doc/SDCCUdoc-31.html b/doc/SDCCUdoc-31.html deleted file mode 100644 index 07d9efe1..00000000 --- a/doc/SDCCUdoc-31.html +++ /dev/null @@ -1,34 +0,0 @@ - - - - - SDCC Compiler User Guide: Appendix A: The Z80 and gbz80 port - - - - -Next -Previous -Contents -
-

31. Appendix A: The Z80 and gbz80 port

- -

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. -

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 -

9 -

-

-Next -Previous -Contents - - diff --git a/doc/SDCCUdoc-5.html b/doc/SDCCUdoc-5.html deleted file mode 100644 index 1b8c6b99..00000000 --- a/doc/SDCCUdoc-5.html +++ /dev/null @@ -1,55 +0,0 @@ - - - - - SDCC Compiler User Guide: Language Extensions - - - - - -Next -Previous -Contents -
-

5. Language Extensions

- -

5.1 Storage Classes. -

- -

In addition to the ANSI storage classes SDCC allows the following 8051 -specific storage classes. -

xdata.

- -

Variables declared with this storage class will be placed in the extern -RAM. This is the default storage class for Large Memory model . -

eg. xdata unsigned char xduc; -

data

- -

This is the default storage class for Small Memory model. Variables declared -with this storage class will be allocated in the internal RAM. -

eg. data int iramdata; -

idata

- -

Variables declared with this storage class will be allocated into the indirectly -addressable portion of the internal ram of a 8051 . -

eg.idata int idi; -

bit

- -

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. -

eg.bit iFlag; -

sfr / sbit

- -

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. -

eg. -

sfr at 0x80 P0; /* special function register P0 at location 0x80 */ -

sbit at 0xd7 CY; /* CY (Carry Flag) */ -

-Next -Previous -Contents - - diff --git a/doc/SDCCUdoc-6.html b/doc/SDCCUdoc-6.html deleted file mode 100644 index 355ad40f..00000000 --- a/doc/SDCCUdoc-6.html +++ /dev/null @@ -1,532 +0,0 @@ - - - - - SDCC Compiler User Guide: Optimizations - - - - - -Next -Previous -Contents -
-

6. Optimizations

- -

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

6.1 Sub-expression elimination -

- -

The compiler does local and global common subexpression elimination. -

eg. -

-

-i = x + y + 1; 
-j = x + y;
- 
-
-

will be translated to -

-

-iTemp = x + y 
-i = iTemp + 1 
-j = iTemp
- 
-
-

Some subexpressions are not as obvious as the above example. -

eg. -

-

-a->b[i].c = 10; 
-a->b[i].d = 11;
- 
-
-

In this case the address arithmetic a->b[i] will be computed -only once; the equivalent code in C would be. -

-

-iTemp = a->b[i]; 
-iTemp.c = 10; 
-iTemp.d = 11;
- 
-
-

The compiler will try to keep these temporary variables in registers. -

6.2 Dead-Code elimination. -

- -

eg. -

-

-int global; 
-void f () { 
-  int i; 
-  i = 1;    /* dead store */ 
-  global
- = 1; /* dead store */ 
-  global = 2; 
-  return; 
-  global = 3; /* unreachable
- */ 
-}
- 
-
-

will be changed to -

-

-int global; void f () 
-{     
- global = 2;     
- return; 
-}
- 
-
-

6.3 Copy-Propagation: -

- -

eg. -

-

-int f() { 
-   int i, j; 
-   i = 10; 
-   j = i; 
-   return j; 
-}
- 
-
-

will be changed to -

-

-int f() { 
-    int i,j; 
-    i = 10; 
-    j = 10; 
-    return 10;
- 
-}
- 
-
-

Note: the dead stores created by this copy propagation will be eliminated -by dead-code elimination . -

6.4 Loop optimizations -

- -

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). -

Loop Invariant:

- -

eg -

-

-for (i = 0 ; i < 100 ; i ++) 
-     f += k + l;
- 
-
-

changed to -

-

-itemp = k + l; 
-for ( i = 0; i < 100; i++ ) f += itemp;
- 
-
-

As mentioned previously some loop invariants are not as apparent, all static -address computations are also moved out of the loop. -

Strength reduction :

- -

This optimization substitutes an expression by a cheaper expression. -

eg. -

-

-for (i=0;i < 100; i++) ar[i*5] = i*3;
- 
-
-

changed to -

-

-itemp1 = 0; 
-itemp2 = 0; 
-for (i=0;i< 100;i++) { 
-     ar[itemp1]
- = itemp2; 
-     itemp1 += 5; 
-     itemp2 += 3; 
-}
- 
-
-

The more expensive multiplication is changed to a less expensive addition. -

Loop reversing:

- -

This optimization is done to reduce the overhead of checking loop boundaries -for every iteration. Some simple loops can be reversed and implemented using -a "decrement and jump if not zero" instruction. SDCC checks for the following -criterion to determine if a loop is reversible (note: more sophisticated compiers -use data-dependency analysis to make this determination, SDCC uses a more simple -minded analysis). -

-

-

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. -

6.5 Algebraic simplifications: -

- -

SDCC does numerous algebraic simplifications, the following is a small -sub-set of these optimizations. -

-

-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;
- 
-
-

Note the subexpressions given above are generally introduced by macro expansions -or as a result of copy/constant propagation. -

6.6 'switch' statements. -

- -

SDCC changes switch statements to jump tables when the following conditions -are true. -

-

-

eg -

-

-switch(i) {                         switch (i) { 
-case 4:...
-                          case 1: ... 
-case 5:...                          case
- 2: ... 
-case 3:...                          case 3: ... 
-case 6:...        
-                  case 4: ... 
-}                                   }
- 
-
-

Both the above switch statements will be implemented using a jump-table. -

-

-

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. -

eg -

-

-switch (i) { 
-case 1: ... 
-case 2: ... 
-case 3: ... 
-case 4: ... 
-case
- 9: ... 
-case 10: ... 
-case 11: ... 
-case 12: ... 
-}
- 
-
-

If the above switch statement is broken down into two switch statements -

-

-switch (i) { 
-case 1: ... 
-case 2: ... 
-case 3: ... 
-case 4: ... 
-}switch (i) { 
-case 9: ... 
-case 10: ... 
-case 11: ... 
-case 12:...
- 
-}
- 
-
-

then both the switch statements will be implemented using jump-tables whereas -the unmodified switch statement will not be . -

6.7 bit-shifting operations. -

- -

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. -

eg. -

-

-unsigned short i;... 
-i>>= 4; 
-..
- 
-
-

generates the following code. -

-

-mov a,_i 
-swap a 
-anl a,#0x0f 
-mov _i,a
- 
-
-

In general SDCC will never setup a loop if the shift count is known. Another -example -

-

-unsigned int i; 
-... 
-i >>= 9; 
-...
- 
-
-

will generate -

-

-mov a,(_i + 1) 
-mov (_i + 1),#0x00 
-clr c 
-rrc a 
-mov _i,a
- 
-
-

Note that SDCC stores numbers in little-endian format (i.e. lowest order -first) -

Bit-rotation:

- -

A special case of the bit-shift operation is bit rotation, SDCC recognizes -the following expression to be a left bit-rotation. -

-

-unsigned char i; 
-... 
-i = ( ( i << 1) | ( i >> 7)); 
-...
- 
-
-

will generate the following code. -

-

-mov a,_i 
-rl a 
-mov _i,a
- 
-
-

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 */ -

6.8 Highest Order Bit. -

- -

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. -

-

-eg 
-unsigned int gint; 
-foo () { 
-unsigned char hob; 
-   ... 
-   hob
- = (gint >> 15) & 1; 
-   .. 
-}
- 
-
-

Will generate the following code. -

-

-                             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
- 
-
-

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. -

-

-eg.xyz = gint + ((gint >> 15) & 1);
- 
-
-

will still be recognized. -

6.9 Peep-hole optimizer. -

- -

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. -

-

-replace { 
-mov %1,a 
-mov a,%1 } by { mov %1,a
- }
- 
-
-

The above rule will the following assembly sequence -

-

-mov r1,a 
-mov a,r1
- 
-
-

to -

-

-mov r1,a
- 
-
-

Note: All occurrences of a '%n' ( pattern variable ) must denote -the same string. With the above rule, the assembly sequence -

-

-mov r1,a 
-mov a,r2
- 
-
-

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'. -

-

-replace { lcall %1 } by { acall %1 }
- 
-replace { ljmp %1 } by { ajmp %1 }
- 
-
-

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. -

The syntax for a rule is as follows , -

-

-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).   
- 
-
-

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. -

-

-replace restart { 
-pop %1 
-push %1 } by {
- 
-; nop 
-}
- 
-
-

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. -

-

-pop ar1 
-pop ar2 
-push ar2 
-push ar1
- 
-
-

would result in -

-

-pop ar1 
-; nop 
-push ar1
- 
-
-

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 -

-

-; nop 
-; nop
- 
-
-

A conditional function can be attached to a rule. Attaching rules are somewhat -more involved, let me illustrate this with an example. -

-

-replace { 
-     ljmp %5 
-%2:} by { 
-     sjmp
- %5 
-%2:} if labelInRange
- 
-
-

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. -

-Next -Previous -Contents - - diff --git a/doc/SDCCUdoc-7.html b/doc/SDCCUdoc-7.html deleted file mode 100644 index beacca59..00000000 --- a/doc/SDCCUdoc-7.html +++ /dev/null @@ -1,71 +0,0 @@ - - - - - SDCC Compiler User Guide: Pointers - - - - - -Next -Previous -Contents -
-

7. Pointers

- -

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. -

Pointer declaration examples. -

-

-/* 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;
- 
-
-

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. -

-

-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 */
- 
-
-

All unqualified pointers are treated as 3 - byte '_generic' pointers. These -type of pointers can also to be explicitly declared. -

-

-unsigned char _generic *ucgp;
- 
-
-

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. -

-Next -Previous -Contents - - diff --git a/doc/SDCCUdoc-8.html b/doc/SDCCUdoc-8.html deleted file mode 100644 index 30292d2a..00000000 --- a/doc/SDCCUdoc-8.html +++ /dev/null @@ -1,106 +0,0 @@ - - - - - SDCC Compiler User Guide: Parameters & Local Variables - - - - - -Next -Previous -Contents -
-

8. Parameters & Local Variables

- -

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. -

eg -

-

-unsigned short foo( short i) reentrant { 
-... 
-}
- 
-
-

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. -

When compiled with the default option (i.e. non-reentrant ), local variables -can be assigned storage classes and absolute addresses. -

eg -

-

-unsigned short foo() { 
-   xdata unsigned short i; 
-   bit bvar; 
- 
-  data at 0x31 unsiged short j; 
-... 
-}
- 
-
-

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. -

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. -

8.1 Overlaying -

- -

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. -

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. -

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. -

eg. -

-

-#pragma SAVE 
-#pragma NOOVERLAY 
-void set_error( unsigned short
- errcd) 
-{ 
-    P3 = errcd; 
-} 
-#pragma RESTORE 
-void some_isr
- () interrupt 2 using 1 
-{ 
-    ... 
-    set_error(10); 
-    ... 
-}
- 
-
-

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. -

-Next -Previous -Contents - - diff --git a/doc/SDCCUdoc-9.html b/doc/SDCCUdoc-9.html deleted file mode 100644 index db729e22..00000000 --- a/doc/SDCCUdoc-9.html +++ /dev/null @@ -1,37 +0,0 @@ - - - - - SDCC Compiler User Guide: critical Functions. - - - - - -Next -Previous -Contents -
-

9. critical Functions.

- -

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. -

eg -

-

-int foo () critical 
-{ 
-... 
-... 
-}
- 
-
-

The critical attribute maybe used with other attributes like reentrant. -

-Next -Previous -Contents - -