title: Can modern x86 hardware not store a single byte to memory?
body: <p>Speaking of the memory model of C++ for concurrency, Stroustrup's <em>C++ Programming Language,</em> 4th ed., sect. 41.2.1, says:</p>
  
  <blockquote>
    <p>... (like most modern hardware) the machine could not load or store anything smaller than a word.</p>
  </blockquote>
  
  <p>However, my x86 processor, a few years old, can and does store objects smaller than a word.  For example:</p>
  
  <pre><code>#include &lt;iostream&gt;
  int main()
  {
      char a =  5;
      char b = 25;
      a = b;
      std::cout &lt;&lt; int(a) &lt;&lt; "\n";
      return 0;
  }
  </code></pre>
  
  <p>Without optimization, GCC compiles this as:</p>
  
  <pre><code>        [...]
          movb    $5, -1(%rbp)   # a =  5, one byte
          movb    $25, -2(%rbp)  # b = 25, one byte
          movzbl  -2(%rbp), %eax # load b, one byte, not extending the sign
          movb    %al, -1(%rbp)  # a =  b, one byte
          [...]
  </code></pre>
  
  <p>The comments are by me but the assembly is by GCC. It runs fine, of course.</p>
  
  <p>Obviously, I do not understand what Stroustrup is talking about when he explains that hardware can load and store nothing smaller than a word. As far as I can tell, my program does nothing <em>but</em> load and store objects smaller than a word.</p>
  
  <p>The thoroughgoing focus of C++ on zero-cost, hardware-friendly abstractions sets C++ apart from other programming languages that are easier to master. Therefore, if Stroustrup has an interesting mental model of signals on a bus, or has something else of this kind, then I would like to understand Stroustrup's model.</p>
  
  <p>What <em>is</em> Stroustrup talking about, please?</p>
  
  <p><strong>LONGER QUOTE WITH CONTEXT</strong></p>
  
  <p>Here is Stroustrup's quote in fuller context:</p>
  
  <blockquote>
    <p>Consider what might happen if a linker allocated [variables of <code>char</code> type like] <code>c</code> and <code>b</code> in the same word in memory and (like most modern hardware) the machine could not load or store anything smaller than a word.... Without a well-defined and reasonable memory model, thread 1 might read the word containing <code>b</code> and <code>c</code>, change <code>c</code>, and write the word back into memory. At the same time, thread 2 could do the same with <code>b</code>. Then, whichever thread managed to read the word first and whichever thread managed to write its result back into memory last would determine the result....</p>
  </blockquote>
  
  <p><strong>ADDITIONAL REMARKS</strong></p>
  
  <p>I do not believe that Stroustrup is talking about cache lines. Even if he were, as far as I know, cache coherency protocols would transparently handle that problem except maybe during hardware I/O.</p>
  
  <p>I have checked my processor's hardware datasheet. Electrically, my processor (an Intel Ivy Bridge) seems to address DDR3L memory by some sort of 16-bit multiplexing scheme, so I don't know what that's about. It is not clear to me that that has much to do with Stroustrup's point, though.</p>
  
  <p>Stroustrup is a smart man and an eminent scientist, so I do not doubt that he is taking about something sensible. I am confused.</p>
  
  <p>See also <a href="https://stackoverflow.com/q/19903338/1275653">this question.</a> My question resembles the linked question in several ways, and the answers to the linked question are also helpful here. However, my question goes also to the hardware/bus model that motivates C++ to be the way it is and that causes Stroustrup to write what he writes. I do not seek an answer merely regarding that which the C++ standard formally guarantees, but also wish to understand why the C++ standard would guarantee it. What is the underlying thought? This is part of my question, too.</p>