From: sandeep Date: Sun, 26 Mar 2000 20:58:47 +0000 (+0000) Subject: added documentation for --model-flat24 X-Git-Url: https://git.gag.com/?a=commitdiff_plain;h=682215e734247141844d57746381d7522240ba89;p=fw%2Fsdcc added documentation for --model-flat24 git-svn-id: https://sdcc.svn.sourceforge.net/svnroot/sdcc/trunk/sdcc@209 4a8a32a2-be11-0410-ad9d-d568d2c75423 --- diff --git a/doc/SDCCUdoc-1.html b/doc/SDCCUdoc-1.html index 41785023..ed05b3bb 100644 --- a/doc/SDCCUdoc-1.html +++ b/doc/SDCCUdoc-1.html @@ -1,7 +1,7 @@ - + SDCC Compiler User Guide: Introduction diff --git a/doc/SDCCUdoc-10.html b/doc/SDCCUdoc-10.html index 3de0515e..fb3fef79 100644 --- a/doc/SDCCUdoc-10.html +++ b/doc/SDCCUdoc-10.html @@ -1,7 +1,7 @@ - + SDCC Compiler User Guide: Absolute addressing. diff --git a/doc/SDCCUdoc-11.html b/doc/SDCCUdoc-11.html index 9e2c5831..6a2fb5f0 100644 --- a/doc/SDCCUdoc-11.html +++ b/doc/SDCCUdoc-11.html @@ -1,7 +1,7 @@ - + SDCC Compiler User Guide: Interrupt Service Routines diff --git a/doc/SDCCUdoc-12.html b/doc/SDCCUdoc-12.html index 4ba08b3b..60249336 100644 --- a/doc/SDCCUdoc-12.html +++ b/doc/SDCCUdoc-12.html @@ -1,7 +1,7 @@ - + SDCC Compiler User Guide: Startup Code diff --git a/doc/SDCCUdoc-13.html b/doc/SDCCUdoc-13.html index 757e4928..ffad944f 100644 --- a/doc/SDCCUdoc-13.html +++ b/doc/SDCCUdoc-13.html @@ -1,7 +1,7 @@ - + SDCC Compiler User Guide: Inline assembler code. diff --git a/doc/SDCCUdoc-14.html b/doc/SDCCUdoc-14.html index e6938bb3..d8e4f1a0 100644 --- a/doc/SDCCUdoc-14.html +++ b/doc/SDCCUdoc-14.html @@ -1,7 +1,7 @@ - + SDCC Compiler User Guide: int (16 bit) and long (32 bit ) support. diff --git a/doc/SDCCUdoc-15.html b/doc/SDCCUdoc-15.html index 612128e1..0cf81b23 100644 --- a/doc/SDCCUdoc-15.html +++ b/doc/SDCCUdoc-15.html @@ -1,7 +1,7 @@ - + SDCC Compiler User Guide: Floating point support @@ -39,7 +39,7 @@ 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). +above will need to recompiled with the --model-Large option)

Next Previous diff --git a/doc/SDCCUdoc-16.html b/doc/SDCCUdoc-16.html index 69eac941..2502743f 100644 --- a/doc/SDCCUdoc-16.html +++ b/doc/SDCCUdoc-16.html @@ -1,7 +1,7 @@ - + SDCC Compiler User Guide: Memory Models diff --git a/doc/SDCCUdoc-17.html b/doc/SDCCUdoc-17.html index 37874070..482dbfeb 100644 --- a/doc/SDCCUdoc-17.html +++ b/doc/SDCCUdoc-17.html @@ -1,8 +1,8 @@ - - SDCC Compiler User Guide: Defines created by the compiler. + + SDCC Compiler User Guide: Flat 24 bit addressing model. @@ -12,17 +12,42 @@ Previous Contents
-

17. Defines created by the compiler.

+

17. Flat 24 bit addressing model.

-

The compiler creates the following #defines . -

-

+

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 diff --git a/doc/SDCCUdoc-18.html b/doc/SDCCUdoc-18.html index 1a9bdc53..d9b24711 100644 --- a/doc/SDCCUdoc-18.html +++ b/doc/SDCCUdoc-18.html @@ -1,8 +1,8 @@ - - SDCC Compiler User Guide: Pragmas + + SDCC Compiler User Guide: Defines created by the compiler. @@ -12,81 +12,17 @@ Previous Contents
-

18. Pragmas

+

18. Defines created by the compiler.

-

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

The compiler creates the following #defines .

