Re: Memory access vs variable access
On Jun 25, 12:53 am, Jerry Coffin <jcof...@taeus.com> wrote:
In article <1om696gj5nba5$....@gelists.gmail.com>, geli...@gmail.com
says...
[ ... ]
What I find a bit disconcerting is that it seems so
difficult to find out whether a given hardware actually does
this. Reality seems to confirm that it actually is "most"
(or otherwise "most" programs would probably crash a lot
more than they do), but I haven't found any documentation
about any specific guarantees of specific compilers on
specific platforms. (I'm mainly interested in VC++ and gcc.)
Does somebody have any pointers for me?
It depends mostly on the hardware architecture, not the
compiler. The compiler will generate byte, half-word, etc. load
and store machine instructions (assuming they exist, of course);
the problem is what the hardware does with them.
For Sparc architecture, see
http://www.sparc.org/specificationsDocuments.html. I presume
that other architecture providers (e.g. Intel, AMD, etc.) have
similar pages.
[...]
Also keep in mind that most modern computers use caching. In a
typical case, any read from or write to main memory happens an
entire cache line at a time. Bookkeeping is also done on the
basis of entire cache lines, so the processor doesn't care how
many bits in a cache line have been modified -- from its
viewpoint, the cache line as a whole is either modified or
not. If, for example, another processor attempts to read
memory that falls in that cache line, the entire line is
written to memory before the other processor can read it. Even
if the two are entirely disjoint, if they fall in the same
cache line, the processor treats them as a unit.
That's true to a point. Most modern architectures also ensure
cache coherence at the hardware level: if one thread writes to
the first byte in a cache line, and a different thread (on a
different core) writes to the second byte, the hardware will
ensure that both writes eventually end up in main memory; that
the write back of the cache line from one core won't overwrite
the changes made by the other core.
This issue was discussed in detail by the committee; in the end,
it was decided that given something like:
struct S { char a; char b; } ;
or
char a[2] ;
one thread could modify S::a or a[0], and the other S::b or
a[1], without any explicit synchronization, and the compiler had
to make it work. This was accepted because in fact, just
emitting store byte instructions is sufficient for all of the
current architectures.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34