\section{Back-end Implementations}\label{backend-sect}

\subsection{Low-level and object oriented backends}

As we saw in section \ref{sect:ootype}, the RTyper can specialize the
high-level graphs using either the \lltype or \ootype typesystem. Like
the RTyper type systems, the backends are also divided into two categories, 
low-level and object-oriented.

Currently, there are two low-level backends: GenC, which produces C
source code to be fed to \emph{gcc}, and GenLLVM, which procudes LLVM
bytecode \cite{LLVM:CGO04}; and three object-oriented backends:
GenCLI, which targets the CLI virtual machine, GenJVM, for the Java
virtual machine, and GenJS, which produces Javascript code to be run
into a web browser.

In the following sections we will discuss only GenCLI (section
\ref{gencli-sect}) and GenJVM (section \ref{genjvm-sect}). For more
informations about the other backends, see \cite{D05.1}, \cite{D12.1}
and \cite{RigoPedroni06}.

The Java Virtual Machine (JVM) \cite{JvmSpec} and the CLI
\cite{ECMA-335} share many similarities, which enables PyPy's JVM and
CLI backends to share a substantial amount of code.


\subsubsection{Translation from RPython to CLI and JVM}

The majority of RPython can be translated to the CLI and JVM in a
straight-forward fashion.  For example, as we saw in section
\ref{sect:ootype}, \ootype 's object model is Java-like, meaning that
most RPython classes can be mapped directly to a corresponding native
class, and RPython method calls be implemented using the CLI's
\lstinline!call instance! or JVM's \lstinline!invokevirtual!
instructions.

Due to the \ootype type system described earlier, we are also able to
map RPython containers such as \lstinline!SomeList! and
\lstinline!SomeDict!  directly to their equivalents in the standard
library of the target platform (respectively, \lstinline!List<T>! and
\lstinline!Dict<K,V>!  for .NET and \lstinline!Vector! and
\lstinline!HashTable! for Java).

Certain parts of RPython, however, do not match the expectations of
the CLI or JVM and require more careful treatment, as explained in
sections \ref{gencli-sect} and \ref{genjvm-sect}.

\subsubsection{Register- to stack-machine translation}

As shown in section \ref{sect:annot}, RPython programs are represented
as flow graphs expressend in SSI form, a register-based intermediate
representation.

Since both the CLI and the JVM are stack-based virtual machines, we
are forced to convert between the two.  Thus, we developed a common
piece of code that can group the register-based instructions into
trees to allow for reasonably efficient stack-based code; the details
of these techniques are not the topic of this paper.

Currently, this algorithm is fully integrated into GenCLI but not yet
into GenJVM; efforts are underway to let GenJVM to exploit the SSI
form to tree-based form transformation.

\subsection{GenCLI: The .NET back-end}\label{gencli-sect}

\input{gencli}

\subsection{GenJVM: The JVM back-end}\label{genjvm-sect}

\input{genjvm}

\subsection{Benchmarks and Comparisons with Other Compilers}\label{benchmarks}

\note{to be filled in}

\input{jython}