[pypy-svn] r64236 - pypy/trunk/pypy/doc

[cfbolz at codespeak.net]

Author: cfbolz
Date: Fri Apr 17 12:05:45 2009
New Revision: 64236

Modified:
   pypy/trunk/pypy/doc/dynamic-language-translation.txt
   pypy/trunk/pypy/doc/getting-started.txt
   pypy/trunk/pypy/doc/translation-aspects.txt
Log:
kill more references to llvm


Modified: pypy/trunk/pypy/doc/dynamic-language-translation.txt
==============================================================================
--- pypy/trunk/pypy/doc/dynamic-language-translation.txt	(original)
+++ pypy/trunk/pypy/doc/dynamic-language-translation.txt	Fri Apr 17 12:05:45 2009
@@ -321,7 +321,7 @@
   target language.  This part depends strongly on the details of the
   target language, so little code can be shared between the different
   back-ends (even between back-ends taking as input the same low-level
-  flow graphs, e.g. the C and the LLVM_ back-ends).  The back-end is
+  flow graphs, e.g. the C and the LLVM back-ends).  The back-end is
   also responsible for integrating with some of the most
   platform-dependent aspects like memory management and exception
   model, as well as for generating alternate styles of code for
@@ -2048,7 +2048,7 @@
   based on the low-level flow graphs thus obtained.
 
 We can currently generate C-like low-level flow graphs and turn them
-into either C or LLVM_ code; or experimentally, PowerPC machine code or
+into either C or LLVM code; or experimentally, PowerPC machine code or
 JavaScript_.  If we go through slightly less low-level flow graphs
 instead, we can also interface with back-ends generating bytecode for
 JVM, CLI/.NET and even Javascript.
@@ -2171,7 +2171,7 @@
 styles of code for different execution models like coroutines.
 
 We will give as an example an overview of the `GenC back-end`_.  The
-`LLVM back-end`_ works at the same level.  The CLI and JVM
+LLVM back-end works at the same level.  The CLI and JVM
 back-ends take ootyped graphs instead, as described above, and faces
 different problems.
 
@@ -2319,8 +2319,6 @@
 
 * Lattice: http://en.wikipedia.org/wiki/Lattice_%28order%29
 
-* LLVM (Low-Level Virtual Machine): http://llvm.org/
-
 * Low-level Types: see [TR]_.
 
 * Object Space: http://codespeak.net/pypy/trunk/pypy/doc/objspace.html
@@ -2346,10 +2344,8 @@
 .. _`ACM SIGPLAN 2004 paper`: http://psyco.sourceforge.net/psyco-pepm-a.ps.gz
 .. _`Hindley-Milner`: http://en.wikipedia.org/wiki/Hindley-Milner_type_inference
 .. _SSA: http://en.wikipedia.org/wiki/Static_single_assignment_form
-.. _LLVM: http://llvm.org/
 .. _`RTyper reference`: rtyper.html
 .. _`GenC back-end`: translation.html#genc
-.. _`LLVM back-end`: translation.html#llvm
 .. _JavaScript: http://www.ecma-international.org/publications/standards/Ecma-262.htm
 .. _lltype: rtyper.html#low-level-types
 .. _`post on the Perl 6 compiler mailing list`: http://www.nntp.perl.org/group/perl.perl6.compiler/1107

Modified: pypy/trunk/pypy/doc/getting-started.txt
==============================================================================
--- pypy/trunk/pypy/doc/getting-started.txt	(original)
+++ pypy/trunk/pypy/doc/getting-started.txt	Fri Apr 17 12:05:45 2009
@@ -133,7 +133,7 @@
 interpreter`_ and the `special PyPy features`_, or directly proceed to
 `translating the PyPy Python interpreter`_.  This allows you to try out
 real Python applications in a fast version of PyPy, compiled via C,
-LLVM, .NET or Java, with or without special features included.
+.NET or Java, with or without special features included.
 
 Main entry point  
 ------------------------------------------
@@ -787,11 +787,6 @@
 .. _`contact possibilities`: home.html
 
 .. _`py library`: http://codespeak.net/py 
-.. _`PyPy/LLVM backend`: translation.html#llvm 
-.. _`low level virtual machine`: http://llvm.org/
-.. _`how to install LLVM`: http://llvm.org/docs/GettingStarted.html
-.. _`LLVM mailing list`: http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
-.. _`LLVM version 1.9 installed`: http://llvm.org/releases
 
 .. _`Spidermonkey`: http://www.mozilla.org/js/spidermonkey/
 .. _`Google summer of code`: http://code.google.com/soc

Modified: pypy/trunk/pypy/doc/translation-aspects.txt
==============================================================================
--- pypy/trunk/pypy/doc/translation-aspects.txt	(original)
+++ pypy/trunk/pypy/doc/translation-aspects.txt	Fri Apr 17 12:05:45 2009
@@ -158,8 +158,8 @@
 whole analysis toolchain also assumes that memory management is being taken
 care of -- only the backends have to concern themselves with that issue. For
 backends that target environments that have their own garbage collector, like
-Smalltalk or Javascript, this is not an issue. For other targets like C and
-LLVM the backend has to produce code that uses some sort of garbage collection.
+Smalltalk or Javascript, this is not an issue. For other targets like C
+the backend has to produce code that uses some sort of garbage collection.
 
 This approach has several advantages. It makes it possible to target different
 platforms, with and without integrated garbage collection. Furthermore, the