🚀 go-pugleaf

In article <BtnI48.D9I@twwells.com> bill@twwells.com (T. William Wells) writes:
>The problem is then what to do with statements like a; and a=b;
>when a is a volatile object. The first expression accesses a but
>then discards the value, which is fine.

What constitutes an access is implementation-defined.  A legal but ugly
definition could allow STORING the value of a (redundantly) when the value
is known from some other recent access.

>The other does NOT do what you'd expect, though.

Who's "you"?  I'd read the implementation's definition in order to see what
to expect.  If I don't like it, I wouldn't buy it.  If I do like it, but
the actual behavior doesn't match the documentation, I'd demand a refund.

>The reason is that the assignment has a
>value which is the value of a after the assignment, which can only
>be obtained by accessing a. Thus a=b results in a sequence like:
>       load b
>       store a
>       load a
>rather than the intended load and store.

Legal, but (in my personal opinion) ugly.  What does the documentation say?
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring.  That was probably it.  Very bad."