Getting the Least Out of Your C Compiler

Transcription

1 Getting the Least Out of Your C Compiler Strategic Development IAR Systems jakob.engblom@iar.se Jakob Engblom Dept. of Computer Systems Uppsala University, Sweden jakob@docs.uu.se Embedded Systems Conference San Fransisco 2001 Class #508 This Class Coding Coding tips and usage tips for C To keep code size down To help the compiler optimize Assumed background: Embedded Systems Hardware Embedded Systems Software C Programming Level: basic 1 2 The Target Systems Why Care About Size? Microcontrollers: CPU Core Integrated memory Integrated peripherals Integrated services System on a chip 8-16 bit most common RAM (small) UART CPU Core A/D LCD D ROM (big) Timer Outside World Keep Keep memory cost down Avoid external memory Use smaller external memory Use a smaller derivative Keep absolute limits HW done before the software Application can only use on-chip memory 3 4

2 Compiler System Compiler Technology User Code C Source C Source C Source Compiler System Compiler Object File Object File Object File C Runtime C Library Linker 5 OS Other Lib Third-Party Code Executable Hardware 6 The Compiler Optimization x = C Source x + 15 Parser Intermediate Code ld R10,$_x add R10,#15 st $_x,r10 x = x + 15; Code Generator Target Code High-Level Optimizer Assembler Object Code Compiler Low-Level Optimizer Analysis: Understand the code Data flow, control flow More info = better code Transformation: Change the code Based on heuristics Should improve but does not have to And definitely not optimality of the code! Improvement not guaranteed! 7 8

3 Basic Transformations Use cheaper operation Find common calculations Propagate constant values Remove useless computations a=b*2 a=b+c*d e=f+c*d a=17 b=56+2*a a=b*c+k a=k+7 a=b+b temp=c*d a=b+temp e=f+temp a=17 b=90 a=b*c+k a=k+7 Basic Transformations Remove unreachable code Move invariant code out of loops if(a>10) b=b*c+k; if(a<5) a+=6; for(i=0;i<10;i++) b = k * c; p[i] = b; if(a>10) b=b*c+k; if(a<5) a+=6; b = k * c; for(i=0;i<10;i++) p[i] = b; 9 10 Pitfall: Empty Loops Optimization Settings Empty Empty delay loop does not work Code with no effect Gets removed Delay is zero For For delay: Access volatile variable Use OS services Use CPU timer Use delay intrinsic void delay(int time) int i; for (i=0;i<time;i++) ; return; void InitHW(void) /* Timing-dependent code */ OUT_SIGNAL (0x20); delay(120); OUT_SIGNAL (0x21); delay(121); OUT_SIGNAL (0x19); Typically available: Minimize size ( size ) Minimize execution time ( speed ) Enable/disable individual transformations Use Use highest settings! Settings only approximate Best guess by compiler writer Test several settings, check the results Disable destructive transformations 11 12

4 Optimization Settings Code Generation Global Global setting Over entire project IDE or command-line Per-file Per-file settings Example: collect all speed in one file Per-function #pragma in source file Compiler dependent #pragma optimize(all,off) void delay(int time) From From Intermediate to Target Implement C operations Break down big operations Insert calls to C runtime (more on this later) May introduce jumps, loops, etc. Assign Assign variables to registers Register Allocation Heuristics for best variables Language rules followed (volatile) Shouldn t be considered optimization Compiler Libraries The C Library User Code C Source C Source C Source Compiler System Compiler Object File Object File Object File OS Other Lib Third-Party Code C Runtime C Library Linker Executable Hardware 15 printf() () etc. etc. Programmer-visible Standardized in ANSI C Standalone profile: No file operations Suitable for run-from-rom systems Limited Limited versions: Smaller code through less functionality Provided with compiler Non-standard 16

5 The C Run-Time System Not Not very well known item Part Part of compiler Designed with the compiler Implements complex functions Called from compiled code Not visible to programmer Whatever is needed that the hardware does not support Bigger Bigger for simpler machines 17 The C Run-Time System 32-bit 32-bit arithmetic Floating-point arithmetic Pointer Pointer use: Banked, generic, large, function pointers, Operations missing from CPU: Multiply, divide, modulo, Variable-length shifts ( a<<x a<<x ) May May have a large footprint Tens of kilobytes of code Tens of bytes of data 18 Coding Techniques Structuring a Program To be efficient and portable Isolate device-dependent code Leave most of the code undisturbed Use tuned code where needed Generic Program Files Tuned Program Files Device-dependent Program Files Hardware 19 20

6 Device Descriptions Chips Chips have many derivatives Different I/O ports Different available memories, sizes, etc. Special features Compiler device description: As As #include include files and command-line options #include files from compiler: Describes chip in best way for compiler Saves work for programmer Do not write your own unless necessary! Use of Data Types Types Types very important Factors Factors to consider: Size Signed or unsigned Floating point or integers Memory placement Pointer types Casting Data Size Performing operations: 32-bit operations hard for 8-bit CPU 8-bit operations less efficient on 32-bit Sometimes type is forced char long char for byte I/O etc long for large counters Often, Often, we can choose Smallest possible type for 8-bit int for 32-bit machines Data Size: Header Files 8-bit machine /* Fixed size types */ typedef unsigned char uint8_t; typedef short int16_t; typedef unsigned long uint32_t; /* Adjusting types */ typedef char best_int8_t; typedef short best_int16_t; typedef long best_int32_t; /* Use best_x_t for ranges */ best_int8_t i; for(i=0; i<10; i++) 32-bit machine /* Fixed size types */ typedef unsigned char uint8_t; typedef short int16_t; typedef unsigned int uint32_t; /* Adjusting types */ typedef int best_int8_t; typedef int best_int16_t; typedef int best_int32_t; All are 32-bit values. Most efficient for calculations 23 24

7 Signed or Unsigned Think Think about the signedness SignedSigned Negative values possible Arithmetic operations performed Unsigned Negative values impossible Bit operations performed + - * / % << >> & ^ ~ 25 Integer or Floating Point Floating point very expensive Brings large library (from C runtime lib) Use only when really needed Can Can be done inadvertently: Example code: #define ImportantRatio ((int)(1.95 * Other)) #define Other 20 #define ImportantRatio (1.95 * Other) int i=a + b * ImportantRatio; This is a floating-point multiplication. Float library linked in! To obtain an integer constant from ImportantRatio, and thus integer code: bits Memory Placement Typical micro- Use smaller areas: controller memory: Smaller addresses 16 bits 8 bits Far Near Tiny Smaller instructions Smaller pointers =more efficient =less code! Place Place variables: Using keywords tiny char a; a Using #pragma Using In tuned files 27 Pointers & Memory Pointer Pointer types: One for each addressing space/mode near char * nearptr; tiny int * tinyptr; Generic, huge, etc: Point to all memories (for disjoint memories) Point to objects crossing banks Software-emulated = expensive Use Use the smallest applicable type Beware of compiler default settings! Memory model, Data model, 28

8 Casting C C has implicit and explicit casts Casting Casting is not free Sign-extend and zero-extend Complex conversions to/from floats Casting Casting to/from pointers is bad Can lose information (different size) Inefficient code Avoid unless really necessary Don t do explicit casts Don t mix types in expressions Register Allocation Important for good code To To facilitate: Register keyword? Use parameters Use local variables Don t take addresses Group function calls Don t use varargs Register keyword Hint Hint to compiler Cannot Cannot take address of variable May May be ignored Modern compilers ignore register register Register allocation heuristics usually better Use Parameters & Locals Global Global variables Written back at function calls Have to be given memory Do not use globals for parameter passing! Parameters and local variables Give compiler more freedom Need not be given memory Parameter passing: Parameters often passed in registers Registers to use = calling convention 31 32

9 Use Parameters & Locals Register allocation targets: Simple values (integers, pointers, floats) Small CPUs: maybe not the biggest values Hard Hard to allocate: Arrays indexing addressing the norm Structs large, often pointed to StructStruct as parameter: Value copied, and a pointer passed Pass pointer directly for efficiency! Use Parameters & Locals void foo(char a) char b,i,j; char h[10]; b=a<<5; for(i=0; ) OUTPUT(b); for(j=0; ) h[j]=a; live ranges a b i j Array usually not in registers Register usage: Variables can share a register Only present in register while live Don t worry about extra variables j, i, b all optimized away at this point Many registers Optimize: needed here Minimize lifetime j can use the same Minimize register overlap as i or b Don t Take Addresses Address taken not in register Always written back to memory Variable has to have memory Since: Since: The address escapes a function Compiler cannot know who reads Note: Note: not too bad for globals Local variables behave like global register keyword prevents Examples of address taking Input Input functions: int a; scanf( %d,&a); int a, temp; scanf( %d,&temp); a=temp; Watch Watch out for smart tricks: #define highbyte(x) ( *((char *)(&x)+1) ) #define highbyte(x) ( (x>>8) & 0xFF ) 35 36

10 Group Function Calls Function calls: Increase register pressure Require certain registers =impediment to register allocation Group Group to minimize effects s.a = a; s.b = bar(b); s.c = c; s.d = c; s.e = baz(d); s.a = a; s.c = c; s.d = c; s.b = bar(b); s.e = baz(d); Don t Use Varargs Variable number of arguments int printf(char *,...) Special macros to access arguments Force Force arguments to the stack Step through them using pointers No No parameters in registers Source Source code gets more complex Object Object code gets bigger Bad Bad idea, simply Facilitate Transformations Convey Convey maximal information Write Write clear code Techniques: Use function prototypes Mark file-locals using static Don t use inline assembler Don t write clever code Write nice loops Access hardware as variables 39 Use Function Prototypes C C and function calls: No declaration: call out of the blue K&R declarations: extern void foo(); ANSI prototypes: char bar(short); extern void foo(); Without ANSI prototypes: No proper type checking All arguments promoted Introduces casting code Parameter data is larger = more stack used Always Always use ANSI prototypes! Turn on checking in compiler! 40

