SDCC Home News Platforms Download Support Who Snapshots Linux Windows Mac OS X Documentation Source Documentation SDCC Manual (html/pdf) Test Suite (html/pdf) CDB Format (html/pdf) Anatomy of a Compiler - A Retargetable ANSI-C Compiler SDCC at SourceForge SDCC File Releases SDCC Subversion Repository SDCC Wiki Links and More! SDCC Metrics by Ohloh

SDCC Manual 6.1 Porting code from or to other compilers check whether endianness of the compilers differs and adapt where needed. check the device specific header files for compiler specific syntax. Eventually include the file <compiler.h> http://sdcc.svn.sourceforge.net/viewvc/sdcc/trunk/sdcc/device/include/mcs51/compiler.h?view=markup to allow using common header files. (see f.e. cc2510fx.h http://sdcc.svn.sourceforge.net/viewvc/sdcc/trunk/sdcc/device/include/mcs51/cc2510fx.h?view=markup). check whether the startup code contains the correct initialization (watchdog, peripherals). check whether the sizes of short, int, long match. check if some 16 or 32 bit hardware registers require a specific addressing order (least significant or most significant byte first) and adapt if needed (first and last relate to time and not to lower/upper memory location here, so this is not the same as endianness). check whether the keyword volatile is used where needed. The compilers might differ in their optimization characteristics (as different versions of the same compiler might also use more clever optimizations this is good idea anyway). See section 3.8.1.1. check that the compilers are not told to supress warnings. check and convert compiler specific extensions (interrupts, memory areas, pragmas etc.). check for differences in type promotion. Especially check for math operations on char or unsigned char variables. For the sake of C99 compatibility SDCC will probably promote these to int more often than other compilers. Eventually insert explicit casts to (char) or (unsigned char). Also check that the ~ operator is not used on bit variables, use the ! operator instead. See sections 6 and 1.4. check the assembly code generated for interrupt routines (f.e. for calls to possibly non-reentrant library functions). check whether timing loops result in proper timing (or preferably consider a rewrite of the code with timer based delays instead). check for differences in printf parameters (some compilers push (va_arg) char variables as int others push them as char. See section 1.4). check the resulting memory map. Usage of different memory spaces: code, stack, data (for mcs51/ds390 additionally idata, pdata, xdata). Eventually check if unexpected library functions are included.