[Lang] Revisit memory model

specs/language/introduction.tex

@@ -273,21 +273,82 @@
 
 \Sec{\acrshort{hlsl} Memory Models}{Intro.Memory}
 
-\p Memory accesses for \gls{sm} 5.0 and earlier operate on 128-bit slots aligned
-on 128-bit boundaries. This optimized for the common case in early shaders where
-data being processed on the GPU was usually 4-element vectors of 32-bit data
-types.
-
-\p On modern hardware memory access restrictions are loosened, and reads of
-32-bit multiples are supported starting with \gls{sm} 5.1 and reads of 16-bit
-multiples are supported with \gls{sm} 6.0. \gls{sm} features are fully
-documented in the \gls{dx} Specifications, and this document will not attempt to
-elaborate further.
+\p The fundamental storage unit in HLSL is a \textit{byte}, which is comprised
+of 8 \textit{bits}. Each \textit{bit} stores a single value 0 or 1. Each byte
+has a unique \textit{address}.
+
+\p A \textit{memory location} is a range of bytes which can be identified by an
+address and a length. A memory location represents either a scalar object, or a
+sequence of adjacent bit-fields of non-zero size.
+
+\p Each read or write to a memory location is called a \textit{memory access}.
+Operations that perform memory accesses are called \textit{memory operations}. A
+memory operation may operate on one or more memory locations. A memory operation
+must not alter memory at a location not contained in the set of memory locations
+it is operating on.
+
+\begin{note}
+  The memory location of a bit-field may include adjacent bit-fields. For
+  example given the following declaration:
+
+  \begin{HLSL}
+    struct ContainingBitfields {
+      uint A : 4;
+      uint B : 4;
+      uint : 0;
+      uint D : 4;
+    }
+  \end{HLSL}
+
+  Members \texttt{A}, and \texttt{B} have the same memory locations comprised of
+  4 bytes beginning at the start of the structure. The zero-sized anonymous
+  bit-field member causes a break in bit-field packing, so member \texttt{D}
+  occupies the next set of memory locations beginning at the 5th byte of the
+  structure and continuing for 4 bytes. For more description of bit-fields see
+  \ref{Classes.BitFields}.
+\end{note}
+
+\p Padding bytes inside a structure are included in the memory location of the
+structure, but are not included in the memory locations of the members inside
+the structure. This means that element-wise operations like default copy
+operations do not copy padding bytes. Because structure padding is
+implementation defined, and reading or writing padding bytes is undefined
+behavior, an implementation may generate writes that overwrite padding bytes.
+
+\p Reading from uninitialized memory is undefined. Writing uninitialized values
+to memory is undefined.
+
+\p Two sets of memory locations, \texttt{A} and \texttt{B}, are said to
+\textit{overlap} each other if some memory location in \texttt{A} is also in
+\texttt{B} (\(A \cap B \neq \emptyset\)).
 
 \Sub{Memory Spaces}{Intro.Memory.Spaces}
 
 \p \acrshort{hlsl} programs manipulate data stored in four distinct memory
-spaces: thread, threadgroup, device and constant.
+spaces: thread, threadgroup, device and constant. Memory spaces are logical
+abstractions over physical memory. Each memory space has a defined \textit{line
+width}, which specifies the minimum readable and writable size, and a
+\textit{minimum alignment}, which defines the smallest addressable increment of
+the memory space. The two values need not be the same, although they may be.
+
+\begin{note}
+  \p Memory accesses for many resource types in \gls{dx} operate on 128-bit
+  slots aligned on 128-bit boundaries. In the terms of this specification it
+  would be said that those memory spaces have a 128-bit \textit{line width},
+  and a 128-bit \textit{minimum alignment}.
+\end{note}
+
+\p Each address has an associated memory space. Two addresses with the same
+value but different memory spaces are considered different unique addresses.
+
+\p A memory location in any memory space may overlap with another memory
+location in the same space. A memory location in thread or threadgroup memory
+may not overlap with memory locations in any other memory spaces\footnote{The
+physical memory regions for thread and threadgroup memory are required to be
+distinct and non-overlapping with any other memory space.}. It is implementation
+defined if memory locations in other memory spaces overlap with memory locations
+in different spaces\footnote{An implementation may define device, constant or
+additional extended memory spaces to share logical address ranges.}.
 
 \SubSub{Thread Memory}{Intro.Memory.Spaces.Thread}
 

specs/language/placeholders.tex

@@ -7,6 +7,7 @@
 \Ch{Classes}{Classes}
 \Sec{Static Members}{Classes.Static}
 \Sec{Conversions}{Classes.Conversions}
+\Sec{Bit-fields}{Classes.BitFields}
 \Ch{Templates}{Template}
 \Sec{Template Instantiation}{Template.Inst}
 \Sec{Partial Ordering of Function Templates}{Template.Func.Order}