Fix the WebAssembly page size at 64KiB.

3 files changed, 13 insertions, 19 deletions

diff --git a/AstSemantics.md b/AstSemantics.md
index 1d91acc..a407c36 100644
--- a/AstSemantics.md
+++ b/AstSemantics.md
@@ -194,12 +194,11 @@ Out of bounds accesses trap.
 ### Resizing
 
 In the MVP, linear memory can be resized by a `grow_memory` operator. This
-operator requires its operand to be a multiple of the system
-page size. To determine page size, a nullary `page_size` operator is provided.
+operator requires its operand to be a multiple of the WebAssembly page size,
+which is 64KiB on all engines.
 
  * `grow_memory` : grow linear memory by a given unsigned delta which
-    must be a multiple of `page_size`
- * `page_size` : nullary constant function returning page size in bytes
+    must be a multiple of 64KiB.
 
 As stated [above](AstSemantics.md#linear-memory), linear memory is contiguous,
 meaning there are no "holes" in the linear address space. After the
@@ -212,13 +211,6 @@ operator may be added. However, due to normal fragmentation, applications are
 instead expected release unused physical pages from the working set using the
 [`discard`](FutureFeatures.md#finer-grained-control-over-memory) future feature.
 
-The result type of `page_size` is `int32` for wasm32 and `int64` for wasm64.
-The result value of `page_size` is an unsigned integer which is a power of 2.
-
-The `page_size` value need not reflect the actual internal page size of the
-implementation; it just needs to be a value suitable for use with
-`grow_memory`.
-
 ## Local variables
 
 Each function has a fixed, pre-declared number of local variables which occupy a single
diff --git a/Nondeterminism.md b/Nondeterminism.md
index 8ab60d0..3a1efee 100644
--- a/Nondeterminism.md
+++ b/Nondeterminism.md
@@ -30,10 +30,6 @@ currently admits nondeterminism:
    shared memory, nondeterminism will be visible through the global sequence of
    API calls. With shared memory, the result of load operators is
    nondeterministic.
- * The value returned by `page_size` is system-dependent. The arguments to the
-   [`grow_memory`](AstSemantics.md#resizing) and other 
-   [future memory management operators](FutureFeatures.md#finer-grained-control-over-memory)
-   are required to be multiples of `page_size`.
  * NaN bit patterns in floating point
    [operators](AstSemantics.md#floating-point-operators) and
    [conversions](AstSemantics.md#datatype-conversions-truncations-reinterpretations-promotions-and-demotions)
diff --git a/Rationale.md b/Rationale.md
index 602f5bd..744c95b 100644
--- a/Rationale.md
+++ b/Rationale.md
@@ -106,10 +106,16 @@ tradeoffs.
 
 ## Resizing
 
-Implementations provide a `page_size` operator which allows them to efficiently
-map the underlying OS's capabilities to the WebAssembly application, as well as
-to communicate their own implementation details in a useful manner to the
-developer.
+To allow efficient virtual-memory based techniques for bounds checking, memory
+sizes are required to be page-aligned.
+For portability across a range of CPU architectures and operating systems,
+WebAssembly defines a fixed page size.
+Programs can depend on this fixed page size and still remain portable across all
+WebAssembly engines which employ efficient virtual memory techniques for bounds\
+checking.
+64KiB represents the least common multiple of many platforms and CPUs.
+In the future, WebAssembly may offer the ability to use larger page sizes on
+some platforms for increased TLB efficiency.
 
 
 ## Linear memory disabled if no linear memory section