11 File Locals Don t Use Inline Assembly The The static keyword: Object not visible outside the file All references known More aggressive optimization possible Functions: Higher chance of inlining Variables: Knows address taken, etc. for all uses Better optimization possible 41 Major Major hinder to optimization Inline assembly can do anything (Some inline assemblers allow annotations) Put Put assembly into: Separate assembly-source files Assembly-only functions in C files To To access special instructions: Use intrinsic functions (if available) disable_interrupts() disable_interrupts() delay( delay(n) Generates single assembly instructions 42 Don t Write Clever Code Example Clever Code Clever Clever code: Fewer source characters = better code Using dark corners of C semantics Straightforward code: Easier for compiler and humans Safer for portability Use common constructions: Likely to be better optimized Less likely to contain bugs Use of constant: Check Check If Low high likelihood 21 Bits of Zero Depends on semantics of NOT operator unsigned in C long int a; unsigned char b; b =!!(a << 11); Explicit check against zero for the creating bit-set lower bits instruction unsigned long int a; unsigned char b; if( (a & 0x1FFFFF)!= 0) b = 0x01; Explicit check: Calculating Add with result of with Conditionals comparison: forces generation int of 1 or bad(char 0 *str) foo(str+(*str=='+')); only do an inc if needed. Smaller int code. good(char *str) if(*str=='+') str++; foo(str); 43 44

12 Write Nice Loops The The compiler is able to: Adjust loop statements to the machine Change count direction Utilize Utilize loop instructions if available (DJNZ) Remove initial check in for -loops Convert array indexing to pointer walking Unroll loops, fuse loops, many other tricks Regular, simple loops: Easier to understand for maintenance Easier to optimize for compiler 45 Write Nice Loops int i=0; do i+=2; temp = b[i]; i-=1; b[i] = temp + 2; while (i<80); for()-loop should always be used if possible! /* use that i is 80 after loop*/ a = i; Do not read value of loop index after the loop best_int8_t i=0; for(i=0; i<80; i++) b[i+1]=b[i+2]+2; Update loop a = 80; index only in the loop declaration Think Fortran 46 Access to Hardware Ports Do Do not cast a constant: #define PORT (*((BYTE *) 0x41FF)) Use Use a variable: volatile no_init BYTE PORT; Locate it: special syntax, or use linker Easier to locate in the right memory Often provided in devicexx devicexx.h Provides better type checking Gives better code Can be simulated on PC 47 Inhibit Optimizations Sometimes, optimizations are not desirable Reordering of computations Removing redundant code Register allocation Examples: Shared variables I/O ports Side effects must be ordered Use volatile variables! 48

13 Volatile Semantics VolatileVolatile keyword means Can change outside program control = Can change asynchronously Effect Effect on compiler: Never in registers All reads and writes to memory immediately Accesses not reordered No assignments considered dead Put Put in: Header files for I/O and shared data Volatile Examples volatile Boolean glock; while( glock == kfalse ) /* spinlock */ ; volatile no_init uint8_t outporta; volatile no_init uint16_t outportb; /* Setup sequence for hardware */ outporta = 0x00; outportb = 0x1000; outporta = 0x3A; outportb = 0xFFFF; Use Another Compiler Outside the Code Compilers are different Different priorities Different sets of optimizations Different ideas of target programs Test Test several compilers See what works best with your code Use Use real application code! Benchmarks are usually misleading ( benchmarketing benchmarketing ) 51 52

14 Try Better Architectures Some Some chips are inherently better More suited for application More suited for C programming More efficient instruction sets (Good example: AVR vs ) Compacted instruction sets Works in practice, gives smaller code ARM/Thumb MIPS16 Closing Remarks Optimization gives bugs? Exposes existing bugs Very particular about C semantics Reduces redundancy in code Code was wrong to begin with Only correct code is optimized correctly Optimization is necessary Write maintainable, non-tuned code Trust compiler to optimize Without optimization, compiler handicapped Summary: Code Write Write easy-to-understand code Provide maximal information Maintenance easier Optimizations work better =Everybody happy Do not suboptimize Keep code free of target assumptions Let the compiler optimize for target Manually optimize only where needed 55 56

15 Summary: C Compilers Compilers are heuristic Usually work OK No guarantees of improving code No hard facts like always always gains n% Try Try different compiler settings All programs are different Use Use common constructions Fewer bugs, better optimized (Many more details in paper) 57 The End Fill in Evaluation Forms Updates of Paper: docs.uu.se/~.se/~jakob