-

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 diff --git a/doc/SDCCUdoc-19.html b/doc/SDCCUdoc-19.html index 2f8614b4..8c23bdee 100644 --- a/doc/SDCCUdoc-19.html +++ b/doc/SDCCUdoc-19.html @@ -1,8 +1,8 @@ - - SDCC Compiler User Guide: Library routines. + + SDCC Compiler User Guide: Pragmas @@ -12,84 +12,81 @@ Previous Contents
-

19. Library routines.

+

19. Pragmas

-

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

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. 

-%[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.
+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 diff --git a/doc/SDCCUdoc-2.html b/doc/SDCCUdoc-2.html index 20526133..5820d30c 100644 --- a/doc/SDCCUdoc-2.html +++ b/doc/SDCCUdoc-2.html @@ -1,7 +1,7 @@ - + SDCC Compiler User Guide: Installation diff --git a/doc/SDCCUdoc-20.html b/doc/SDCCUdoc-20.html index 024b92f0..aaeeb627 100644 --- a/doc/SDCCUdoc-20.html +++ b/doc/SDCCUdoc-20.html @@ -1,8 +1,8 @@ - - SDCC Compiler User Guide: Interfacing with assembly routines. + + SDCC Compiler User Guide: Library routines. @@ -12,243 +12,84 @@ Previous Contents
-

20. Interfacing with assembly routines.

+

20. Library routines.

-

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

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

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

-

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

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

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

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

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 diff --git a/doc/SDCCUdoc-21.html b/doc/SDCCUdoc-21.html index 20a79076..142442f1 100644 --- a/doc/SDCCUdoc-21.html +++ b/doc/SDCCUdoc-21.html @@ -1,8 +1,8 @@ - - SDCC Compiler User Guide: External Stack. + + SDCC Compiler User Guide: Interfacing with assembly routines. @@ -12,18 +12,243 @@ Previous Contents
-

21. External Stack.

+

21. Interfacing with assembly routines.

-

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

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 diff --git a/doc/SDCCUdoc-22.html b/doc/SDCCUdoc-22.html index 90fbb02d..ea3a751b 100644 --- a/doc/SDCCUdoc-22.html +++ b/doc/SDCCUdoc-22.html @@ -1,8 +1,8 @@ - - SDCC Compiler User Guide: ANSI-Compliance. + + SDCC Compiler User Guide: External Stack. @@ -12,77 +12,18 @@ Previous Contents
-

22. ANSI-Compliance.

+

22. External Stack.

-

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()' */
- 
-
+

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 diff --git a/doc/SDCCUdoc-23.html b/doc/SDCCUdoc-23.html index 6191487f..79155e3e 100644 --- a/doc/SDCCUdoc-23.html +++ b/doc/SDCCUdoc-23.html @@ -1,8 +1,8 @@ - - SDCC Compiler User Guide: Cyclomatic Complexity + + SDCC Compiler User Guide: ANSI-Compliance. @@ -12,32 +12,77 @@ Previous Contents
-

23. Cyclomatic Complexity

+

23. ANSI-Compliance.

-

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

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. 
    -complexity = (number of edges in control flow graph) - 
-             (number
- of nodes in control flow graph) + 2;
+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()' */
-

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 diff --git a/doc/SDCCUdoc-24.html b/doc/SDCCUdoc-24.html index f757d6b0..b57f4cca 100644 --- a/doc/SDCCUdoc-24.html +++ b/doc/SDCCUdoc-24.html @@ -1,8 +1,8 @@ - - SDCC Compiler User Guide: TIPS + + SDCC Compiler User Guide: Cyclomatic Complexity @@ -12,104 +12,32 @@ Previous Contents
-

24. TIPS

+

24. Cyclomatic Complexity

-

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

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.

-

-

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

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 diff --git a/doc/SDCCUdoc-25.html b/doc/SDCCUdoc-25.html index 7809e017..c42b795f 100644 --- a/doc/SDCCUdoc-25.html +++ b/doc/SDCCUdoc-25.html @@ -1,8 +1,8 @@ - - SDCC Compiler User Guide: Retargetting for other MCUs. + + SDCC Compiler User Guide: TIPS @@ -12,59 +12,104 @@ Previous Contents
-

25. Retargetting for other MCUs.

+

25. TIPS

-

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

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.

-

    -
  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. 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'.
    7. +
  7. 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.
    8. +
  8. NEVER jump into a LOOP.
    9. +
  9. Declare the variables to be local whenever possible, especially loop control +variables (induction).
    10. +
  10. Since the compiler does not do implicit integral promotion, the programmer +should do an explicit cast when integral promotion is required.
    11. +
  11. Reducing the size of division , multiplication & modulus operations +can reduce code size substantially. Take the following code for example. +
    +foobar( unsigned int p1, unsigned char ch)
+{
+    unsigned char ch1
+ = p1 % ch ;
+    ....    
+}
+  
+
    + +

    For the modulus operation the variable ch will be promoted to unsigned +int first then the modulus operation will be performed (this will lead to a +call to a support routine). If the code is changed to + +

    +

    +foobar( unsigned int p1, unsigned char ch)
+{
+    unsigned char ch1
+ = (unsigned char)p1 % ch ;
+    ....    
+}
+  
+
    +

    It would substantially reduce the code generated (future versions of the +compiler will be smart enough to detect such optimization oppurtunities).

    12. -
  12. 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.
    13. -
  13. As mentioned in the optimization section the peep-hole optimizer is rule -based system, which can reprogrammed for other MCUs.
    14. -
+ +

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 diff --git a/doc/SDCCUdoc-26.html b/doc/SDCCUdoc-26.html index dfa33931..5a4ab36f 100644 --- a/doc/SDCCUdoc-26.html +++ b/doc/SDCCUdoc-26.html @@ -1,8 +1,8 @@ - - SDCC Compiler User Guide: Reporting Bugs + + SDCC Compiler User Guide: Retargetting for other MCUs. @@ -12,13 +12,59 @@ Previous Contents
-

26. Reporting Bugs

+

26. Retargetting for other MCUs.

-

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

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 diff --git a/doc/SDCCUdoc-27.html b/doc/SDCCUdoc-27.html index 8ec850ba..7c2da075 100644 --- a/doc/SDCCUdoc-27.html +++ b/doc/SDCCUdoc-27.html @@ -1,8 +1,8 @@ - - SDCC Compiler User Guide: SDCDB - Source level debugger. + + SDCC Compiler User Guide: Reporting Bugs @@ -12,233 +12,13 @@ Previous Contents
-

27. SDCDB - Source level debugger.

+

27. Reporting Bugs

-

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

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

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

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

27.4 Command line options. -

- -

-

-

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

27.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 
-;; 
-
- 
-
+

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 diff --git a/doc/SDCCUdoc-28.html b/doc/SDCCUdoc-28.html index cb2e167b..f5247e32 100644 --- a/doc/SDCCUdoc-28.html +++ b/doc/SDCCUdoc-28.html @@ -1,8 +1,8 @@ - - SDCC Compiler User Guide: Conclusion + + SDCC Compiler User Guide: SDCDB - Source level debugger. @@ -12,16 +12,233 @@ Previous Contents
-

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

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 diff --git a/doc/SDCCUdoc-29.html b/doc/SDCCUdoc-29.html index 0c6aa382..e05b0642 100644 --- a/doc/SDCCUdoc-29.html +++ b/doc/SDCCUdoc-29.html @@ -1,32 +1,29 @@ - - SDCC Compiler User Guide: Acknowledgments + + SDCC Compiler User Guide: Conclusion + -Next +Next Previous Contents
-

29. Acknowledgments

+

29. Conclusion

-

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

+

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 +Next Previous Contents diff --git a/doc/SDCCUdoc-3.html b/doc/SDCCUdoc-3.html index 841d9860..ef2fc5b9 100644 --- a/doc/SDCCUdoc-3.html +++ b/doc/SDCCUdoc-3.html @@ -1,7 +1,7 @@ - + SDCC Compiler User Guide: Compiling. diff --git a/doc/SDCCUdoc-4.html b/doc/SDCCUdoc-4.html index 7bcc9b40..92f8bbe1 100644 --- a/doc/SDCCUdoc-4.html +++ b/doc/SDCCUdoc-4.html @@ -1,7 +1,7 @@ - + SDCC Compiler User Guide: Command Line options @@ -24,6 +24,9 @@ are compiled with small model , they will need to be recompiled.
  • --model-small Generate code for Small Model programs see section Memory Models for more details. This is the default model.
    • +
  • --model-flat24 +--model-flat24Generate code for Small Model programs see section Memory +Models for more details. This is the default model.
  • --stack-auto All functions in the source file will be compiled as reentrant, i.e. the parameters and local variables will be allocated on the stack. see @@ -80,8 +83,8 @@ function the appropriate library function needs to be recompiled with the same option. If the project consists of multiple source files then all the source file should be compiled with the same --callee-saves option string. Also see Pragma Directive - CALLEE-SAVES. - .
    • + CALLEE-SAVES. + .
  • --debug When this option is used the compiler will generate debug information , that can be used with the SDCDB. The debug information is collected in a diff --git a/doc/SDCCUdoc-5.html b/doc/SDCCUdoc-5.html index 09b37924..1b8c6b99 100644 --- a/doc/SDCCUdoc-5.html +++ b/doc/SDCCUdoc-5.html @@ -1,7 +1,7 @@ - + SDCC Compiler User Guide: Language Extensions diff --git a/doc/SDCCUdoc-6.html b/doc/SDCCUdoc-6.html index a99ad6aa..355ad40f 100644 --- a/doc/SDCCUdoc-6.html +++ b/doc/SDCCUdoc-6.html @@ -1,7 +1,7 @@ - + SDCC Compiler User Guide: Optimizations diff --git a/doc/SDCCUdoc-7.html b/doc/SDCCUdoc-7.html index e7fa3fdc..beacca59 100644 --- a/doc/SDCCUdoc-7.html +++ b/doc/SDCCUdoc-7.html @@ -1,7 +1,7 @@ - + SDCC Compiler User Guide: Pointers diff --git a/doc/SDCCUdoc-8.html b/doc/SDCCUdoc-8.html index 8efb5dae..30292d2a 100644 --- a/doc/SDCCUdoc-8.html +++ b/doc/SDCCUdoc-8.html @@ -1,7 +1,7 @@ - + SDCC Compiler User Guide: Parameters & Local Variables diff --git a/doc/SDCCUdoc-9.html b/doc/SDCCUdoc-9.html index 4d9cfe1a..db729e22 100644 --- a/doc/SDCCUdoc-9.html +++ b/doc/SDCCUdoc-9.html @@ -1,7 +1,7 @@ - + SDCC Compiler User Guide: critical Functions. diff --git a/doc/SDCCUdoc.html b/doc/SDCCUdoc.html index ce4134ae..5b76eac9 100644 --- a/doc/SDCCUdoc.html +++ b/doc/SDCCUdoc.html @@ -1,7 +1,7 @@ - + SDCC Compiler User Guide @@ -86,13 +86,16 @@ Contents

    16. Memory Models

    -

    17. Defines created by the compiler.

    +

    17. Flat 24 bit addressing model.

    -

    18. Pragmas

    +

    18. Defines created by the compiler.

    -

    19. Library routines.

    +

    19. Pragmas

    + +

    +

    20. Library routines.

    @@ -172,44 +175,47 @@ then they will have to be recompiled with the appropriate compiler option.
 
    Have not had time to do the more involved routines like printf, will get
 to them shortly.
 
    
-
    20. Interfacing with assembly routines.
    
+
    21. Interfacing with assembly routines.
    
 
 
      
-
    • 20.1 Global registers used for parameter passing.
-
    • 20.2 With --noregparms option.
+
    • 21.1 Global registers used for parameter passing.
+
    • 21.2 With --noregparms option.
 
      
-
      21. External Stack.
      
+
      22. External Stack.
      
 
 
      
-
      22. ANSI-Compliance.
      
+
      23. ANSI-Compliance.
      
 
 
      
-
      23. Cyclomatic Complexity
      
+
      24. Cyclomatic Complexity
      
 
 
      
-
      24. TIPS
      
+
      25. TIPS
      
 
 
      
-
      25. Retargetting for other MCUs.
      
+
      26. Retargetting for other MCUs.
      
 
 
      
-
      26. Reporting Bugs
      
+
      27. Reporting Bugs
      
 
 
      
-
      27. SDCDB - Source level debugger.
      
+
      28. SDCDB - Source level debugger.
      
 
 
        
-
      • 27.1 Compiling for debugging.
-
      • 27.2 How the debugger works.
-
      • 27.3 Starting the debugger.
-
      • 27.4 Command line options.
-
      • 27.5 Debugger Commands.
-
      • 27.6 Interfacing with XEmacs.
+
      • 28.1 Compiling for debugging.
+
      • 28.2 How the debugger works.
+
      • 28.3 Starting the debugger.
+
      • 28.4 Command line options.
+
      • 28.5 Debugger Commands.
+
      • 28.6 Interfacing with XEmacs.
+
        
+
        29. Conclusion
        
+
 
        
-
        28. Conclusion
        
+
        30. Acknowledgments
        
 
 
        
-
        29. Acknowledgments
        
+
        31. Appendix A: The Z80 and gbz80 port
        
 
 
        
 Next
diff --git a/doc/SDCCUdoc.lyx b/doc/SDCCUdoc.lyx
index 819186fb..7fe7d109 100644
--- a/doc/SDCCUdoc.lyx
+++ b/doc/SDCCUdoc.lyx
@@ -1,4 +1,5 @@
-#LyX 1.1 created this file. For more info see http://www.lyx.org/
+#This file was created by  Sun Mar 26 12:40:23 2000
+#LyX 1.0 (C) 1995-1999 Matthias Ettrich and the LyX Team
 \lyxformat 2.15
 \textclass linuxdoc
 \language english
@@ -1456,6 +1457,27 @@ Generate code for Small Model programs see section Memory Models for more
 \layout Itemize
 
 
+\series bold 
+\size large 
+\bar under 
+--model-flat24
+\series default 
+\emph on 
+\bar default 
+ 
+\size default 
+\emph default 
+
+\begin_inset LatexCommand \ref[--model-flat24]{--model-flat24}
+
+\end_inset 
+
+Generate code for Small Model programs see section Memory Models for more
+ details.
+ This is the default model.
+\layout Itemize
+
+
 \series bold 
 \size large 
 \bar under 
@@ -5602,7 +5624,7 @@ 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).
+ will need to recompiled with the --model-Large option)
 \layout Section
 
 Memory Models
