[pypy-commit] pypy default: Removed a ton of documenation about ootypesystem.
alex_gaynor
noreply at buildbot.pypy.org
Sun Jul 28 20:32:14 CEST 2013
Author: Alex Gaynor <alex.gaynor at gmail.com>
Branch:
Changeset: r65749:66ce9bd318a9
Date: 2013-07-28 11:31 -0700
http://bitbucket.org/pypy/pypy/changeset/66ce9bd318a9/
Log: Removed a ton of documenation about ootypesystem.
diff --git a/pypy/doc/cli-backend.rst b/pypy/doc/cli-backend.rst
deleted file mode 100644
--- a/pypy/doc/cli-backend.rst
+++ /dev/null
@@ -1,455 +0,0 @@
-===============
-The CLI backend
-===============
-
-The goal of GenCLI is to compile RPython programs to the CLI virtual
-machine.
-
-
-Target environment and language
-===============================
-
-The target of GenCLI is the Common Language Infrastructure environment
-as defined by the `Standard Ecma 335`_.
-
-While in an ideal world we might suppose GenCLI to run fine with
-every implementation conforming to that standard, we know the world we
-live in is far from ideal, so extra efforts can be needed to maintain
-compatibility with more than one implementation.
-
-At the moment of writing the two most popular implementations of the
-standard are supported: Microsoft Common Language Runtime (CLR) and
-Mono.
-
-Then we have to choose how to generate the real executables. There are
-two main alternatives: generating source files in some high level
-language (such as C#) or generating assembly level code in
-Intermediate Language (IL).
-
-The IL approach is much faster during the code generation
-phase, because it doesn't need to call a compiler. By contrast the
-high level approach has two main advantages:
-
- - the code generation part could be easier because the target
- language supports high level control structures such as
- structured loops;
-
- - the generated executables take advantage of compiler's
- optimizations.
-
-In reality the first point is not an advantage in the PyPy context,
-because the `flow graph`_ we start from is quite low level and Python
-loops are already expressed in terms of branches (i.e., gotos).
-
-About the compiler optimizations we must remember that the flow graph
-we receive from earlier stages is already optimized: PyPy implements
-a number of optimizations such a constant propagation and
-dead code removal, so it's not obvious if the compiler could
-do more.
-
-Moreover by emitting IL instruction we are not constrained to rely on
-compiler choices but can directly choose how to map CLI opcodes: since
-the backend often know more than the compiler about the context, we
-might expect to produce more efficient code by selecting the most
-appropriate instruction; e.g., we can check for arithmetic overflow
-only when strictly necessary.
-
-The last but not least reason for choosing the low level approach is
-flexibility in how to get an executable starting from the IL code we
-generate:
-
- - write IL code to a file, then call the ilasm assembler;
-
- - directly generate code on the fly by accessing the facilities
- exposed by the System.Reflection.Emit API.
-
-
-Handling platform differences
-=============================
-
-Since our goal is to support both Microsoft CLR we have to handle the
-differences between the twos; in particular the main differences are
-in the name of the helper tools we need to call:
-
-=============== ======== ======
-Tool CLR Mono
-=============== ======== ======
-IL assembler ilasm ilasm2
-C# compiler csc gmcs
-Runtime ... mono
-=============== ======== ======
-
-The code that handles these differences is located in the sdk.py
-module: it defines an abstract class which exposes some methods
-returning the name of the helpers and one subclass for each of the two
-supported platforms.
-
-Since Microsoft ``ilasm`` is not capable of compiling the PyPy
-standard interpreter due to its size, on Windows machines we also look
-for an existing Mono installation: if present, we use CLR for
-everything except the assembling phase, for which we use Mono's
-``ilasm2``.
-
-
-Targeting the CLI Virtual Machine
-=================================
-
-In order to write a CLI backend we have to take a number of decisions.
-First, we have to choose the typesystem to use: given that CLI
-natively supports primitives like classes and instances,
-ootypesystem is the most natural choice.
-
-Once the typesystem has been chosen there is a number of steps we have
-to do for completing the backend:
-
- - map ootypesystem's types to CLI Common Type System's
- types;
-
- - map ootypesystem's low level operation to CLI instructions;
-
- - map Python exceptions to CLI exceptions;
-
- - write a code generator that translates a flow graph
- into a list of CLI instructions;
-
- - write a class generator that translates ootypesystem
- classes into CLI classes.
-
-
-Mapping primitive types
------------------------
-
-The `rtyper`_ give us a flow graph annotated with types belonging to
-ootypesystem: in order to produce CLI code we need to translate these
-types into their Common Type System equivalents.
-
-For numeric types the conversion is straightforward, since
-there is a one-to-one mapping between the two typesystems, so that
-e.g. Float maps to float64.
-
-For character types the choice is more difficult: RPython has two
-distinct types for plain ASCII and Unicode characters (named UniChar),
-while .NET only supports Unicode with the char type. There are at
-least two ways to map plain Char to CTS:
-
- - map UniChar to char, thus maintaining the original distinction
- between the two types: this has the advantage of being a
- one-to-one translation, but has the disadvantage that RPython
- strings will not be recognized as .NET strings, since they only
- would be sequences of bytes;
-
- - map both char, so that Python strings will be treated as strings
- also by .NET: in this case there could be problems with existing
- Python modules that use strings as sequences of byte, such as the
- built-in struct module, so we need to pay special attention.
-
-We think that mapping Python strings to .NET strings is
-fundamental, so we chose the second option.
-
-Mapping built-in types
-----------------------
-
-As we saw in section ootypesystem defines a set of types that take
-advantage of built-in types offered by the platform.
-
-For the sake of simplicity we decided to write wrappers
-around .NET classes in order to match the signatures required by
-pypylib.dll:
-
-=================== ===========================================
-ootype CLI
-=================== ===========================================
-String System.String
-StringBuilder System.Text.StringBuilder
-List System.Collections.Generic.List<T>
-Dict System.Collections.Generic.Dictionary<K, V>
-CustomDict pypy.runtime.Dict
-DictItemsIterator pypy.runtime.DictItemsIterator
-=================== ===========================================
-
-Wrappers exploit inheritance for wrapping the original classes, so,
-for example, pypy.runtime.List<T> is a subclass of
-System.Collections.Generic.List<T> that provides methods whose names
-match those found in the _GENERIC_METHODS of ootype.List
-
-The only exception to this rule is the String class, which is not
-wrapped since in .NET we can not subclass System.String. Instead, we
-provide a bunch of static methods in pypylib.dll that implement the
-methods declared by ootype.String._GENERIC_METHODS, then we call them
-by explicitly passing the string object in the argument list.
-
-
-Mapping instructions
---------------------
-
-PyPy's low level operations are expressed in Static Single Information
-(SSI) form, such as this::
-
- v2 = int_add(v0, v1)
-
-By contrast the CLI virtual machine is stack based, which means the
-each operation pops its arguments from the top of the stacks and
-pushes its result there. The most straightforward way to translate SSI
-operations into stack based operations is to explicitly load the
-arguments and store the result into the appropriate places::
-
- LOAD v0
- LOAD v1
- int_add
- STORE v2
-
-The code produced works correctly but has some inefficiency issues that
-can be addressed during the optimization phase.
-
-The CLI Virtual Machine is fairly expressive, so the conversion
-between PyPy's low level operations and CLI instruction is relatively
-simple: many operations maps directly to the corresponding
-instruction, e.g int_add and sub.
-
-By contrast some instructions do not have a direct correspondent and
-have to be rendered as a sequence of CLI instructions: this is the
-case of the "less-equal" and "greater-equal" family of instructions,
-that are rendered as "greater" or "less" followed by a boolean "not",
-respectively.
-
-Finally, there are some instructions that cannot be rendered directly
-without increasing the complexity of the code generator, such as
-int_abs (which returns the absolute value of its argument). These
-operations are translated by calling some helper function written in
-C#.
-
-The code that implements the mapping is in the modules opcodes.py.
-
-Mapping exceptions
-------------------
-
-Both RPython and CLI have their own set of exception classes: some of
-these are pretty similar; e.g., we have OverflowError,
-ZeroDivisionError and IndexError on the first side and
-OverflowException, DivideByZeroException and IndexOutOfRangeException
-on the other side.
-
-The first attempt was to map RPython classes to their corresponding
-CLI ones: this worked for simple cases, but it would have triggered
-subtle bugs in more complex ones, because the two exception
-hierarchies don't completely overlap.
-
-At the moment we've chosen to build an RPython exception hierarchy
-completely independent from the CLI one, but this means that we can't
-rely on exceptions raised by built-in operations. The currently
-implemented solution is to do an exception translation on-the-fly.
-
-As an example consider the RPython int_add_ovf operation, that sums
-two integers and raises an OverflowError exception in case of
-overflow. For implementing it we can use the built-in add.ovf CLI
-instruction that raises System.OverflowException when the result
-overflows, catch that exception and throw a new one::
-
- .try
- {
- ldarg 'x_0'
- ldarg 'y_0'
- add.ovf
- stloc 'v1'
- leave __check_block_2
- }
- catch [mscorlib]System.OverflowException
- {
- newobj instance void class OverflowError::.ctor()
- throw
- }
-
-
-Translating flow graphs
------------------------
-
-As we saw previously in PyPy function and method bodies are
-represented by flow graphs that we need to translate CLI IL code. Flow
-graphs are expressed in a format that is very suitable for being
-translated to low level code, so that phase is quite straightforward,
-though the code is a bit involved because we need to take care of three
-different types of blocks.
-
-The code doing this work is located in the Function.render
-method in the file function.py.
-
-First of all it searches for variable names and types used by
-each block; once they are collected it emits a .local IL
-statement used for indicating the virtual machine the number and type
-of local variables used.
-
-Then it sequentially renders all blocks in the graph, starting from the
-start block; special care is taken for the return block which is
-always rendered at last to meet CLI requirements.
-
-Each block starts with an unique label that is used for jumping
-across, followed by the low level instructions the block is composed
-of; finally there is some code that jumps to the appropriate next
-block.
-
-Conditional and unconditional jumps are rendered with their
-corresponding IL instructions: brtrue, brfalse.
-
-Blocks that needs to catch exceptions use the native facilities
-offered by the CLI virtual machine: the entire block is surrounded by
-a .try statement followed by as many catch as needed: each catching
-sub-block then branches to the appropriate block::
-
-
- # RPython
- try:
- # block0
- ...
- except ValueError:
- # block1
- ...
- except TypeError:
- # block2
- ...
-
- // IL
- block0:
- .try {
- ...
- leave block3
- }
- catch ValueError {
- ...
- leave block1
- }
- catch TypeError {
- ...
- leave block2
- }
- block1:
- ...
- br block3
- block2:
- ...
- br block3
- block3:
- ...
-
-There is also an experimental feature that makes GenCLI to use its own
-exception handling mechanism instead of relying on the .NET
-one. Surprisingly enough, benchmarks are about 40% faster with our own
-exception handling machinery.
-
-
-Translating classes
--------------------
-
-As we saw previously, the semantic of ootypesystem classes
-is very similar to the .NET one, so the translation is mostly
-straightforward.
-
-The related code is located in the module class\_.py. Rendered classes
-are composed of four parts:
-
- - fields;
- - user defined methods;
- - default constructor;
- - the ToString method, mainly for testing purposes
-
-Since ootype implicitly assumes all method calls to be late bound, as
-an optimization before rendering the classes we search for methods
-that are not overridden in subclasses, and declare as "virtual" only
-the one that needs to.
-
-The constructor does nothing more than calling the base class
-constructor and initializing class fields to their default value.
-
-Inheritance is straightforward too, as it is natively supported by
-CLI. The only noticeable thing is that we map ootypesystem's ROOT
-class to the CLI equivalent System.Object.
-
-The Runtime Environment
------------------------
-
-The runtime environment is a collection of helper classes and
-functions used and referenced by many of the GenCLI submodules. It is
-written in C#, compiled to a DLL (Dynamic Link Library), then linked
-to generated code at compile-time.
-
-The DLL is called pypylib and is composed of three parts:
-
- - a set of helper functions used to implements complex RPython
- low-level instructions such as runtimenew and ooparse_int;
-
- - a set of helper classes wrapping built-in types
-
- - a set of helpers used by the test framework
-
-
-The first two parts are contained in the pypy.runtime namespace, while
-the third is in the pypy.test one.
-
-
-Testing GenCLI
-==============
-
-As the rest of PyPy, GenCLI is a test-driven project: there is at
-least one unit test for almost each single feature of the
-backend. This development methodology allowed us to early discover
-many subtle bugs and to do some big refactoring of the code with the
-confidence not to break anything.
-
-The core of the testing framework is in the module
-rpython.translator.cli.test.runtest; one of the most important function
-of this module is compile_function(): it takes a Python function,
-compiles it to CLI and returns a Python object that runs the just
-created executable when called.
-
-This way we can test GenCLI generated code just as if it were a simple
-Python function; we can also directly run the generated executable,
-whose default name is main.exe, from a shell: the function parameters
-are passed as command line arguments, and the return value is printed
-on the standard output::
-
- # Python source: foo.py
- from rpython.translator.cli.test.runtest import compile_function
-
- def foo(x, y):
- return x+y, x*y
-
- f = compile_function(foo, [int, int])
- assert f(3, 4) == (7, 12)
-
-
- # shell
- $ mono main.exe 3 4
- (7, 12)
-
-GenCLI supports only few RPython types as parameters: int, r_uint,
-r_longlong, r_ulonglong, bool, float and one-length strings (i.e.,
-chars). By contrast, most types are fine for being returned: these
-include all primitive types, list, tuples and instances.
-
-Installing Python for .NET on Linux
-===================================
-
-With the CLI backend, you can access .NET libraries from RPython;
-programs using .NET libraries will always run when translated, but you
-might also want to test them on top of CPython.
-
-To do so, you can install `Python for .NET`_. Unfortunately, it does
-not work out of the box under Linux.
-
-To make it work, download and unpack the source package of Python
-for .NET; the only version tested with PyPy is the 1.0-rc2, but it
-might work also with others. Then, you need to create a file named
-Python.Runtime.dll.config at the root of the unpacked archive; put the
-following lines inside the file (assuming you are using Python 2.7)::
-
- <configuration>
- <dllmap dll="python27" target="libpython2.7.so.1.0" os="!windows"/>
- </configuration>
-
-The installation should be complete now. To run Python for .NET,
-simply type ``mono python.exe``.
-
-
-.. _`Standard Ecma 335`: http://www.ecma-international.org/publications/standards/Ecma-335.htm
-.. _`flow graph`: translation.html#the-flow-model
-.. _`rtyper`: rtyper.html
-.. _`Python for .NET`: http://pythonnet.sourceforge.net/
diff --git a/pypy/doc/clr-module.rst b/pypy/doc/clr-module.rst
deleted file mode 100644
--- a/pypy/doc/clr-module.rst
+++ /dev/null
@@ -1,143 +0,0 @@
-===============================
-The ``clr`` module for PyPy.NET
-===============================
-
-PyPy.NET give you access to the surrounding .NET environment via the
-``clr`` module. This module is still experimental: some features are
-still missing and its interface might change in next versions, but
-it's still useful to experiment a bit with PyPy.NET.
-
-PyPy.NET provides an import hook that lets you to import .NET namespaces
-seamlessly as they were normal Python modules. Then,
-
-PyPY.NET native classes try to behave as much as possible in the
-"expected" way both for the developers used to .NET and for the ones
-used to Python.
-
-In particular, the following features are mapped one to one because
-they exist in both worlds:
-
- - .NET constructors are mapped to the Python __init__ method;
-
- - .NET instance methods are mapped to Python methods;
-
- - .NET static methods are mapped to Python static methods (belonging
- to the class);
-
- - .NET properties are mapped to property-like Python objects (very
- similar to the Python ``property`` built-in);
-
- - .NET indexers are mapped to Python __getitem__ and __setitem__;
-
- - .NET enumerators are mapped to Python iterators.
-
-Moreover, all the usual Python features such as bound and unbound
-methods are available as well.
-
-Example of usage
-================
-
-Here is an example of interactive session using the ``clr`` module::
-
- >>>> from System.Collections import ArrayList
- >>>> obj = ArrayList()
- >>>> obj.Add(1)
- 0
- >>>> obj.Add(2)
- 1
- >>>> obj.Add("foo")
- 2
- >>>> print obj[0], obj[1], obj[2]
- 1 2 foo
- >>>> print obj.Count
- 3
-
-Conversion of parameters
-========================
-
-When calling a .NET method Python objects are converted to .NET
-objects. Lots of effort have been taken to make the conversion as
-much transparent as possible; in particular, all the primitive types
-such as int, float and string are converted to the corresponding .NET
-types (e.g., ``System.Int32``, ``System.Float64`` and
-``System.String``).
-
-Python objects without a corresponding .NET types (e.g., instances of
-user classes) are passed as "black boxes", for example to be stored in
-some sort of collection.
-
-The opposite .NET to Python conversions happens for the values returned
-by the methods. Again, primitive types are converted in a
-straightforward way; non-primitive types are wrapped in a Python object,
-so that they can be treated as usual.
-
-Overload resolution
-===================
-
-When calling an overloaded method, PyPy.NET tries to find the best
-overload for the given arguments; for example, consider the
-``System.Math.Abs`` method::
-
-
- >>>> from System import Math
- >>>> Math.Abs(-42)
- 42
- >>>> Math.Abs(-42.0)
- 42.0
-
-``System.Math.Abs`` has got overloadings both for integers and floats:
-in the first case we call the method ``System.Math.Abs(int32)``, while
-in the second one we call the method ``System.Math.Abs(float64)``.
-
-If the system can't find a best overload for the given parameters, a
-TypeError exception is raised.
-
-
-Generic classes
-================
-
-Generic classes are fully supported. To instantiate a generic class, you need
-to use the ``[]`` notation::
-
- >>>> from System.Collections.Generic import List
- >>>> mylist = List[int]()
- >>>> mylist.Add(42)
- >>>> mylist.Add(43)
- >>>> mylist.Add("foo")
- Traceback (most recent call last):
- File "<console>", line 1, in <interactive>
- TypeError: No overloads for Add could match
- >>>> mylist[0]
- 42
- >>>> for item in mylist: print item
- 42
- 43
-
-
-External assemblies and Windows Forms
-=====================================
-
-By default, you can only import .NET namespaces that belongs to already loaded
-assemblies. To load additional .NET assemblies, you can use
-``clr.AddReferenceByPartialName``. The following example loads
-``System.Windows.Forms`` and ``System.Drawing`` to display a simple Windows
-Form displaying the usual "Hello World" message::
-
- >>>> import clr
- >>>> clr.AddReferenceByPartialName("System.Windows.Forms")
- >>>> clr.AddReferenceByPartialName("System.Drawing")
- >>>> from System.Windows.Forms import Application, Form, Label
- >>>> from System.Drawing import Point
- >>>>
- >>>> frm = Form()
- >>>> frm.Text = "The first pypy-cli Windows Forms app ever"
- >>>> lbl = Label()
- >>>> lbl.Text = "Hello World!"
- >>>> lbl.AutoSize = True
- >>>> lbl.Location = Point(100, 100)
- >>>> frm.Controls.Add(lbl)
- >>>> Application.Run(frm)
-
-Unfortunately at the moment you can't do much more than this with Windows
-Forms, because we still miss support for delegates and so it's not possible
-to handle events.
diff --git a/pypy/doc/config/objspace.usemodules.clr.txt b/pypy/doc/config/objspace.usemodules.clr.txt
deleted file mode 100644
--- a/pypy/doc/config/objspace.usemodules.clr.txt
+++ /dev/null
@@ -1,1 +0,0 @@
-Use the 'clr' module.
diff --git a/pypy/doc/config/translation.cli.trace_calls.txt b/pypy/doc/config/translation.cli.trace_calls.txt
deleted file mode 100644
--- a/pypy/doc/config/translation.cli.trace_calls.txt
+++ /dev/null
@@ -1,3 +0,0 @@
-Internal. Debugging aid for the CLI backend.
-
-.. internal
diff --git a/pypy/doc/cpython_differences.rst b/pypy/doc/cpython_differences.rst
--- a/pypy/doc/cpython_differences.rst
+++ b/pypy/doc/cpython_differences.rst
@@ -45,7 +45,6 @@
binascii
bz2
cStringIO
- clr
cmath
`cpyext`_
crypt
diff --git a/pypy/doc/dir-reference.rst b/pypy/doc/dir-reference.rst
--- a/pypy/doc/dir-reference.rst
+++ b/pypy/doc/dir-reference.rst
@@ -85,14 +85,9 @@
from an
RPython program (generally via the rtyper_)
-`rpython/translator/cli/`_ the `CLI backend`_ for `.NET`_
- (Microsoft CLR or Mono_)
-
`pypy/goal/`_ our `main PyPy-translation scripts`_
live here
-`rpython/translator/jvm/`_ the Java backend
-
`rpython/translator/tool/`_ helper tools for translation
`dotviewer/`_ `graph viewer`_
@@ -123,7 +118,6 @@
.. _`testing methods`: coding-guide.html#testing-in-pypy
.. _`translation`: translation.html
.. _`GenC backend`: translation.html#genc
-.. _`CLI backend`: cli-backend.html
.. _`py.py`: getting-started-python.html#the-py.py-interpreter
.. _`translatorshell.py`: getting-started-dev.html#try-out-the-translator
.. _JIT: jit/index.html
diff --git a/pypy/doc/discussion/VM-integration.rst b/pypy/doc/discussion/VM-integration.rst
deleted file mode 100644
--- a/pypy/doc/discussion/VM-integration.rst
+++ /dev/null
@@ -1,263 +0,0 @@
-==============================================
-Integration of PyPy with host Virtual Machines
-==============================================
-
-This document is based on the discussion I had with Samuele during the
-Duesseldorf sprint. It's not much more than random thoughts -- to be
-reviewed!
-
-Terminology disclaimer: both PyPy and .NET have the concept of
-"wrapped" or "boxed" objects. To avoid confusion I will use "wrapping"
-on the PyPy side and "boxing" on the .NET side.
-
-General idea
-============
-
-The goal is to find a way to efficiently integrate the PyPy
-interpreter with the hosting environment such as .NET. What we would
-like to do includes but it's not limited to:
-
- - calling .NET methods and instantiate .NET classes from Python
-
- - subclass a .NET class from Python
-
- - handle native .NET objects as transparently as possible
-
- - automatically apply obvious Python <--> .NET conversions when
- crossing the borders (e.g. integers, string, etc.)
-
-One possible solution is the "proxy" approach, in which we manually
-(un)wrap/(un)box all the objects when they cross the border.
-
-Example
--------
-
- ::
-
- public static int foo(int x) { return x}
-
- >>>> from somewhere import foo
- >>>> print foo(42)
-
-In this case we need to take the intval field of W_IntObject, box it
-to .NET System.Int32, call foo using reflection, then unbox the return
-value and reconstruct a new (or reuse an existing one) W_IntObject.
-
-The other approach
-------------------
-
-The general idea to solve handle this problem is to split the
-"stateful" and "behavioral" parts of wrapped objects, and use already
-boxed values for storing the state.
-
-This way when we cross the Python --> .NET border we can just throw
-away the behavioral part; when crossing .NET --> Python we have to
-find the correct behavioral part for that kind of boxed object and
-reconstruct the pair.
-
-
-Split state and behaviour in the flowgraphs
-===========================================
-
-The idea is to write a graph transformation that takes an usual
-ootyped flowgraph and split the classes and objects we want into a
-stateful part and a behavioral part.
-
-We need to introduce the new ootypesystem type ``Pair``: it acts like
-a Record but it hasn't its own identity: the id of the Pair is the id
-of its first member.
-
- XXX about ``Pair``: I'm not sure this is totally right. It means
- that an object can change identity simply by changing the value of a
- field??? Maybe we could add the constraint that the "id" field
- can't be modified after initialization (but it's not easy to
- enforce).
-
- XXX-2 about ``Pair``: how to implement it in the backends? One
- possibility is to use "struct-like" types if available (as in
- .NET). But in this case it's hard to implement methods/functions
- that modify the state of the object (such as __init__, usually). The
- other possibility is to use a reference type (i.e., a class), but in
- this case there will be a gap between the RPython identity (in which
- two Pairs with the same state are indistinguishable) and the .NET
- identity (in which the two objects will have a different identity,
- of course).
-
-Step 1: RPython source code
----------------------------
-
- ::
-
- class W_IntObject:
- def __init__(self, intval):
- self.intval = intval
-
- def foo(self, x):
- return self.intval + x
-
- def bar():
- x = W_IntObject(41)
- return x.foo(1)
-
-
-Step 2: RTyping
----------------
-
-Sometimes the following examples are not 100% accurate for the sake of
-simplicity (e.g: we directly list the type of methods instead of the
-ootype._meth instances that contains it).
-
-Low level types
-
- ::
-
- W_IntObject = Instance(
- "W_IntObject", # name
- ootype.OBJECT, # base class
- {"intval": (Signed, 0)}, # attributes
- {"foo": Meth([Signed], Signed)} # methods
- )
-
-
-Prebuilt constants (referred by name in the flowgraphs)
-
- ::
-
- W_IntObject_meta_pbc = (...)
- W_IntObject.__init__ = (static method pbc - see below for the graph)
-
-
-Flowgraphs
-
- ::
-
- bar() {
- 1. x = new(W_IntObject)
- 2. oosetfield(x, "meta", W_IntObject_meta_pbc)
- 3. direct_call(W_IntObject.__init__, x, 41)
- 4. result = oosend("foo", x, 1)
- 5. return result
- }
-
- W_IntObject.__init__(W_IntObject self, Signed intval) {
- 1. oosetfield(self, "intval", intval)
- }
-
- W_IntObject.foo(W_IntObject self, Signed x) {
- 1. value = oogetfield(self, "value")
- 2. result = int_add(value, x)
- 3. return result
- }
-
-Step 3: Transformation
-----------------------
-
-This step is done before the backend plays any role, but it's still
-driven by its need, because at this time we want a mapping that tell
-us what classes to split and how (i.e., which boxed value we want to
-use).
-
-Let's suppose we want to map W_IntObject.intvalue to the .NET boxed
-``System.Int32``. This is possible just because W_IntObject contains
-only one field. Note that the "meta" field inherited from
-ootype.OBJECT is special-cased because we know that it will never
-change, so we can store it in the behaviour.
-
-
-Low level types
-
- ::
-
- W_IntObject_bhvr = Instance(
- "W_IntObject_bhvr",
- ootype.OBJECT,
- {}, # no more fields!
- {"foo": Meth([W_IntObject_pair, Signed], Signed)} # the Pair is also explicitly passed
- )
-
- W_IntObject_pair = Pair(
- ("value", (System.Int32, 0)), # (name, (TYPE, default))
- ("behaviour", (W_IntObject_bhvr, W_IntObject_bhvr_pbc))
- )
-
-
-Prebuilt constants
-
- ::
-
- W_IntObject_meta_pbc = (...)
- W_IntObject.__init__ = (static method pbc - see below for the graph)
- W_IntObject_bhvr_pbc = new(W_IntObject_bhvr); W_IntObject_bhvr_pbc.meta = W_IntObject_meta_pbc
- W_IntObject_value_default = new System.Int32(0)
-
-
-Flowgraphs
-
- ::
-
- bar() {
- 1. x = new(W_IntObject_pair) # the behaviour has been already set because
- # it's the default value of the field
-
- 2. # skipped (meta is already set in the W_IntObject_bhvr_pbc)
-
- 3. direct_call(W_IntObject.__init__, x, 41)
-
- 4. bhvr = oogetfield(x, "behaviour")
- result = oosend("foo", bhvr, x, 1) # note that "x" is explicitly passed to foo
-
- 5. return result
- }
-
- W_IntObject.__init__(W_IntObjectPair self, Signed value) {
- 1. boxed = clibox(value) # boxed is of type System.Int32
- oosetfield(self, "value", boxed)
- }
-
- W_IntObject.foo(W_IntObject_bhvr bhvr, W_IntObject_pair self, Signed x) {
- 1. boxed = oogetfield(self, "value")
- value = unbox(boxed, Signed)
-
- 2. result = int_add(value, x)
-
- 3. return result
- }
-
-
-Inheritance
------------
-
-Apply the transformation to a whole class (sub)hierarchy is a bit more
-complex. Basically we want to mimic the same hierarchy also on the
-``Pair``\s, but we have to fight the VM limitations. In .NET for
-example, we can't have "covariant fields"::
-
- class Base {
- public Base field;
- }
-
- class Derived: Base {
- public Derived field;
- }
-
-A solution is to use only kind of ``Pair``, whose ``value`` and
-``behaviour`` type are of the most precise type that can hold all the
-values needed by the subclasses::
-
- class W_Object: pass
- class W_IntObject(W_Object): ...
- class W_StringObject(W_Object): ...
-
- ...
-
- W_Object_pair = Pair(System.Object, W_Object_bhvr)
-
-Where ``System.Object`` is of course the most precise type that can
-hold both ``System.Int32`` and ``System.String``.
-
-This means that the low level type of all the ``W_Object`` subclasses
-will be ``W_Object_pair``, but it also means that we will need to
-insert the appropriate downcasts every time we want to access its
-fields. I'm not sure how much this can impact performances.
-
-
diff --git a/pypy/doc/discussion/outline-external-ootype.rst b/pypy/doc/discussion/outline-external-ootype.rst
deleted file mode 100644
--- a/pypy/doc/discussion/outline-external-ootype.rst
+++ /dev/null
@@ -1,187 +0,0 @@
-Some discussion about external objects in ootype
-================================================
-
-Current approach:
-
-* SomeCliXxx for .NET backend
-
-SomeCliXxx
-----------
-
-* Supports method overloading
-
-* Supports inheritance in a better way
-
-* Supports static methods
-
-Would be extremely cool to generalize the approach to be useful also for the
-JVM backend. Here are some notes:
-
-* There should be one mechanism, factored out nicely out of any backend,
- to support any possible backend (cli, jvm for now).
-
-* This approach might be eventually extended by a backend itself, but
- as much as possible code should be factored out.
-
-* Backend should take care itself about creating such classes, either
- manually or automatically.
-
-* Should support superset of needs of all backends (ie callbacks,
- method overloading, etc.)
-
-
-Proposal of alternative approach
-================================
-
-The goal of the task is to let RPython program access "external
-entities" which are available in the target platform; these include:
-
- - external classes (e.g. for .NET: System.Collections.ArrayList)
-
- - external prebuilt instances (e.g. for .NET: typeof(System.Console))
-
-External entities should behave as much as possible as "internal
-entities".
-
-Moreover, we want to preserve the possibility of *testing* RPython
-programs on top of CPython if possible. For example, it should be
-possible to RPython programs using .NET external objects using
-PythonNet; for JVM, there are JPype_ and JTool_, to be investigated:
-
-.. _JPype: http://jpype.sourceforge.net/
-.. _JTool: http://wiki.europython.eu/Talks/Jtool%20Java%20In%20The%20Python%20Vm
-
-How to represent types
-----------------------
-
-First, some definitions:
-
- - high-level types are the types used by the annotator
- (SomeInteger() & co.)
-
- - low-level types are the types used by the rtyper (Signed & co.)
-
- - platform-level types are the types used by the backends (e.g. int32 for
- .NET)
-
-Usually, RPython types are described "top-down": we start from the
-annotation, then the rtyper transforms the high-level types into
-low-level types, then the backend transforms low-level types into
-platform-level types. E.g. for .NET, SomeInteger() -> Signed -> int32.
-
-External objects are different: we *already* know the platform-level
-types of our objects and we can't modify them. What we need to do is
-to specify an annotation that after the high-level -> low-level ->
-platform-level transformation will give us the correct types.
-
-For primitive types it is usually easy to find the correct annotation;
-if we have an int32, we know that it's ootype is Signed and the
-corresponding annotation is SomeInteger().
-
-For non-primitive types such as classes, we must use a "bottom-up"
-approach: first, we need a description of platform-level interface of
-the class; then we construct the corresponding low-level type and
-teach the backends how to treat such "external types". Finally, we
-wrap the low-level types into special "external annotation".
-
-For example, consider a simple existing .NET class::
-
- class Foo {
- public float bar(int x, int y) { ... }
- }
-
-The corresponding low-level type could be something like this::
-
- Foo = ootype.ExternalInstance({'bar': ([Signed, Signed], Float)})
-
-Then, the annotation for Foo's instances is SomeExternalInstance(Foo).
-This way, the transformation from high-level types to platform-level
-types is straightforward and correct.
-
-Finally, we need support for static methods: similarly for classes, we
-can define an ExternalStaticMeth low-level type and a
-SomeExternalStaticMeth annotation.
-
-
-How to describe types
----------------------
-
-To handle external objects we must specify their signatures. For CLI
-and JVM the job can be easily automatized, since the objects have got
-precise signatures.
-
-
-RPython interface
------------------
-
-External objects are exposed as special Python objects that gets
-annotated as SomeExternalXXX. Each backend can choose its own way to
-provide these objects to the RPython programmer.
-
-External classes will be annotated as SomeExternalClass; two
-operations are allowed:
-
- - call: used to instantiate the class, return an object which will
- be annotated as SomeExternalInstance.
-
- - access to static methods: return an object which will be annotated
- as SomeExternalStaticMeth.
-
-Instances are annotated as SomeExternalInstance. Prebuilt external objects are
-annotated as SomeExternalInstance(const=...).
-
-Open issues
------------
-
-Exceptions
-~~~~~~~~~~
-
-.NET and JVM users want to catch external exceptions in a natural way;
-e.g.::
-
- try:
- ...
- except System.OverflowException:
- ...
-
-This is not straightforward because to make the flow objspace happy the
-object which represent System.OverflowException must be a real Python
-class that inherits from Exception.
-
-This means that the Python objects which represent external classes
-must be Python classes itself, and that classes representing
-exceptions must be special cased and made subclasses of Exception.
-
-
-Inheritance
-~~~~~~~~~~~
-
-It would be nice to allow programmers to inherit from an external
-class. Not sure about the implications, though.
-
-Special methods/properties
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-In .NET there are special methods that can be accessed using a special
-syntax, for example indexer or properties. It would be nice to have in
-RPython the same syntax as C#, although we can live without that.
-
-
-Implementation details
-----------------------
-
-The CLI backend use a similar approach right now, but it could be
-necessary to rewrite a part of it.
-
-To represent low-level types, it uses NativeInstance, a subclass of
-ootype.Instance that contains all the information needed by the
-backend to reference the class (e.g., the namespace). It also supports
-overloading.
-
-For annotations, it reuses SomeOOInstance, which is also a wrapper
-around a low-level type but it has been designed for low-level
-helpers. It might be saner to use another annotation not to mix apples
-and oranges, maybe factoring out common code.
-
-I don't know whether and how much code can be reused from the existing
-bltregistry.
diff --git a/pypy/doc/dot-net.rst b/pypy/doc/dot-net.rst
deleted file mode 100644
--- a/pypy/doc/dot-net.rst
+++ /dev/null
@@ -1,11 +0,0 @@
-.NET support
-============
-
- .. warning::
-
- The .NET backend within PyPy is unmaintained. This documentation may be out-of-date. We welcome contributors who are interested in doing the work to get this into shape.
-
-.. toctree::
-
- cli-backend.rst
- clr-module.rst
diff --git a/pypy/doc/faq.rst b/pypy/doc/faq.rst
--- a/pypy/doc/faq.rst
+++ b/pypy/doc/faq.rst
@@ -369,13 +369,11 @@
Which backends are there for the RPython toolchain?
---------------------------------------------------
-Currently, there are backends for C_, the CLI_, and the JVM_.
-All of these can translate the entire PyPy interpreter.
+Currently, there only backends is C_.
+It can translate the entire PyPy interpreter.
To learn more about backends take a look at the `translation document`_.
.. _C: translation.html#the-c-back-end
-.. _CLI: cli-backend.html
-.. _JVM: translation.html#genjvm
.. _`translation document`: translation.html
------------------
diff --git a/pypy/doc/getting-started-python.rst b/pypy/doc/getting-started-python.rst
--- a/pypy/doc/getting-started-python.rst
+++ b/pypy/doc/getting-started-python.rst
@@ -6,7 +6,7 @@
PyPy's Python interpreter is a very compliant Python
-interpreter implemented in RPython. When compiled, it passes most of
+interpreter implemented in RPython. When compiled, it passes most of
`CPythons core language regression tests`_ and comes with many of the extension
modules included in the standard library including ``ctypes``. It can run large
libraries such as Django_ and Twisted_. There are some small behavioral
@@ -18,8 +18,8 @@
.. _`CPython differences`: cpython_differences.html
-To actually use PyPy's Python interpreter, the first thing to do is to
-`download a pre-built PyPy`_ for your architecture.
+To actually use PyPy's Python interpreter, the first thing to do is to
+`download a pre-built PyPy`_ for your architecture.
.. _`download a pre-built PyPy`: http://pypy.org/download.html
@@ -31,8 +31,8 @@
.. _`windows document`: windows.html
-You can translate the whole of PyPy's Python interpreter to low level C code,
-or `CLI code`_. If you intend to build using gcc, check to make sure that
+You can translate the whole of PyPy's Python interpreter to low level C code.
+If you intend to build using gcc, check to make sure that
the version you have is not 4.2 or you will run into `this bug`_.
.. _`this bug`: https://bugs.launchpad.net/ubuntu/+source/gcc-4.2/+bug/187391
@@ -71,9 +71,9 @@
3. Translation is time-consuming -- 45 minutes on a very fast machine --
- and RAM-hungry. As of March 2011, you will need **at least** 2 GB of
- memory on a
- 32-bit machine and 4GB on a 64-bit machine. If your memory resources
+ and RAM-hungry. As of March 2011, you will need **at least** 2 GB of
+ memory on a
+ 32-bit machine and 4GB on a 64-bit machine. If your memory resources
are constrained, or your machine is slow you might want to pick the
`optimization level`_ `1` in the next step. A level of
`2` or `3` or `jit` gives much better results, though. But if all
@@ -82,7 +82,7 @@
Let me stress this again: at ``--opt=1`` you get the Boehm
GC, which is here mostly for historical and for testing reasons.
- You really do not want to pick it for a program you intend to use.
+ You really do not want to pick it for a program you intend to use.
The resulting ``pypy-c`` is slow.
4. Run::
@@ -119,7 +119,7 @@
>>>> pystone.main()
Pystone(1.1) time for 50000 passes = 0.060004
This machine benchmarks at 833278 pystones/second
- >>>>
+ >>>>
Note that pystone gets faster as the JIT kicks in.
This executable can be moved around or copied on other machines; see
@@ -194,22 +194,22 @@
cd pypy
python bin/pyinteractive.py
-After a few seconds (remember: this is running on top of CPython),
-you should be at the PyPy prompt, which is the same as the Python
+After a few seconds (remember: this is running on top of CPython),
+you should be at the PyPy prompt, which is the same as the Python
prompt, but with an extra ">".
Now you are ready to start running Python code. Most Python
-modules should work if they don't involve CPython extension
+modules should work if they don't involve CPython extension
modules. **This is slow, and most C modules are not present by
default even if they are standard!** Here is an example of
-determining PyPy's performance in pystones::
+determining PyPy's performance in pystones::
- >>>> from test import pystone
+ >>>> from test import pystone
>>>> pystone.main(10)
The parameter is the number of loops to run through the test. The
default is 50000, which is far too many to run in a non-translated
-PyPy version (i.e. when PyPy's interpreter itself is being interpreted
+PyPy version (i.e. when PyPy's interpreter itself is being interpreted
by CPython).
pyinteractive.py options
@@ -236,9 +236,7 @@
.. _Mono: http://www.mono-project.com/Main_Page
-.. _`CLI backend`: cli-backend.html
.. _`Boehm-Demers-Weiser garbage collector`: http://www.hpl.hp.com/personal/Hans_Boehm/gc/
-.. _clr: clr-module.html
.. _`CPythons core language regression tests`: http://buildbot.pypy.org/summary?category=applevel&branch=%3Ctrunk%3E
.. include:: _ref.txt
diff --git a/pypy/doc/glossary.rst b/pypy/doc/glossary.rst
--- a/pypy/doc/glossary.rst
+++ b/pypy/doc/glossary.rst
@@ -84,12 +84,6 @@
extend or twist these semantics, or c) serve whole-program analysis
purposes.
- ootypesystem
- An `object oriented type model <rtyper.html#object-oriented-types>`__
- containing classes and instances. A :term:`backend` that uses this type system
- is also called a high-level backend. The JVM and CLI backends
- all use this typesystem.
-
prebuilt constant
In :term:`RPython` module globals are considered constants. Moreover,
global (i.e. prebuilt) lists and dictionaries are supposed to be
diff --git a/pypy/doc/project-documentation.rst b/pypy/doc/project-documentation.rst
--- a/pypy/doc/project-documentation.rst
+++ b/pypy/doc/project-documentation.rst
@@ -72,8 +72,6 @@
`command line reference`_
-`CLI backend`_ describes the details of the .NET backend.
-
`JIT Generation in PyPy`_ describes how we produce the Python Just-in-time Compiler
from our Python interpreter.
diff --git a/pypy/doc/rtyper.rst b/pypy/doc/rtyper.rst
--- a/pypy/doc/rtyper.rst
+++ b/pypy/doc/rtyper.rst
@@ -432,226 +432,6 @@
See for example `rpython/rtyper/rlist.py`_.
-.. _`oo type`:
-
-Object Oriented Types
----------------------
-
-The standard `low-level type` model described above is fine for
-targeting low level backends such as C, but it is not good
-enough for targeting higher level backends such as .NET CLI or Java
-JVM, so a new object oriented model has been introduced. This model is
-implemented in the first part of `rpython/rtyper/ootypesystem/ootype.py`_.
-
-As for the low-level typesystem, the second part of
-`rpython/rtyper/ootypesystem/ootype.py`_ is a runnable implementation of
-these types, for testing purposes.
-
-
-The target platform
-+++++++++++++++++++
-
-There are plenty of object oriented languages and platforms around,
-each one with its own native features: they could be statically or
-dynamically typed, they could support or not things like multiple
-inheritance, classes and functions as first class order objects,
-generics, and so on.
-
-The goal of *ootypesystem* is to define a trade-off between all
-the potential backends that let them to use the native facilities when
-available while not preventing other backends to work when they
-aren't.
-
-
-Types and classes
-+++++++++++++++++
-
-Most of the primitive types defined in *ootypesystem* are the very
-same of those found in *lltypesystem*: ``Bool``, ``Signed``,
-``Unsigned``, ``Float``, ``Char``, ``UniChar`` and ``Void``.
-
-The target platform is supposed to support classes and instances with
-**single inheritance**. Instances of user-defined classes are mapped
-to the ``Instance`` type, whose ``_superclass`` attribute indicates
-the base class of the instance. At the very beginning of the
-inheritance hierarchy there is the ``Root`` object, i.e. the common
-base class between all instances; if the target platform has the
-notion of a common base class too, the backend can choose to map the
-``Root`` class to its native equivalent.
-
-Object of ``Instance`` type can have attributes and methods:
-attributes are got and set by the ``oogetfield`` and ``oosetfield``
-operations, while method calls are expressed by the ``oosend``
-operation.
-
-Classes are passed around using the ``Class`` type: this is a first
-order class type whose only goal is to allow **runtime instantiation**
-of the class. Backends that don't support this feature natively, such
-as Java, may need to use some sort of placeholder instead.
-
-
-Static vs. dynamic typing
-+++++++++++++++++++++++++
-
-The target platform is assumed to be **statically typed**, i.e. the
-type of each object is known at compile time.
-
-As usual, it is possible to convert an object from type to type only
-under certain conditions; there is a number of predefined conversions
-between primitive types such as from ``Bool`` to ``Signed`` or from
-``Signed`` to ``Float``. For each one of these conversions there is a
-corresponding low level operation, such as ``cast_bool_to_int`` and
-``cast_int_to_float``.
-
-Moreover it is possible to cast instances of a class up and down the
-inheritance hierarchy with the ``ooupcast`` and ``oodowncast`` low
-level operations. Implicit upcasting is not allowed, so you really
-need to do a ``ooupcast`` for converting from a subclass to a
-superclass.
-
-With this design statically typed backends can trivially insert
-appropriate casts when needed, while dynamically typed backends can
-simply ignore some of the operation such as ``ooupcast`` and
-``oodowncast``. Backends that supports implicit upcasting, such as CLI
-and Java, can simply ignore only ``ooupcast``.
-
-Object model
-++++++++++++
-
-The object model implemented by ootype is quite Java-like. The
-following is a list of key features of the ootype object model which
-have a direct correspondence in the Java or .NET object model:
-
- - classes have a static set of strongly typed methods and
- attributes;
-
- - methods can be overriden in subclasses; every method is "virtual"
- (i.e., can be overridden); methods can be "abstract" (i.e., need
- to be overridden in subclasses);
-
- - classes support single inheritance; all classes inherit directly
- or indirectly from the ROOT class;
-
- - there is some support for method overloading. This feature is not
- used by the RTyper itself because RPython doesn't support method
- overloading, but it is used by the GenCLI backend for offering
- access to the native .NET libraries (see XXX);
-
- - all classes, attributes and methods are public: ootype is only
- used internally by the translator, so there is no need to enforce
- accessibility rules;
-
- - classes and functions are first-class order objects: this feature
- can be easily simulated by backends for platforms on which it is not
- a native feature;
-
- - there is a set of `built-in types`_ offering standard features.
-
-Exception handling
-++++++++++++++++++
-
-Since flow graphs are meant to be used also for very low level
-backends such as C, they are quite unstructured: this means that the
-target platform doesn't need to have a native exception handling
-mechanism, since at the very least the backend can handle exceptions
-just like ``genc`` does.
-
-By contrast we know that most of high level platforms natively support
-exception handling, so *ootypesystem* is designed to let them to use
-it. In particular the exception instances are typed with the
-``Instance`` type, so the usual inheritance exception hierarchy is
-preserved and the native way to catch exception should just work.
-
-.. `built-in types`_
-
-Built-in types
-++++++++++++++
-
-It seems reasonable to assume high level platforms to provide built-in
-facilities for common types such as *lists* or *hashtables*.
-
-RPython standard types such as ``List`` and ``Dict`` are implemented
-on top of these common types; at the moment of writing there are six
-built-in types:
-
- - **String**: self-descriptive
-
- - **StringBuilder**: used for dynamic building of string
-
- - **List**: a variable-sized, homogeneous list of object
-
- - **Dict**: a hashtable of homogeneous keys and values
-
- - **CustomDict**: same as dict, but with custom equal and hash
- functions
-
- - **DictItemsIterator**: a helper class for iterating over the
- elements of a ``Dict``
-
-
-Each of these types is a subtype of ``BuiltinADTType`` and has set of
-ADT (Abstract Data Type) methods (hence the name of the base class)
-for being manipulated. Examples of ADT methods are ``ll_length`` for
-``List`` and ``ll_get`` for ``Dict``.
-
-From the backend point of view an instance of a built-in types is
-treated exactly as a plain ``Instance``, so usually no special-casing
-is needed. The backend is supposed to provide a bunch of classes
-wrapping the native ones in order to provide the right signature and
-semantic for the ADT methods.
-
-As an alternative, backends can special-case the ADT types to map them
-directly to the native equivalent, translating the method names
-on-the-fly at compile time.
-
-Generics
-++++++++
-
-Some target platforms offer native support for **generics**, i.e.
-classes that can be parametrized on types, not only values. For
-example, if one wanted to create a list using generics, a possible
-declaration would be to say ``List<T>``, where ``T`` represented the
-type. When instantiated, one could create ``List<Integer>`` or
-``List<Animal>``. The list is then treated as a list of whichever type
-is specified.
-
-Each subclass of ``BuiltinADTTypes`` defines a bunch of type
-parameters by creating some class level placeholder in the form of
-``PARAMNAME_T``; then it fills up the ``_GENERIC_METHODS`` attribute
-by defining the signature of each of the ADT methods using those
-placeholders in the appropriate places. As an example, here is an
-extract of *ootypesystem*'s List type::
-
- class List(BuiltinADTType):
- # placeholders for types
- SELFTYPE_T = object()
- ITEMTYPE_T = object()
-
- ...
-
- def _init_methods(self):
- # 'ITEMTYPE_T' is used as a placeholder for indicating
- # arguments that should have ITEMTYPE type. 'SELFTYPE_T' indicates 'self'
-
- self._GENERIC_METHODS = frozendict({
- "ll_length": Meth([], Signed),
- "ll_getitem_fast": Meth([Signed], self.ITEMTYPE_T),
- "ll_setitem_fast": Meth([Signed, self.ITEMTYPE_T], Void),
- "_ll_resize_ge": Meth([Signed], Void),
- "_ll_resize_le": Meth([Signed], Void),
- "_ll_resize": Meth([Signed], Void),
- })
-
- ...
-
-Thus backends that support generics can simply look for placeholders
-for discovering where the type parameters are used. Backends that
-don't support generics can simply use the ``Root`` class instead and
-insert the appropriate casts where needed. Note that placeholders
-might also stand for primitive types, which typically require more
-involved casts: e.g. in Java, making wrapper objects around ints.
-
-
HighLevelOp interface
---------------------
diff --git a/pypy/doc/translation.rst b/pypy/doc/translation.rst
--- a/pypy/doc/translation.rst
+++ b/pypy/doc/translation.rst
@@ -27,15 +27,10 @@
this task into several steps, and the purpose of this document is to
introduce them.
-As of the 1.2 release, RPython_ programs can be translated into the following
-languages/platforms: C/POSIX, CLI/.NET
-and Java/JVM.
-
.. _`application-level`: coding-guide.html#application-level
.. _`interpreter-level`: coding-guide.html#interpreter-level
-The choice of the target platform affects the process somewhat, but to
-start with we describe the process of translating an RPython_ program into
+To start with we describe the process of translating an RPython_ program into
C (which is the default and original target).
.. _`initialization time`:
@@ -654,54 +649,6 @@
Use the :config:`translation.backend` option to choose which backend to use.
-
-The Object-Oriented Backends
-----------------------------
-
-The Object-Oriented backends target platforms that are less C-like and support
-classes, instance etc. If such a platform is targeted, the `OO type system` is
-used while rtyping. Of the OO backends, both gencli and genjava can translate
-the full Python interpreter.
-
-.. _`oo type system`: rtyper.html#oo-type
-
-.. mention that pretty much all these backends are done by volunteers?
-
-GenCLI
-++++++
-
-GenCLI_ targets the `Common Language Infrastructure`_, the most famous
-implementations of which are Microsoft's `.NET`_ and Mono_.
-
-It is the most advanced of the object oriented backends -- it can
-compile the PyPy interpreter as well as our two standard benchmarks,
-RPyStone (CPython's PyStone benchmark modified slightly to be RPython)
-and a RPython version of the common Richards benchmark.
-
-It is almost entirely the work of Antonio Cuni, who started this
-backend as part of his `Master's thesis`_, the Google's Summer of Code
-2006 program and the Summer of PyPy program.
-
-.. _`Common Language Infrastructure`: http://www.ecma-international.org/publications/standards/Ecma-335.htm
-.. _`.NET`: http://www.microsoft.com/net/
-.. _Mono: http://www.mono-project.com/
-.. _`Master's thesis`: http://buildbot.pypy.org/misc/Implementing%20Python%20in%20.NET.pdf
-.. _GenCLI: cli-backend.html
-
-GenJVM
-++++++
-
-GenJVM targets the Java Virtual Machine: it translates RPython
-programs directly into Java bytecode, similarly to what GenCLI does.
-
-So far it is the second most mature high level backend after GenCLI:
-it still can't translate the full Standard Interpreter, but after the
-Leysin sprint we were able to compile and run the rpystone and
-richards benchmarks.
-
-GenJVM is almost entirely the work of Niko Matsakis, who worked on it
-also as part of the Summer of PyPy program.
-
.. _extfunccalls:
External Function Calls
More information about the pypy-commit
mailing list