AR: Clarify message register uses.

data* registers may be MRs, instead of are definitely MRs. This lets us
say that if aampostincrement is implemented then they must not be MRs.

Also rewrote the definition to be more clear.

debug_module.tex

@@ -314,16 +314,28 @@ \section{Halt Groups, Resume Groups, and External Triggers} \label{hrgroups}
 \section{Message Registers}
 \label{sec:mr}
 
-Message Registers (MRs) are registers that are only used in a limited way,
-allowing for different implementations. They exist to let two sides communicate
-when the two sides already know who is the sender and who is the receiver.
-
-An MR implements read and write operations on two sides.  When one side reads an
-MR, and the last write was by the other side, then the result value of the read
-is the value last written by the other side.  When one side reads an MR, and the
-last write was by that same side, then the result value of the read is
-\unspecified.  Thus the MR can be used to exchange data with the other side, but
-not as storage to be accessed later.
+Message Registers (MRs) are registers that implement fewer features than a
+traditional register. They support just enough features to pass messages back
+and forth.
+
+Only registers whose description explicitly says they may be MRs may be
+implemented as MRs instead of traditional registers. \RdmDataZero through
+\RdmDataEleven may be MRs, used to let the debugger pass arguments to abstract
+commands, and let the DM pass results from abstract commands back.
+
+A traditional dual-ported register contains a single value, which can be
+read/written through both ports. A MR has two ports: PortA and PortB. It
+contains two values: ValueA and ValueB. Only one of these values has defined
+contents at any one time.
+
+\begin{steps}{For an MR:}
+    \item A write to PortA updates ValueA with the written value, and makes
+        ValueB \unspecified.
+    \item A write to PortB updates ValueB with the written value, and makes
+        ValueA \unspecified.
+    \item A read from PortA returns ValueB.
+    \item A read from PortB returns ValueA.
+\end{steps}
 
 \begin{commentary}
     A regular register can be used to implement an MR. In some FPGAs it is

xml/abstract_commands.xml

@@ -258,6 +258,10 @@
             {\tt arg1} (which contains the address used) by the number of bytes
             encoded in \FacAccessmemoryAamsize.
 
+            Implementations that allow this bit to be 1 must implement the
+            relevant {\tt data} registers as traditional registers instead of
+            MRs.
+
             Supporting this variant is optional, but highly recommended for
             performance reasons.
         </field>

xml/dm_registers.xml

@@ -394,9 +394,8 @@
             If \FdmHartinfoDataaccess is 1: Number of 32-bit words in the memory map
             dedicated to shadowing the {\tt data} registers.
 
-            If this value is non-zero, then the {tt data} registers must go
-            beyond being MRs and guarantee they each store a single value, that is
-            readable/writable by either side.
+            If this value is non-zero, then the {tt data} registers must be
+            traditional registers and not MRs.
 
             Since there are at most 12 {\tt data} registers, the value in this
             register must be 12 or smaller.
@@ -641,19 +640,19 @@
     </register>
 
     <register name="Abstract Data 0" short="data0" address="0x04">
-        \RdmDataZero through \RdmDataEleven are Message Registers, whose
-        behavior is described in Section~\ref{sec:mr}, that may
+        \RdmDataZero through \RdmDataEleven may be Message Registers, whose
+        behavior is described in Section~\ref{sec:mr}. These registers may
         be read or changed by abstract commands. \FdmAbstractcsDatacount indicates how many
         of them are implemented, starting at \RdmDataZero, counting up.
         Table~\ref{tab:datareg} shows how abstract commands use these
-        MRs.
+        registers.
 
-        Accessing these MRs while an abstract command is executing causes
+        Accessing these registers while an abstract command is executing causes
         \FdmAbstractcsCmderr to be set to 1 (busy) if it is 0.
 
         Attempts to write them while \FdmAbstractcsBusy is set does not change their value.
 
-        The values in these MRs might not be preserved after an abstract
+        The values in these registers might not be preserved after an abstract
         command is executed. The only guarantees on their contents are the ones
         offered by the command in question. If the command fails, no
         assumptions can be made about the contents of these registers.