Contrary to predictions of its demise, C remains a dominant programming language, especially in embedded systems. Speed and transparency dictate that it will be so for the next decade, despite its supposed unsuitability for programming parallel architectures. A flexible compiler development system is a unique vehicle to bend the C language and its implementation to the developers' will. Using hard-won experience in applying extended versions of C to diverse parallel architectures, C's potential in the dark ages of multi-core programming is examined.

We believe it makes sense to develop compilers that are specific for particular application domains. In many areas of embedded computing, processor architectures are designed specifically to run a narrow band of application code very well. These architectures are unlike any the world has seen before and to program them is a challenge to say the least. CoSy's flexible compiler technology thrives in this area. By viewing the compiler as a means and not as a goal, it is possible to achieve spectacular results in a very short time-frame.

Modern compilers parse their input, which usually is a high-level programming language, and then convert the resulting parse tree into an intermediate representation (IR). This IR has the important property of being source language and target processor independent, which allows for generalized optimizations. This flexibility, however, also discards some of the high-level properties of the source language. In this paper we present an analysis that can extract most of the control flow structures typically found in the C programming language from a medium level IR. Mirtoc is an implementation of this analysis for the specific case of CCMIR, the IR used in ACE's CoSy® compiler framework. A compiler based on mirtoc is able to emit C code that is well structured, readable by a human and can be compiled by a back end compiler with relatively low overhead. This enables the use of optimizers based on medium level IRs in a source-to-source flow.

Abstract Over 25 implementations of different functional languages are benchmarked using the same program, a floating-point intensive application taken from molecular biology. The principal aspects studied are compile time and execution time for the various implementations that were benchmarked. An important consideration is how the program can be modified and tuned to obtain maximal performance on each language implementation. With few exceptions, the compilers take a significant amount of time to compile this program, though most compilers were faster than the then current GNU C compiler (GCC version 2.5.8). Compilers that generate C or Lisp are often slower than those that generate native code directly: the cost of compiling the intermediate form is normally a large fraction of the total compilation time. There is no clear distinction between the runtime performance of eager and lazy implementations when appropriate annotations are used: lazy implementations have clearly come of age when it comes to implementing largely strict applications, such as the Pseudoknot program. The speed of C can be approached by some implementations, but to achieve this performance, special measures such as strictness annotations are required by non-strict implementations. The benchmark results have to be interpreted with care. Firstly, a benchmark based on a single program cannot cover a wide spectrum of ‘typical’ applications. Secondly, the compilers vary in the kind and level of optimisations offered, so the effort required to obtain an optimal version of the program is similarly varied.

Strictness optimizations in the implementation of lazy functional languages are not always valid. In nonoptimized graph reduction, evaluation always takes place at the request of case analysis or a primitive operation. Hence, the result of a reduction is always a data value and never a function. This implies that in an implementation no argument satisfaction check is required. But in the presence of strict arguments, “premature” reduction may take place outside the scope of a case or primitive operation. This causes problems in graph reducers that use an aggressive take . Two solutions are presented, one based on a run-time argument satisfaction check, the other on a weakened strictness analyzer. Experimental results are used to compare the two solutions and show that the cost of the aggressive take can be arbitrarily high for specific programs. The experimental results enable a trade-off to be made by the reduction machine designer.