A Sample Document That Uses the icfp2007 Package

Norman Ramsey

Harvard University

Simon L. Peyton Jones

Microsoft Research

C-- is a new kind of compiler infrastructure: one whose primary goal is to help you build a quality implementation of the language of your choice on the machine of your choice. Many compiler infrastructures support multiple machines, but only C-- is designed from the beginning to support multiple front ends for multiple programming languages.

The key insight driving C-- is that to support such language features as garbage collection, exception dispatch, and concurrency, it is not enough for an infrastructure just to translate programs into target-machine code—the infrastructure must also support the runtime system (??). C-- provides this support through a unique runtime interface, which reveals to the run-time system the important decisions made in the compiler’s back end.

C-- also provides a compile-time interface. For ease of use with multiple clients, this interface is not an API but a language with an ASCII syntax. Using an ASCII syntax makes the interface independent of the programming language used to implement the client, but making the C-- compile-time interface a language also provides other benefits: it is much easier to debug a program than to debug a sequence of API calls, and we have better formal tools for specifying the proper use and semantics of a language than for specifying the use and semantics of an API.

A client of our system emits code in the C-- language, which our compiler then translates to native machine code. This native machine code runs together with the client’s run-time system, which makes calls into the C-- run-time interface. Using C--, a client can divide work between compiler and run-time system much as it would if using a custom code generator. For example, a client that implements garbage collection might generate C-- code to test for heap exhaustion, to advance an allocation pointer, and to initialize the fields of a newly allocated object. But that same client would probably put the garbage collector in its run-time system, where it would use the C-- run-time interface to walk each activation on the stack and to get access to the values of local C-- variables.

The C-- interfaces hide many details of the target machine, including the number and kinds of machine registers and the names and capabilities of machine instructions. The interfaces also hide many compiler algorithms, which can then be reused by multiple clients. These algorithms are well understood but difficult to implement; they include register allocation, instruction scheduling, peephole optimization, and many scalar and loop optimizations. Despite this hiding, the C-- interfaces are resolutely low-level: they are

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ICFP’07 October 1–3, 2007, Freiburg, Germany. Copyright \begin{matrix}c \\ ◯ \end{matrix} 2007 ACM 978-1-59593-815-2/07/0010… $5.00

much more like an assembly language than like the JVM or .NET frameworks. For example, a client targeting C-- has full control over the representation of high-level types such as strings, records, arrays, objects, functions, and so on.

Our long-term goals for C-- are to provide a reusable, optimizing back end that will support many useful optimizations on many target machines. By paying careful attention to how C-- is actually used by clients, we hope to make our compiler infrastructure easier to use than C while producing code that is almost as good as what one would get from a custom code generator.

Norman Ramsey graduated from Princeton University in 1983 with a degree in physics. He eventually switched to computing, in which field he earned the PhD from Princeton in 1993. After six years at Bellcore, Purdue, and the University of Virginia, he came to Harvard, where he is now Associate Professor of Computer Science in the Division of Engineering and Applied Sciences.

His main research interest is how to build reusable, retargetable programming-language infrastructure: compilers, assemblers, linkers, and debuggers. In his work on retargeting, he has pioneered the use of declarative machine descriptions, which say only what the machine does and do so in terms that are independent of particular implementations or tools. His SLED description language has been reused for applications ranging from binary translation to proof-carrying code. Simon Peyton Jones graduated from Trinity College Cambridge in 1980. After two years in industry, he spent seven years as a lecturer at University College London and nine years as a professor at Glasgow University before moving to Microsoft Research in 1998. His main research interest is in functional programming languages, their implementation, and their application. He has led a succession of research projects focused around the design and implementation of production-quality functional-language systems for both uniprocessors and parallel machines. He was a key contributor to the design of the now-standard functional language Haskell, and he is the lead designer of the widely-used Glasgow Haskell Compiler. He has written two textbooks about the implementation of functional languages.

References

Simon L. Peyton Jones, Norman Ramsey, and Fermin Reig. C--: A portable assembly language that supports garbage collection. In International Conference on Principles and Practice of Declarative Programming, volume 1702 of LNCS, pages 1–28. Springer Verlag, September 1999. Norman Ramsey and Simon L. Peyton Jones. A single intermediate language that supports multiple implementations of exceptions. Proceedings of the ACM SIGPLAN ’00 Conference on Programming Language Design and Implementation, in SIGPLAN Notices, 35(5):285–298, May 2000.