Rename the Emscripten Browers Env. To Emscripten Runtime env. Put memory model doc into that doc. Update links to typed arrays mode 2 to point to the same place

site/source/docs/api_reference/preamble.js.rst

@@ -312,10 +312,10 @@ Stack trace
 
 
 
-Type accessors for Typed Arrays Mode 2
-==========================================
+Type accessors for the memory model
+===================================
 
-When using :ref:`typed-arrays-mode-2` a typed array buffer (``ArrayBuffer``) is used to represent memory, with different views into it giving access to the different types. The views for accessing different types of memory are listed below.
+The :ref:`emscripten-memory-model` uses a typed array buffer (``ArrayBuffer``) to represent memory, with different views into it giving access to the different types. The views for accessing different types of memory are listed below.
 
 
 .. js:data:: HEAP8

site/source/docs/compiling/Code-Generation-Modes.rst

@@ -1,35 +0,0 @@
-.. _emscripten-runtime-environment:
-
-===================================================
-Emscripten Runtime Environment (under-construction)
-===================================================
-
-
-
-.. _Code-Generation-Modes:
-
-.. _typed-arrays:
-
-.. _emscripten-memory-model:
-
-
-Emscripten Memory Model
-=======================
-
-Emscripten's memory model is known as :term:`Typed Arrays Mode 2`. It represents memory using a single `typed array <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays>`_, with different *views* providing access to different types (:js:data:`HEAPU32` for 32-bit unsigned integers, etc.)  
-
-.. _typed-arrays-mode-2:
-
-.. note:: *Typed Arrays Mode 2* is the *only* memory model supported by the :ref:`Fastcomp <LLVM-Backend>` compiler, and it is the *default* memory model for the :ref:`old compiler <original-compiler-core>`. 
-
-	Compared to other models tried by the project, it can be used for a broad range of arbitrary compiled code, and is relatively fast.  
-
-The model lays out items in memory in the same way as with normal C and C++, and as a result it uses the same amount of memory. 
-
-We currently align the stack to 4-byte boundaries (this means that reading 8-byte values is slower as they must be read in two parts and then combined).
-
-This model allows you to use code that violates the load-store consistency assumption. Since the different views show the same data, you can (say) write a 32-bit integer, then read a byte from the middle, and it will work just like in C or C++.
-
-
-.. note:: ``SAFE_HEAP`` ignores load-store consistency violations, since they don't matter. Alignment of reads and writes will be checked, which is important since reading unaligned values can fail.
-

site/source/docs/porting/Emscripten-browser-environment.rst

@@ -1,9 +1,10 @@
 .. _Emscripten-browser-environment:
 
+.. _emscripten-runtime-environment:
+
 ============================================
-Emscripten browser environment (wiki-import)
+Emscripten Runtime Environment (wiki-import)
 ============================================
-.. note:: This article was migrated from the wiki (Fri, 25 Jul 2014 04:21) and is now the "master copy" (the version in the wiki will be deleted). It may not be a perfect rendering of the original but we hope to fix that soon!
 
 The browser environment is different than the environment a normal C/C++ application expects. The main differences are how input and output work, and the fact that the main loop must be asynchronous.
 
@@ -65,3 +66,24 @@ Notes
 
 - ``SDL_QUIT`` is tricky to implement in browsers. The current Emscripten implementation of it will work if you use :c:func:`emscripten_set_main_loop`: As the page is shut, it will force a final direct call to the main loop, giving it a chance to notice the ``SDL_QUIT`` event. So if you do not use a main loop, you will not notice it - your app will close before your next event handling. Note also that there are limitations on what you can do as the page shuts (in onunload), some actions like showing alerts are banned by browsers.
 
+
+.. _emscripten-memory-model:
+
+Emscripten memory model
+=======================
+
+Emscripten's memory model is known as :term:`Typed Arrays Mode 2`. It represents memory using a single `typed array <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays>`_, with different *views* providing access to different types (:js:data:`HEAPU32` for 32-bit unsigned integers, etc.)  
+
+.. note:: *Typed Arrays Mode 2* is the *only* memory model supported by the :ref:`Fastcomp <LLVM-Backend>` compiler, and it is the *default* memory model for the :ref:`old compiler <original-compiler-core>`. 
+
+	Compared to other models tried by the project, it can be used for a broad range of arbitrary compiled code, and is relatively fast.  
+
+The model lays out items in memory in the same way as with normal C and C++, and as a result it uses the same amount of memory. 
+
+We currently align the stack to 4-byte boundaries (this means that reading 8-byte values is slower as they must be read in two parts and then combined).
+
+This model allows you to use code that violates the load-store consistency assumption. Since the different views show the same data, you can (say) write a 32-bit integer, then read a byte from the middle, and it will work just like in C or C++.
+
+
+.. note:: ``SAFE_HEAP`` ignores load-store consistency violations, since they don't matter. Alignment of reads and writes will be checked, which is important since reading unaligned values can fail.
+

site/source/docs/porting/index.rst

@@ -11,7 +11,6 @@ The topics in this section cover the main integration points that you need to co
    
 	guidelines/index
 	Emscripten-browser-environment
-	../compiling/Code-Generation-Modes
 	connecting_cpp_and_javascript/index
 	files/index
 	multimedia_and_graphics/index	

site/source/docs/tools_reference/emcc.rst

@@ -120,13 +120,7 @@ Options that are modified or new in *emcc* are listed below:
 	
 	.. note:: This is only relevant when :term:`minifying` global names, which happens in ``-O2`` and above, and when no ``-g`` option was specified to prevent minification.
 	
-``--typed-arrays <mode>``
-	Set the :ref:`typed array mode <typed-arrays>`. Possible values are:
-	 
-		- ``0``: No typed arrays.
-		- ``1``: Parallel typed arrays.
-		- ``2``: Shared (C-like) typed arrays (default).
-		
+	
 ``--js-opts <level>``
 	Enables JavaScript optimizations. Possible ``level`` values are: