update conversation

diff --git a/3d_gpu/microarchitecture.mdwn b/3d_gpu/microarchitecture.mdwn
index e7da4e7f728ff7e3825b70d80aaffd4c69223bd6..c69ec48e73edb661527f467c409e7ffc71ff42a0 100644 (file)
--- a/3d_gpu/microarchitecture.mdwn
+++ b/3d_gpu/microarchitecture.mdwn
@@ -368,34 +368,34 @@ and there are several of them:
   - most recent STOREs prevent later LOADs.
 * one for Function-Unit to Function-Unit.
   - it expresses both RAW and WAW hazards through "Go_Write"
-     and "Go_Read" signals, which are stopped from proceeding by
-     dependent 1-bit CAM latches
+    and "Go_Read" signals, which are stopped from proceeding by
+    dependent 1-bit CAM latches
   - exceptions may ALSO be made "precise" by holding a "Write prevention"
-     signal.  only when the Function Unit knows that an exception is
-     not going to occur (memory has been fetched, for example), does
-     it release the signal
+    signal.  only when the Function Unit knows that an exception is
+    not going to occur (memory has been fetched, for example), does
+    it release the signal
   - speculative branch execution likewise may hold a "Write prevention",
-       however it also needs a "Go die" signal, to clear out the
-       incorrectly-taken branch.
+    however it also needs a "Go die" signal, to clear out the
+    incorrectly-taken branch.
   - LOADs/STOREs *also* must be considered as "Functional Units" and thus
-       must also have corresponding entries (plural) in the FU-to-FU Matrix
+    must also have corresponding entries (plural) in the FU-to-FU Matrix
   - it is permitted for ALUs to *BEGIN* execution (read operands are
-       valid) without being permitted to *COMMIT*.  thus, each FU must
-       store (buffer) results, until such time as a "commit" signal is
-       received
+    valid) without being permitted to *COMMIT*.  thus, each FU must
+    store (buffer) results, until such time as a "commit" signal is
+    received
   - we may need to express an inter-dependence on the instruction order
-       (raising the WAW hazard line to do so) as a way to preserve execution
-       order.  only the oldest instructions will have this flag dropped,
-       permitting execution that has *begun* to also reach "commit" phase.
+    (raising the WAW hazard line to do so) as a way to preserve execution
+    order.  only the oldest instructions will have this flag dropped,
+    permitting execution that has *begun* to also reach "commit" phase.
 * one for Function-Unit to Registers.
   - it expresses the read and write requirements: the source
-      and destination registers on which the operation depends.  source
-      registers are marked "need read", dest registers marked
-      "need write".
+    and destination registers on which the operation depends.  source
+    registers are marked "need read", dest registers marked
+    "need write".
   - by having *more than one* Functional Unit matrix row per ALU
-      it becomes possible to effectively achieve "Reservation Stations"
-      orthogonality with the Tomasulo Algorithm.  the FU row must, like
-      RS's, take and store a copy of the src register values.
+    it becomes possible to effectively achieve "Reservation Stations"
+    orthogonality with the Tomasulo Algorithm.  the FU row must, like
+    RS's, take and store a copy of the src register values.
 
 ## Register Renaming
 
@@ -460,7 +460,7 @@ on the destination   register number
 * the Register Read and Write signals are then "striped" such that
   read/write requests for every 2nd (or 4th) register are "grouped" and
   will have to fight for access to a multiplexer in order to access
-  registers that do not   have the same modulo 2 (or 4) match.
+  registers that do not have the same modulo 2 (or 4) match.
 * we MAY potentially be able to drop the destination (write) multiplexer(s)
   by only permitting FU rows with the same modulo to write to that
   destination bank.  FUs with indices 0,4,8,12 may only write to registers