From: kbongers Date: Wed, 4 Jul 2001 05:22:22 +0000 (+0000) Subject: updates, lyx conversions X-Git-Url: https://git.gag.com/?a=commitdiff_plain;h=7c4864abd20761f654c879b34752687088d20b18;p=fw%2Fsdcc updates, lyx conversions git-svn-id: https://sdcc.svn.sourceforge.net/svnroot/sdcc/trunk/sdcc@1023 4a8a32a2-be11-0410-ad9d-d568d2c75423 --- diff --git a/doc/SDCCUdoc.html b/doc/SDCCUdoc.html index 17638654..9d225cec 100644 --- a/doc/SDCCUdoc.html +++ b/doc/SDCCUdoc.html @@ -46,138 +46,140 @@ Contents @@ -212,15 +214,15 @@ copy propagation, dead code elimination and jumptables for 'switch' statements. For the back-end SDCC uses a global register allocation scheme which should be well suited for other 8 bit MCUs. The peep hole optimizer uses a rule based substitution mechanism which is MCU -independent. Supported data-types are short (8 bits, 1 byte), -char (8 bits, 1 byte), int (16 bits, 2 bytes ), long (32 bit, 4 bytes) -& float (4 byte IEEE). The compiler also allows inline assembler -code to be embedded anywhere in a function. In addition routines -developed in assembly can also be called. SDCC also provides an option -to report the relative complexity of a function, these functions can -then be further optimized, or hand coded in assembly if need be. SDCC -also comes with a companion source level debugger SDCDB, the debugger -currently uses ucSim a freeware simulator for 8051 and other micro-controllers. +dependent. Supported data-types are char (8 bits, 1 byte), short +and int (16 bits, 2 bytes ), long (32 bit, 4 bytes) and float +(4 byte IEEE). The compiler also allows inline assembler code +to be embedded anywhere in a function. In addition routines developed +in assembly can also be called. SDCC also provides an option to report +the relative complexity of a function, these functions can then be +further optimized, or hand coded in assembly if needed. SDCC also +comes with a companion source level debugger SDCDB, the debugger currently +uses ucSim a freeware simulator for 8051 and other micro-controllers. The latest version can be downloaded from http://sdcc.sourceforge.net/.

@@ -276,7 +278,7 @@ place to find distribution sets. You can also find links to the user mailing lists that offer help or discuss SDCC with other SDCC users. Web links to other SDCC related sites can also be found here. This document can be found in the DOC directory of the source package as -a text or HTML file. Some of the other tools(simulator and assembler) +a text or HTML file. Some of the other tools (simulator and assembler) included with SDCC contain their own documentation and can be found in the source distribution. If you want the latest unreleased software, the complete source package is available directly by anonymous CVS @@ -393,14 +395,14 @@ the program should run and tell you the version. If it doesn't run, or gives a message about not finding sdcc program, then you need to check over your installation. Make sure that the sdcc bin directory is in your executable search path defined by the PATH environment -setting(see the Trouble-shooting section for suggestions). Make sure +setting (see the Trouble-shooting section for suggestions). Make sure that the sdcc program is in the bin folder, if not perhaps something did not install correctly.

SDCC binaries are commonly installed in a directory arrangement like this: - +

@@ -413,17 +415,23 @@ this:
/usr/local/binHolds common C header files
- -

+
+
Make sure the compiler works on a very simple example. Type in the following test.c program using your favorite editor: +
+
main()  +
{ + +

+int i;

-main() -
{ int i; -
i = 0; -
i += 10; -
} +i = 0; + +

+i += 10;  +
}

Compile this using the following command: ``sdcc -c test.c''. @@ -435,28 +443,33 @@ code, just to keep things simple for this step.

