[pypy-svn] r41230 - pypy/dist/pypy/doc
hpk at codespeak.net
hpk at codespeak.net
Sat Mar 24 12:37:01 CET 2007
Author: hpk
Date: Sat Mar 24 12:37:00 2007
New Revision: 41230
Modified:
pypy/dist/pypy/doc/new-architecture.txt
Log:
use a bit more telling variable names for not-so-mathematically
trained people
Modified: pypy/dist/pypy/doc/new-architecture.txt
==============================================================================
--- pypy/dist/pypy/doc/new-architecture.txt (original)
+++ pypy/dist/pypy/doc/new-architecture.txt Sat Mar 24 12:37:00 2007
@@ -48,28 +48,29 @@
aspects and produce custom implementations for particular feature
and platform configurations.
-Particularly, we want to help avoiding having to write ``n * m * o``
-interpreters for ``n`` dynamic languages and ``m`` platforms
+Particularly, we want to help avoiding having to write ``l * o * p``
+interpreters for ``l`` dynamic languages and ``p`` platforms
with ``o`` crucial design decisions. PyPy aims at having any
one of these parameters changeable independently from each
other:
-* ``n``: modify or replace the language we analyse and regenerate
+* ``l``: modify or replace the language we analyse and regenerate
a concrete interpreter for each target;
-* ``m``: write new translator back-ends to target new
- physical and virtual platforms;
-
* ``o``: tweak and optimize the translation process to produce
platform specific code based on different models and tradeoffs.
+* ``p``: write new translator back-ends to target
+ physical and virtual platforms;
+
+
By contrast, a standardized target environment - say .NET -
-enforces ``m=1`` as far as it's concerned. This helps making ``o`` a
+enforces ``p=1`` as far as it's concerned. This helps making ``o`` a
bit smaller by providing a higher-level base to build upon. Still,
we believe that enforcing the use of one common environment
is not necessary. PyPy's goal is to give weight to this claim - at least
as far as language implementation is concerned - showing an approach
-to the ``n * m * o`` problem that does not rely on standardization.
+to the ``l * o * p`` problem that does not rely on standardization.
Particularly, we set ourselves the goal to *generate
Just-In-Time Compilers* in addition to traditional
More information about the Pypy-commit
mailing list