@@ -5635,6 +5657,78 @@ Judicious usage of the processor specific storage classes and the 'reentrant'
  be used unless absolutely required.
 \layout Section
 
+Flat 24 bit addressing model.
+\begin_inset LatexCommand \label{--model-flat24}
+
+\end_inset 
+
+
+\layout Standard
+
+This option generates code for the 24 bit contiguous addressing mode of
+ the Dallas DS80C390 part.
+ In this mode, up to four meg of external RAM or code space can be directly
+ addressed.
+ See the data sheets at www.dalsemi.com for further information on this part.
+\layout Standard
+
+Note that the compiler does not generate any code to place the processor
+ into this mode (it defaults to 8051 compatible mode).
+ Boot loader or similar code must ensure that the processor is in 24 bit
+ contiguous addressing mode before calling the SDCC startup code.
+\layout Standard
+
+Like the --model-large option, variables will by default be placed into
+ the XDATA segment.
+ However, a current limitation is that the compiler will spill variables
+ into the DATA segment when it runs out of registers.
+ This means that compiling complex code can rapidly fill up the DATA segment.
+ This limitation is being worked on, and should be addressed in the next
+ release of sdcc.
+\layout Standard
+
+Segments may be placed anywhere in the 4 meg address space using the usual
+ --*-loc options.
+ Note that if any segments are located above 64K, the -r flag must be passed
+ to the linker to generate the proper segment relocations, and the Intel
+ HEX output format must be used.
+ The -r flag can be passed to the linker by using the option -Wl-r on the
+ sdcc command line.
+\layout Standard
+
+--stack-10bit:
+\layout Standard
+
+This option generates code for the 10 bit stack mode of the Dallas DS80C390
+ part.
+ In this mode, the stack is located in the lower 1K of the internal RAM,
+ which is mapped to 0x400000.
+\layout Standard
+
+With this option, sdcc will generate the proper addressing for stack variables.
+\layout Standard
+
+Note that the support is incomplete, since it still uses a single byte as
+ the stack pointer.
+ This means that only the lower 256 bytes of the potential 1K stack space
+ can actually be used.
+ However, this does allow you to reclaim the precious 256 bytes of low RAM
+ for use for the DATA and IDATA segments.
+\layout Standard
+
+The compiler will not generate any code to put the processor into 10 bit
+ stack mode.
+ It is important to ensure that the processor is in this mode before calling
+ any re-entrant functions compiled with this option.
+\layout Standard
+
+In principle, this should work with the --stack-auto option, but that has
+ not been tested.
+ It is incompatible with the --xstack option.
+ It also only makes sense if the processor is in 24 bit contiguous addressing
+ mode (see the --model-flat24 option).
+\layout Section
+
 Defines created by the compiler.
 \begin_inset LatexCommand \label{Defines.}
 
@@ -11665,7 +11759,7 @@ As always, the code is the authoritave reference - see z80/ralloc.c and z80/gen.
 \layout Standard
 
 
-\begin_inset LatexCommand \index{}
+\begin_inset LatexCommand \index
 
 \end_inset 
 
diff --git a/doc/SDCCUdoc.sgml b/doc/SDCCUdoc.sgml
index f4bfeacf..a7d5bac0 100644
--- a/doc/SDCCUdoc.sgml
+++ b/doc/SDCCUdoc.sgml
@@ -1,6 +1,6 @@
 
 
-
 
  
@@ -481,6 +481,8 @@ share/
  should be compiled with this option. In addition the standard library routines
  are compiled with small model , they will need to be recompiled.
   --model-small