Page 1. Last Time. Today. Embedded Compilers. Compiler Requirements. What We Get. What We Want

Transcription

1 Last Time Today Low-level parts of the toolchain for embedded systems Linkers Programmers Booting an embedded CPU Debuggers JTAG Any weak link in the toolchain will hinder development Compilers: Expectations and reality C for embedded systems Lots of things make C for embedded systems different from C for Windows or Linux Raw device access Inline assembly Interrupts Etc. Not enough to just be good at C Also: This all applies to C++ But we re not going to talk about C++ explicitly Embedded Compilers Compiler Requirements Today: General capabilities Specific issues part 1 First: Almost all compilers for embedded systems are cross-compilers Compiler runs on an architecture other than its target Does this matter at all? Be correct Embedded compilers are notoriously buggy Relatively few copies sold Diverse hardware impedes thorough testing Produce small, fast code Speed and size are conflicting goals Oops! Take advantage of platform-specific features Produce code that s easy to debug Conflicts with optimization Whole-program optimization particularly problematic What We Want You want to tell the compiler: There are only 32 KB of RAM Program must fit, but there s no point reducing RAM consumption further There are only 256 KB of ROM Again: Program must fit but there s no point reducing ROM consumption further Interrupt handler 7 is time critical So make it very fast, even if this bloats code Threads 8-13 are background threads Performance is unimportant so focus on reducing code size What We Get A few compiler flags: -O2, -Os, Etc. May or may not do what you want Typically no flags for controlling RAM usage Grim realities: Meeting resource constraints is 100% your problem Shouldn t assume compiler did the right thing Shouldn t assume code you reuse does the right thing Including the C library Figure out which resources matter and focus on dealing with them Changing or upgrading compiler mid-project is usually very bad Page 1

2 Nice Example Why use C? From a 1982 book on 6502 assembly programming: strcmp(): compare two strings Registers used: all Execution time: * length of shorter string Code size: 52 bytes Data size: 4 bytes on page 0 4 bytes to hold the string pointers Try to find this information for current C libraries! Mid-level language Some high-level features Plenty of low-level control Type system easily subverted C is popular and well-understood Plenty of good developers exist Plenty of good compilers exist Plenty of good books and web pages exist There s no obviously superior choice Why not use C? Hard to write portable code For example int does not have a fixed size Hard to write correct code Very hard to tell when your code does something bad E.g. out-of-bounds array reference This is Microsoft s major problem Language standard is weak in some areas Means there is plenty of diversity in implementations Linking model is unsafe Preprocessor is poorly designed CPP the C Preprocessor CPP runs as a separate pass before the compiler Basic usage: #define FOO 32 int y = FOO; Compiler sees: int y = 32; CPP operates by lexical substitution Important: The compiler never sees FOO So of course the debugger, linker, etc. do not know about it either Some Interesting Macros Macro Problems #define PLUS_ONE(x) x+1 int a = PLUS_ONE(y)*3 #define TIMES_TWO(x) (x*2) int a = TIMES_TWO(1+1) #define MAX(x,y) ((x)>(y)?(x):(y)) void f () { int m = MAX(a++,b); #define INT_POINTER int * INT_POINTER x, y; Root of the problem: C preprocessor is highly error-prone Avoid it except to do very simple things Fully parenthesize macro definitions Make macro usage conventions clear Entertaining macros: #define DISABLE_INTS asm volatile ( cli ); { #define ENABLE_INTS asm volatile ( sei ); Is this good or bad macro usage? Page 2

3 Macro Avoidance Old conventional wisdom: Careful use of CPP is good New conventional wisdom: Most uses of CPP can be avoided Trust the optimizer Constants Use #define X 10 const int X = 10; Functions Use #define INC_X x++ inline void INC_X(void) { x++ More Macro Avoidance Conditional compilation #if FOO #endif Use if (FOO) { #ifdef X86 #endif Put x86 code into a separate file However: Design of C makes it impossible to avoid macros entirely C++ much better in this respect Bit Manipulation without Macros Something like this is good: void set_bit (int *a, int bit) { (*a) = (1<<bit); void clear_bit (int *a, int bit) { (*a) &= ~(1<<bit); CPP in Action Sometimes you need to look at the CPP output That is, see what the C compiler really sees There s always a way to do this In CodeWarrior, do this using the IDE For gcc: gcc E foo.c Accessing Device Registers Many embedded chips map device registers into RAM This is memory mapped I/O These registers do not act like RAM Each read may return a different value Writes may be ignored Reads and writes can be side effecting Page 3

