% instructions at http://www.sheridanprinting.com/typedept/icfp.htm

\documentclass{sigplanconf}
\usepackage{icfp2007}
%\usepackage[normalbib]{icfp2007}

\newcommand{\PAL}{C\texttt{-{}-}}

\begin{document}
\title{A Sample Document That Uses the \texttt{icfp2007} Package}
\authorinfo{Norman Ramsey}{Harvard University}{}
\authorinfo{Simon L. Peyton Jones}{Microsoft Research}{}

\conferenceinfo{ICFP'07} {October 1--3, 2007, Freiburg, Germany.}
\CopyrightYear{2007}
\copyrightdata{978-1-59593-815-2/07/0010}


\maketitle

{\PAL} 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
{\PAL} is designed from the beginning to support multiple front ends
for multiple programming languages.

The key insight driving {\PAL} 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 run-time system
\cite{peyton-jones:c--gc,ramsey:intermediate}. 
{\PAL}~provides this support through a unique \emph{run-time interface}, which
reveals to the run-time system the important decisions made in the
compiler's back end. 

{\PAL}~also provides a compile-time interface.
For ease of use with multiple clients, this interface is not an API
but a \emph{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
{\PAL} 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 {\PAL}~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 {\PAL} run-time interface.
%
%
%
Using {\PAL}, 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 {\PAL}~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 {\PAL} run-time interface to
walk each activation on the stack and to get access to the values of
local {\PAL} variables.

The {\PAL} 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 {\PAL} interfaces are resolutely low-level:
they are much more like an assembly language than like the JVM or .NET
frameworks.
For example, a~client targeting~{\PAL} 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 {\PAL} are to provide a reusable, optimizing
 back end that will support many useful optimizations on many target
 machines. 
By paying careful attention to how {\PAL} 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.

\bigskip

\noindent
\textbf{Norman Ramsey}
graduated from Princeton University
in~1983 with a degree in physics.
He eventually switched to computing, in which field he
%He enjoyed a fleeting career as a physicist before returning to graduate study
%in computer science, earning
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 \emph{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.


\smallskip
\noindent
\textbf{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. 


\bibliographystyle{plainnat}
\bibliography{ramsey}

\end{document}