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

cover feature priate candidates to start with in the ﬁrst place. And to make matters worse, we want to explore different types of parallelizations quickly and easily, without rewriting signiﬁcant parts of the program over and over again. Tools can help us in transforming the source code, but in the end, there is no silver bullet: either the designer or the tool (or both) must sufﬁciently “understand” the source code to be able to transform it correctly and efﬁciently. Hence, it’s crucial that we identify those constructs in the source code that hamper this process. These can be code constructs at the level of programming language idioms or even at the level of design patterns for parallel programming. Once we’ve identiﬁed these constructs, we may elaborate rules that specify in which circumstances these constructs should be avoided. This is the rationale of IMEC’s so-called CleanC rules that have been elaborated during the development of an MPSoC applicationmapping tool suite. These rules target ANSI-C language idioms that make the process of mapping sequential C programs onto an MPSoC platform more difﬁcult. They consist of a few tens of guidelines and restrictions. Code restrictions are constructs that aren’t allowed to be present in the input C code for the tools to work (on that part of the code). For instance, undisciplined use of preprocessing information in C can make life very hard for any kind of source-code transformation tool. Code guidelines describe how code should be written to give the tools maximum accuracy and transformation freedom. The majority of these rules transcends the speciﬁc functionality of the IMEC mapping tools and may form the basis for a standard set of guidelines for programming MPSoC platforms in a “clean” code called CleanC. HOW CLEANC DIFFERS FROM C We can roughly classify the CleanC rules ing transformations. This makes the transformed code easier to recognize and understand, which is useful when the designer must edit the transformed code. Undisciplined use of header ﬁles and C preprocessor statements makes this design goal difﬁcult to achieve. A subset of CleanC rules detail how to properly use header ﬁles and preprocessor statements. Source-code transformations may also introduce conﬂicts between variable names; hence, CleanC suggests using different names for different things. Other constructs that make source code transformations more difﬁcult include irregular control ﬂow and expressions with side effects. • Category 2 – Rules to enable and improve datadependency analysis. A major challenge in parallelizing code and optimizing usage of the memory hierarchy consists of dealing with data dependencies. Knowing which data are needed by which parts of the code and understanding the exact dependencies between the program parts that update the data and the parts that read those data are crucial instruments for parallelizing and optimizing the code. Bruteforce approaches for synchronizing accesses to shared data resources may result in worst-case assumptions about the programs behavior. Hence they are typically bound to be suboptimal at best and highly inefﬁcient at worst. Thus, we must be able to analyze data dependencies in more precise and ﬁne-grained ways: for instance, which parts of a video frame may be safely processed in parallel by a video encoder application. To achieve this goal, a subset 13 To simplify the development of code suitable for parallelization and mapping on multiprocessor platforms, researchers at IMEC have developed a set of CleanC guidelines and a code analysis and refactoring toolbox to make code compliant to the CleanC programming style. in four different groups. These classiﬁcations are not completely independent. For instance, applying a rule from one category may strengthen the effects of rules in other categories. • Category 1 – Rules to enable and improve source-code transformations. The IMEC mapping tools are source-code transformation tools. One of the design goals of these tools was the ability to retain the structure of the original source code as much as possible when perform- www.embedded.com/europe | embedded systems design europe | AUGUST – SEPTEMBER 2008 012-013-014-016-017-018-019_ESDE.indd 13 28/08/08 13:18:07 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.