4 Accessing Device Registers What happens if we access a register like this: extern int CTRL_REG; set_bit (&CTRL_REG, 3); Compiler may add, delete, and reorder references to this register Compiler thinks the register is in RAM Optimizing CPUs can do similar things What if bit 4 of CTRL_REG is the one that lowers the control rod into the reactor? And the compiler eliminates the write Oops! Solution: Volatile Qualifier In C you can mark any variable as volatile Compiler is no longer permitted to assume that Retains its value after a read or write Reads from and writes to the variable have no side effects Easy implementation strategy for compiler writers: Refuse to optimize any function that accesses any volatile variable Some compilers actually do this Volatile is a storage qualifier, like const Volatile Example C code you might write: /* Enable signal as GPIO */ void make_pin0_gpio (void) { MCF_GPIO_PTCPAR = MCF_GPIO_PTCPAR_DTIN0_GPIO; Relevant reprocessor definitions: typedef volatile uint8 vuint8; #define MCF_GPIO_PTCPAR \ (*(vuint8 *)(& IPSBAR[0x10006F])) #define MCF_GPIO_PTCPAR_DTIN0_GPIO (0) Volatile Example After the C processor has run, the code is: void make_pin0_gpio (void) { (*(vuint8 *)(& IPSBAR[0x10006F])) = (0); So, this is the code the CodeWarrior compiler actually sees and compiles Note: vuint8 * is pointer-to-volatile, not volatile-pointer The distinction is crucial Hardware register access is typically done using pointers-to-volatile Compiler Output Different Example _make_pin0_gpio: 0x link a6, #0 0x moveq #0, d0 0x move.b d0, IPSBAR x C unlk a6 0x E rts C code you might write: /* Enable signal as GPIO */ void make_pin0_gpio (void) { MCF_GPIO_PTCPAR = MCF_GPIO_PTCPAR_DTIN0_GPIO; Expands out to: void make_pin0_gpio_bogus (void) { (*(vuint8 *)(& IPSBAR[0x10006F])) = (0) ; Page 4

5 Compiler Output _make_pin0_gpio_bogus: 0x link a6, #0 0x move.b IPSBAR , d0 0x A unlk a6 0x C rts 0x E nop So What Does Volatile Really Mean? Does not mean suppress optimizations It means: loads from and stores to a volatile location must not be added or deleted, and must occur in program order What happened? Is the code what we wanted? Is the compiler correct? What does volatile NOT mean? Accesses to volatiles are not necessarily atomic Accesses to volatiles may be moved past accesses to non-volatiles Example: volatile int flag; void interrupt (void) { flag = 1; void not_interrupt (void) { while (flag == 0); do stuff Volatile Problem Compiler can transform your code to this: void not_interrupt (void) { do stuff while (flag == 0); Better: void not_interrupt (void) { while (flag == 0); BARRIER; do stuff Memory Barriers In gcc a compiler barrier looks like this: asm volatile ( : : : memory ); Says to the compiler: No code motion around this statement This statement may affect any RAM location, so: Store all register values to RAM before the barrier Reload values from RAM into register after the barrier How to do this is CodeWarrior??? Nothing in the docs Best guess: CodeWarrior does not do reordering optimizations More Barrier Issues Compiler isn t the only source of problems! Smart memory subsystems can reorder operations Apparently redundant operations can be suppressed Important: Device memory must be marked as non-caching Locks must include not only compiler barriers but also processor-specific memory system barriers Page 5

6 Volatile Summary Does this make sense? const volatile int x; Use volatiles to protect access to hardware registers Do not build your own locks A lock is anything that you use to enforce sequencing or mutual exclusion between concurrent computations Even experts get these wrong Summary C compilers make writing embedded software feel a lot like writing regular software However: Lots of subtle differences between writing Windows / Linux code and embedded code Need to understand these and cope with them Easy to get burned and create very difficult debugging problems Page 6