This is an excerpt from an article published in Circuit Cellar
Magazine in August 2000. It's a little
outdated (the compiler is much more efficient now and user/developer
friendly), but pretty well exposes the guts of it all.
The current version of SDCC can generate code for Intel 8051 and Z80
MCU. It is fairly easy to retarget for other 8-bit MCU. Here we take
a look at some of the internals of the compiler.
Parsing the input source file and creating an AST (Annotated Syntax Tree). This phase also involves propagating types (annotating each node of the parse tree with type information) and semantic analysis. There are some MCU specific parsing rules. For example the storage classes, the extended storage classes are MCU specific while there may be a xdata storage class for 8051 there is no such storage class for z80 or Atmel AVR. SDCC allows MCU specific storage class extensions, i.e. xdata will be treated as a storage class specifier when parsing 8051 C code but will be treated as a C identifier when parsing z80 or ATMEL AVR C code.
Intermediate code generation. In this phase the AST is broken down into three-operand form (iCode). These three operand forms are represented as doubly linked lists. ICode is the term given to the intermediate form generated by the compiler. ICode example section shows some examples of iCode generated for some simple C source functions.
Bulk of the target independent optimizations is performed in this phase. The optimizations include constant propagation, common sub-expression elimination, loop invariant code movement, strength reduction of loop induction variables and dead-code elimination.
During intermediate code generation phase, the compiler assumes the target machine has infinite number of registers and generates a lot of temporary variables. The live range computation determines the lifetime of each of these compiler-generated temporaries. A picture speaks a thousand words. ICode example sections show the live range annotations for each of the operand. It is important to note here, each iCode is assigned a number in the order of its execution in the function. The live ranges are computed in terms of these numbers. The from number is the number of the iCode which first defines the operand and the to number signifies the iCode which uses this operand last.
The register allocation determines the type and number of registers needed by each operand. In most MCUs only a few registers can be used for indirect addressing. In case of 8051 for example the registers R0 & R1 can be used to indirectly address the internal ram and DPTR to indirectly address the external ram. The compiler will try to allocate the appropriate register to pointer variables if it can. ICode example section shows the operands annotated with the registers assigned to them. The compiler will try to keep operands in registers as much as possible; there are several schemes the compiler uses to do achieve this. When the compiler runs out of registers the compiler will check to see if there are any live operands which is not used or defined in the current basic block being processed, if there are any found then it will push that operand and use the registers in this block, the operand will then be popped at the end of the basic block.
There are other MCU specific considerations in this phase. Some MCUs have an accumulator; very short-lived operands could be assigned to the accumulator instead of a general-purpose register.
Figure II gives a table of iCode operations supported by the compiler. The code generation involves translating these stly taypecasted unless the --std-c89 or --std-c99 command line options are used.
void vararg_func (char *str, ...) { str; }
void main (void)
{
char c = 10;
/* argument u is promoted to int before
* passing to function */
vararg_func ("%c", c);
/* argument u is not promoted to int,
* it is passed as char to function
* if -std-cXX is not defined;
* is promoted to int before passing
* to function if -std-cXX is defined */
vararg_func ("%bc", (char)u);
}
Bdale Garbee 2008-05-15