Embedded Systems Design Europe - August/September 2008 - (Page 14)

cover feature of the CleanC rules detail how to use constructs that reveal the intention of the designer more clearly. For instance, when processing a video frame, it’s easier to analyze the code when the designer uses an explicit code construct to represent the frame as a two-dimensional array with explicit indexing to access the pixel values, and when the designer uses canonical for loops with known bounds to enumerate the pixels. (The IMEC mapping tools understand a controlled form of dynamic multidimensional memory allocation.) Equivalent code with data and function pointers and with pointer arithmetic often obscures the intentions and makes the analysis more difﬁcult. Some exceptions to this intention-revealing principle exist, however. For instance, while recursive function deﬁnitions often express the intention more clearly than their nonrecursive counterparts, they are typically harder to analyze by tools. elsewhere, such as in the Misra C guidelines available at www.misra. org.uk. PUTTING CLEANC TO WORK Rather than exhaustively delineate these and other categories of rules for writing C-code for multiprocessor designs, following are examples of some of these rules at work. • Category 3 – Rules to minimize data dependencies. Needless data dependencies complicate the analysis process and may lower the quality of the analysis results. This, in turn, affects the ability to optimize and parallelize the source code. CleanC not only details to avoid global variables and duplicated functionality, but it also imposes stricter constraints on the usage of types: types with different names are basically considered different. Using code constructs like global variables also has more direct negative effects, for instance by needlessly increasing the lifecycle of large data structures. Category 4 – Rules to avoid the dark corners of the C standards. The C standards contain many elements that not deﬁned or, in general, not well understood. The CleanC rules specify a limited set of constructs that should be avoided. More rules of this type can be found • • Example 1 – Guideline: use the manifest loop pattern. Many optimizations rely on analyzing exactly which data element is accessed at which point in time. That requires interpreting how index expressions evolve over the execution of the loops. Therefore, it must be possible to interpret the index expressions, the loop bounds, and how the loop iterator is incremented. To make this interpretation easier, CleanC uses a ﬁxed pattern for manifest loops. A manifest loop is executed in exactly the same way, independent of the input received by the code. More formally, a manifest loop is a loop with an iterator that is initialized with a manifest value. The iterator is incremented or dec- remented with a constant value in each iteration, and the loop ﬁnishes when the iterator reaches a certain manifest value. A manifest value is a value that is either constant or computed from the iterators of outer loops. Nonmanifest loops, on the other hand, have no restriction on how they should be written. In CleanC, only loops that follow this ﬁxed pattern are recognized as being manifest by the tools. Therefore, it mostly is just a matter of using the pattern instead of using, for example, a while loop. If the iterator is updated in several places, this can usually be replaced by a ﬁxed update and not executing the loop body in some iterations. A loop with a data-dependent upper bound (the typical while loop) can be replaced by a manifest loop over the maximum number of iterations with a condition nested inside it. However, this is only useful if the iterator is then used in some index expression. Figure 1 shows a screenshot of an example of the guideline “manifest loop pattern” violation as it would appear in the CleanC tool. 14 AUGUST – SEPTEMBER 2008 | embedded systems design europe | www.embedded.com/europe 012-013-014-016-017-018-019_ESDE.indd 14 28/08/08 13:18:23 http://www.misra.org.uk http://www.misra.org.uk http://www.embedded.com/europe

Table of Contents Feed for the Digital Edition of Embedded Systems Design Europe - August/September 2008

Embedded Systems Design Europe - August/September 2008 Contents TI Overhauls DSP Lineup, Adds 15 Processors QNX Publishes Source Code for File System Congatec to Take on Proprietary Market Swiss Multicore Project Wins Microsoft Grant OpenCores Bundles Development Tool ARM Compiler Boosts Freescale i.MX31 LabVIEW Updated for Multicore and Wireless Cover Feature: Interactive Tool Supports Multiprocessor SoC Design Wanted: Benchmaking for Embedded VMM Hypervisors Graphical Design Empowers Spider Robots Building a Power Supply for Discontinuous Transmission Wireless Networks RTOS Selection & Best Practices Achieving Cache Coherence in a MIPS32 Multicore Design New Products Advertising Contacts

Embedded Systems Design Europe - August/September 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.