1. The Process From bare bones to finished product

2. The Steps Programming Debugging Performance Tuning Optimization

3. Programming To create a set of instructions for a piece of hardware to follow Two broad categories:  Low-level languages  High-level languages

4. Low Level Languages Have a limited amount of abstraction between the hardware and the programmer Deal with registers, memory addresses, etc Are often limited to a small set of platforms due to this Examples:  Machine Code  Assembly  C

5. High Level Languages Are “abstract”  Human readable  Use objects, variables, arrays, etc Suffer from “abstraction penalty” Execution types:  Interpreted (Java, Python, Ruby)  Compiled (C, C++, practically everything else)  Translated (Often translated to C)

6. Debugging The act of taking something broken and trying desperately to make it work Where the significant time in any project is spent Necessary for both hardware and software sides

7. Hardware Debugging FIGURE 17.1 Platform Debug Process

8. Software Debugging Can the problem be lived with? Attempt to reproduce the problem Narrow the suspects down  Divide-and-conquer Use specific debugging tools in the right place  Can lead to “false positives”  Not capable of catching everything

9. Debugging Techniques Path tracing – printf (or equivalent) Breakpoints Stepping through Memory/core dumps

10. Performance Tuning Assess the problem Measure the performance Identify bottlenecks Modify that part Measure the new performance Do not get caught up in minutiae!!

11. Tuning May take one of several forms  Code optimization  Caching  Load balancing  Parallelization All are bottlenecks

12. Optimization More important for embedded systems Focus on the limitations of the platform  Speed  Power consumption  Memory usage Exist as tradeoffs  Greater speed, higher memory usage  Lower power consumption, slower processing

13. Problems Tuning and optimization are in themselves bottlenecks – though in production, not performance  May introduce new bugs  Often not “human readable”  May affect ease of upgrading

14. Programming, Tuning and Optimization Code first, then tune and optimize Unoptimized code is often easier to code and debug than optimized code  Get the major flaws out of the reasoning first Be specific  Power consumption needs to be limited Be reasonable  Idealized reality rarely exists