The next step is to try it with the linker. Type in ``sdcc test.c''. If all goes well the compiler will link with the libraries and produce -a test.ihx output file. If this step fails(no test.ihx, and the linker +a test.ihx output file. If this step fails (no test.ihx, and the linker generates warnings), then the problem is most likely that sdcc cannot -find the usr/local/share/sdcc/lib/small directory(see the Install -trouble-shooting section for suggestions). +find the /usr/local/share/sdcc/lib directory (see the Install trouble-shooting +section for suggestions).

The final test is to ensure sdcc can use the standard header files and libraries. Edit test.c and change it to the following: +
+
#include <string.h>  +
main()  +
{

-#include <string.h> -
main() -
{ char str1[10]; -
strcpy(str1, ``testing''); -
} +char str1[10]; +

+strcpy(str1, ``testing'');  +
  +
} +

Compile this by typing: ``sdcc test.c''. This should generate a test.ihx output file, and it should give no warnings such as not finding the string.h file. If it cannot find the string.h file, then the problem is that sdcc cannot find the /usr/local/share/sdcc/include -directory(see the Install trouble-shooting section for suggestions). +directory (see the Install trouble-shooting section for suggestions).

@@ -484,17 +497,15 @@ test.c

-A few things to try include starting from scratch by unpacking the -.tgz source package again in an empty directory. If this doesn't work, -you could try downloading a different version. If this doesn't work, -you can re-direct the install messages by doing the following: +A thing to try is starting from scratch by unpacking the .tgz source +package again in an empty directory. Confure it again and build like:

-$./make > dump.txt 2>&1 +``make 2SPMamp;>1 | tee make.log''

-After this you can examine the dump.txt files to locate the problem. -Or these messages can be attached to an email that could be helpful +After this you can review the make.log file to locate the problem. +Or a relevant part of this be attached to an email that could be helpful when requesting help from the mailing list.

@@ -764,7 +775,7 @@ at <http://mazsola.iit.uni-miskolc.hu/drdani/embedded/s51/>.

-SDCDB is the companion source level debugger . The current version +SDCDB is the companion source level debugger. The current version of the debugger uses Daniel's Simulator S51, but can be easily changed to use other simulators. @@ -832,11 +843,13 @@ created by the Linker.

-

  • sourcefile.<ihx | s19> - The load module : ihx - Intel -hex format (default ), s19 - Motorola S19 format when compiler option --out-fmt-s19 is used. +
  • sourcefile.ihx - The load module in Intel hex format +(you can select the Motorola S19 format with -out-fmt-s19)

    +

    • +
  • sourcefile.cdb - An optional file (with -debug) containing debug +information.
    • @@ -920,7 +933,8 @@ created in this manner may be included using the command line, make sure you include the -L <library-path> option to tell the linker where to look for these files. Here is an example, assuming you have the source file 'foomain.c' and a library 'foolib.lib' in -the directory 'mylib'. +the directory 'mylib' (if that is not the same as your current +project).

    sdcc foomain.c foolib.lib -L mylib @@ -973,109 +987,143 @@ development, not complete).

    -3.2.2 Path, Lib and Define Options +3.2.2 Preprocessor Options

    -3.2.3 MCS51 Options +3.2.3 Linker Options

    +

    +-lib-path(-L) <absolute path to additional libraries> This +option is passed to the linkage editor's additional libraries search +path. The path name must be absolute. Additional library files may +be specified in the command line. See section Compiling programs for +more details. + +

    +-xram-loc<Value> The start location of the external ram, +default value is 0. The value entered can be in Hexadecimal or Decimal +format, e.g.: -xram-loc 0x8000 or -xram-loc 32768. +

    -3.2.4 Optimization Options +3.2.4 MCS51 Options

    +

    + +

    +3.2.5 Optimization Options +

    + +

    + +

    -

    -3.2.5 DS390 Options +

    +3.2.6 DS390 Options

    @@ -1083,254 +1131,210 @@ option as well.

    -

    -3.2.6 Other Options +

    +3.2.7 Other Options

    -

    -3.2.7 Intermediate Dump Options +

    +3.2.8 Intermediate Dump Options

    The following options are provided for the purpose of retargetting -and debugging the compiler . These provided a means to dump the intermediate +and debugging the compiler. These provided a means to dump the intermediate code (iCode) generated by the compiler in human readable form at various stages of the compilation process.

    Note that the files created for the dump are appended to each time. -So the files should be deleted manually , before each dump is created. - -

    -When reporting bugs, it can be helpful to include these dumps along -with the portion of the code that is causing the problem. - +

  • [-dumplrange]Will create a dump of the live ranges of iTemp's +
    • +
  • [-dumpall]Will cause all the above mentioned dumps to be +created. +
    • +

    -3.3 MCS51 Storage Class Language Extensions +3.3 MCS51/DS390 Storage Class Language Extensions

    @@ -1345,13 +1349,10 @@ MCS51 specific storage classes.

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

    - +RAM. This is the default storage class for Large Memory model, +e.g.: +
    +
    xdata unsigned char xduc;

    @@ -1362,12 +1363,9 @@ RAM. This is the default storage class for Large Memory model

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

    - +internal RAM, e.g.: +
    +
    data int iramdata;

    @@ -1377,12 +1375,10 @@ internal RAM.

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

    - +the indirectly addressable portion of the internal ram of a 8051, +e.g.: +
    +
    idata int idi;

    @@ -1393,10 +1389,9 @@ the indirectly addressable portion of the internal ram of a 8051 .

    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; +of 8051, e.g.: +
    +
    bit iFlag;

    @@ -1407,17 +1402,11 @@ eg.bit iFlag;

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

    @@ -1429,66 +1418,49 @@ LOCATION 0X80 */ 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. - -

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

    - - -

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

    - - -

    +of the compiler, the following syntax for pointer declaration is still +supported but will disappear int the near future. +
    +
    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 (4-byte for the ds390) +'_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 @@ -1508,21 +1480,14 @@ 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 { -
    ... -
    } -

    - - -

    +using the 'reentrant' keyword in the function declaration, e.g.: +
    +
    unsigned char foo( char 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 @@ -1532,22 +1497,23 @@ 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. +variables can be assigned storage classes and absolute addresses, +e.g.: (jwk: pending: this is obsolete and need a rewrite) +
    +
    unsigned char foo() {

    -eg -

    - +xdata unsigned char i;

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

    +data at 0x31 unsiged char j; +

    +...   +
    }

    In the above example the variable i will be allocated in the @@ -1590,66 +1556,307 @@ 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. +implemented using external functions, e.g.: +
    +
    #pragma SAVE   +
    #pragma NOOVERLAY   +
    void set_error( unsigned char errcd)   +
    {

    -eg. +P3 = errcd;  +
    }   +
    #pragma RESTORE   +
    void some_isr () interrupt 2 using 1   +
    {

    -#pragma SAVE -
    #pragma NOOVERLAY -
    void set_error( unsigned short errcd) +... + +

    +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 +when called from an ISR. The pragma NOOVERLAY ensures that the parameters +and local variables for the function are NOT overlayed. + +

    + +

    +3.7 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
    { -
        P3 = errcd; -
    } -
    #pragma RESTORE -
    void some_isr () 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 #DescriptionVector Address
    0External 00x0003
    1Timer 00x000B
    2External 10x0013
    3Timer 10x001B
    4Serial0x0023
    +
    +

    +If the interrupt service routine is defined without 'using' +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. + +

    + +

    +3.8 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
    { -
        ... -
        set_error(10); -
        ... +
    ... +
    ...
    } +
    +
    +The critical attribute maybe used with other attributes like reentrant. + +

    + +

    +3.9 Naked Functions +

    + +

    +A special keyword may be associated with a function declaring it as +'_naked'. The '_naked' function modifier attribute +prevents the compiler from generating prologue and epilogue code for +that function. This means that the user is entirely responsible for +such things as saving any registers that may need to be preserved, +selecting the proper register bank, generating the 'return' +instruction at the end, etc. Practically, this means that the contents +of the function must be written in inline assembler. This is particularly +useful for interrupt functions, which can have a large (and often +unnecessary) prologue/epilogue. For example, compare the code generated +by these two functions: +
    +
    +data unsigned char counter; +
    +void simpleIterrupt(void) interrupt 1 +
    { + +

    +counter++; +
    } +
    +
    +void nakedInterrupt(void) interrupt 2 _naked +
    { + +

    +_asm + +

    +   inc  _counter + +

    +   reti         ; MUST explicitly include ret in _naked +function. + +

    +_endasm; +
    } +
    +
    +For an 8051 target, the generated simpleInterrupt looks like: +
    +
    +_simpleIterrupt: + +

    +push    acc + +

    +push    b + +

    +push    dpl + +

    +push    dph + +

    +push    psw + +

    +mov     psw,#0x00 + +

    +inc     _counter + +

    +pop     psw + +

    +pop     dph + +

    +pop     dpl + +

    +pop     b +

    +pop     acc +

    +reti +
    +
    +whereas nakedInterrupt looks like: +
    +
    +_nakedInterrupt:

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

    +reti         ; MUST explicitly include ret(i) in _naked function. +
    +
    +While there is nothing preventing you from writing C code inside a +_naked function, there are many ways to shoot yourself in the foot +doing this, and is is recommended that you stick to inline assembler.

    -

    -3.7 Critical Functions +

    +3.10 Functions using private banks

    -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. +The 'using' attribute (which tells the compiler to use a register +bank other than the default bank zero) should only be applied to 'interrupt' +functions (see note A below). This will in most circumstances make +the generated ISR code more efficient since it will not have to save +registers on the stack.

    -eg +The 'using' attribute will have no effect on the generated +code for a non-'interrupt' function (but may occasionally be +useful anyway1). +
    (jwk: todo: I don't think this has been done yet)

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

    - +An 'interrupt' function using a non-zero bank will assume that it +can trash that register bank, and will not save it. Since high-priority +interrupts can interrupt low-priority ones on the 8051 and friends, +this means that if a high-priority ISR 'using' a particular bank occurs +while processing a low-priority ISR 'using' the same bank, terrible +and bad things can happen. To prevent this, no single register bank +should be 'used' by both a high priority and a low priority ISR. This +is probably most easily done by having all high priority ISRs use +one bank and all low priority ISRs use another. If you have an ISR +which can change priority at runtime, you're on your own: I suggest +using the default bank zero and taking the small performance hit.

    -The critical attribute maybe used with other attributes like reentrant. +It is most efficient if your ISR calls no other functions. If your +ISR must call other functions, it is most efficient if those functions +use the same bank as the ISR (see note A below); the next best is +if the called functions use bank zero. It is very inefficient to call +a function using a different, non-zero bank from an ISR.

    -

    -3.8 Absolute Addressing +

    +3.11 Absolute Addressing

    @@ -1699,101 +1906,8 @@ over all the variables allocated.

    -

    -3.9 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 #DescriptionVector Address
    0External 00x0003
    1Timer 00x000B
    2External 10x0013
    3Timer 10x001B
    4Serial0x0023
    - -

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

    - -

    -3.10 Startup Code +

    +3.12 Startup Code

    @@ -1810,8 +1924,8 @@ hardware or perform some other critical operation prior to static

    -

    -3.11 Inline Assembler Code +

    +3.13 Inline Assembler Code

    @@ -1844,7 +1958,7 @@ carefully before using this option.

    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 +lines). The compiler does not do any validation of the code within the _asm ... _endasm; keyword pair.

    @@ -1882,8 +1996,8 @@ assembly CANNOT be accessed by C statements.

    -

    -3.12 int(16 bit) and long (32 bit ) Support +

    +3.14 int(16 bit) and long (32 bit ) Support

    @@ -1955,8 +2069,8 @@ option, after which the source program will have to be compiled with

    -

    -3.13 Floating Point Support +

    +3.15 Floating Point Support

    @@ -2040,8 +2154,8 @@ mentioned above will need to recompiled with the -model-Large option)

    -

    -3.14 MCS51 Memory Models +

    +3.16 MCS51 Memory Models

    @@ -2069,8 +2183,8 @@ recommdended that the small model be used unless absolutely required.

    -

    -3.15 Flat 24 bit Addressing Model +

    +3.17 Flat 24 bit Addressing Model

    @@ -2108,12 +2222,12 @@ on the sdcc command line.

    -

    -3.16 Defines Created by the Compiler +

    +3.18 Defines Created by the Compiler

    -The compiler creates the following #defines . +The compiler creates the following #defines.

    @@ -2272,7 +2386,7 @@ will be changed to

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

    @@ -2288,7 +2402,7 @@ 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 +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 @@ -2394,8 +2508,8 @@ within the loop. 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. +it is advantageous to declare loop control symbols as either 'char', +ofcourse this may not be possible on all situations.

    @@ -2513,7 +2627,7 @@ If the above switch statement is broken down into two switch statements

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

    @@ -2523,14 +2637,14 @@ whereas the unmodified switch statement will not be .

    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. +programming. SDCC tries to implement bit-shift operations in the most +efficient way possible.

    eg.

    -unsigned short i; +unsigned char i;

    @@ -2610,10 +2724,10 @@ will generate the following code.

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

    @@ -2623,7 +2737,7 @@ SDCC uses pattern matching on the parse tree to determine this operation

    It is frequently required to obtain the highest order bit of an integral -type (int,long,short or char types). SDCC recognizes the following +type (long, int, short or char types). SDCC recognizes the following expression to yield the highest order bit and generates optimized code for it. @@ -2659,7 +2773,7 @@ mov  _foo_hob_1_1,a

    -Variations of this case however will NOT be recognized . It is a standard +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. @@ -2685,7 +2799,7 @@ will still be recognized.

    The compiler uses a rule based , pattern matching and re-writing mechanism -for peep-hole optimization . It is inspired by 'copt' a peep-hole +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 @@ -2856,7 +2970,7 @@ are applicable only at a function level.