sdccman.txt

很少见的源码公开的msc51和z80的c编译器。

The inline assembler code can contain any valid code understood
by the assembler, this includes any assembler directives
and comment lines. The compiler does not do any validation
of the code within the _asm ... _endasm; keyword pair. 

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

foo() { 
    /* some c code */ 
    _asm 
      ; some assembler code 
      ljmp $0003 
    _endasm; 
    /* some more c code */ 
clabel:  /* inline assembler cannot reference
this label */ 
    _asm
    $0003: ;label (can be reference by inline assembler
only) 
    _endasm ; 
    /* some more c code */
}

In other words inline assembly code can access labels defined
in inline assembly within the scope of the funtion. 

The same goes the other way, ie. labels defines in inline
assembly CANNOT be accessed by C statements.

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

For signed & unsigned int (16 bit) and long (32 bit) variables,
division, multiplication and modulus operations are implemented
by support routines. These support routines are all developed
in ANSI-C to facilitate porting to other MCUs, although
some model specific assembler optimations are used. The
following files contain the described routine, all of them
can be found in <installdir>/share/sdcc/lib.

<pending: tabularise this>

_mulsint.c - signed 16 bit multiplication (calls _muluint)
_muluint.c - unsigned 16 bit multiplication
_divsint.c - signed 16 bit division (calls _divuint)
_divuint.c - unsigned 16 bit division
_modsint.c - signed 16 bit modulus (call _moduint)
_moduint.c - unsigned 16 bit modulus
_mulslong.c - signed 32 bit multiplication (calls _mululong)
_mululong.c - unsigned32 bit multiplication
_divslong.c - signed 32 division (calls _divulong)
_divulong.c - unsigned 32 division
_modslong.c - signed 32 bit modulus (calls _modulong)
_modulong.c - unsigned 32 bit modulus 

Since they are compiled as non-reentrant, interrupt service
routines should not do any of the above operations. If this
is unavoidable then the above routines will need to be compiled
with the --stack-auto option, after which the source program
will have to be compiled with --int-long-rent option.

 Floating Point Support

SDCC supports IEEE (single precision 4bytes) floating point
numbers.The floating point support routines are derived
from gcc's floatlib.c and consists of the following routines:

<pending: tabularise this>

_fsadd.c - add floating point numbers
_fssub.c - subtract floating point numbers
_fsdiv.c - divide floating point numbers
_fsmul.c - multiply floating point numbers
_fs2uchar.c - convert floating point to unsigned char
_fs2char.c - convert floating point to signed char
_fs2uint.c - convert floating point to unsigned int
_fs2int.c - convert floating point to signed int
_fs2ulong.c - convert floating point to unsigned long
_fs2long.c - convert floating point to signed long
_uchar2fs.c - convert unsigned char to floating point
_char2fs.c - convert char to floating point number
_uint2fs.c - convert unsigned int to floating point
_int2fs.c - convert int to floating point numbers
_ulong2fs.c - convert unsigned long to floating point number
_long2fs.c - convert long to floating point number

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.

 MCS51 Memory Models

SDCC allows two memory models for MCS51 code, small and large.
Modules compiled with different memory models should never
be combined together or the results would be unpredictable.
The library routines supplied with the compiler are compiled
as both small and large. The compiled library modules are
contained in seperate directories as small and large so
that you can link to either set. 

When the large model is used all variables declared without
a storage class will be allocated into the external ram,
this includes all parameters and local variables (for non-reentrant
functions). When the small model is used variables without
storage class are allocated in the internal ram.

Judicious usage of the processor specific storage classes
and the 'reentrant' function type will yield much more efficient
code, than using the large model. Several optimizations
are disabled when the program is compiled using the large
model, it is therefore strongly recommdended that the small
model be used unless absolutely required.

 DS390 Memory Models

The only model supported is Flat 24. This 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.

In older versions of the compiler, this option was used with
the MCS51 code generator (-mmcs51). Now, however, the '390
has it's own code generator, selected by the -mds390 switch.


Note that the compiler does not generate any code to place
the processor into 24 bitmode (although tinibios in the
ds390 libraries will do that for you). If you don't use
tinibios, the 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. 

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. However, currently the linker can not handle
code segments > 64k.

 Defines Created by the Compiler

The compiler creates the following #defines.

 SDCC - this Symbol is always defined.

 SDCC_mcs51 or SDCC_ds390 or SDCC_z80, etc - depending on
  the model used (e.g.: -mds390)

 __mcs51 or __ds390 or __z80, etc - depending on the model
  used (e.g. -mz80)

 SDCC_STACK_AUTO - this symbol is defined when --stack-auto
  option is used.

 SDCC_MODEL_SMALL - when --model-small is used.

 SDCC_MODEL_LARGE - when --model-large is used.

 SDCC_USE_XSTACK - when --xstack option is used.

 SDCC_STACK_TENBIT - when -mds390 is used

 SDCC_MODEL_FLAT24 - when -mds390 is used

 SDCC Technical Data

 Optimizations

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

 Sub-expression Elimination

The compiler does local and global common subexpression elimination,
e.g.: 

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

will be translated to

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

Some subexpressions are not as obvious as the above example,
e.g.:

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

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

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

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

 Dead-Code Elimination

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

will be changed to

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

 Copy-Propagation

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

will be changed to 

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

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

 Loop Optimizations

Two types of loop optimizations are done by SDCC loop invariant
lifting and strength reduction of loop induction variables.
In addition to the strength reduction the optimizer marks
the induction variables and the register allocator tries
to keep the induction variables in registers for the duration
of the loop. Because of this preference of the register
allocator, loop induction optimization causes an increase
in register pressure, which may cause unwanted spilling
of other temporary variables into the stack / data space.
The compiler will generate a warning message when it is
forced to allocate extra space either on the stack or data
space. If this extra space allocation is undesirable then
induction optimization can be eliminated either for the
entire source file (with --noinduction option) or for a
given function only using #pragma NOINDUCTION.

Loop Invariant:

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

changed to

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

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

Strength Reduction, this optimization substitutes an expression
by a cheaper expression:

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

changed to

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

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

 Loop Reversing

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

 The 'for' loop is of the form 
  
  for (<symbol> = <expression> ; <sym> [< | <=] <expression>
  ; [<sym>++ | <sym> += 1])
      <for body>

 The <for body> does not contain "continue"
  or 'break".

 All goto's are contained within the loop.

 No function calls within the loop.

 The loop control variable <sym> is not assigned any value
  within the loop

 The loop control variable does NOT participate in any arithmetic
  operation within the loop.

 There are NO switch statements in the loop.

Note djnz instruction can be used for 8-bit values only,
therefore it is advantageous to declare loop control symbols
as char. Ofcourse this may not be possible on all situations.

 Algebraic Simplifications

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

i = j + 0 ; /* changed to */ i = j; 
i /= 2; /* changed to */ i >>= 1; 
i = j - j ; /* changed to */ i = 0; 
i = j / 1 ; /* changed to */ i = j;

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

 'switch' Statements

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

 The case labels are in numerical sequence, the labels need
  not be in order, and the starting number need not be one
  or zero.
  
  switch(i) {     
             
         switch (i) { 
  case 4:...      
             
         case 1: ... 
  case 5:...      
             
         case 2: ... 
  case 3:...      
             
         case 3: ... 
  case 6:...      
             
         case 4: ... 
  }           
             
             }
  
  Both