Re: Help with Atomic_Components and whole array assignment

[Tucker Taft <stt@averstar.com>]

Robert Dewar wrote:
> 
> In article <94hfaq$h3n$1@nnrp1.deja.com>,
>   mark_lundquist@my-deja.com wrote:
> >    for I in A'range loop
> >       A (I) := 0;
> >    end loop;
> >
> > you'll get 1-byte writes, guaranteed.
> 
> That is not correct.

It seems correct if pragma atomic_components applies to A,
since in that case, each component of A is an atomic object,
and each update to an atomic object has a separate external
effect, per C.6(20).

> > It's hard to imagine a compiler wanting to generate anything
> > but simply a 1-byte write for each element
> 
> It's not hard at all. Converting this loop to a more efficient
> form is a quite reasonable optimization (the Microsoft C
> compiler does this for example, since it is a big win on
> earlier implementations of the ia32 architecture.

True, but such a transformation is not permitted if Atomic_Components
applies.

> > but if it did want to, RM C.6(20) would not allow it
> > (violation of sharing properties of the other components).
> 
> No, it is a perfectly legitimate optimization, and does not
> violate the quoted section, which talks about generating extra
> stores, not about combining store operations.

I don't agree with Robert's reading of this.  It seems very clear
that you cannot combine multiple updates of separate atomic
objects into a single write.  One of the whole points of atomic
is to make each write separate and indivisible.  It was designed
specifically to address issues relating to "active" memory, where
breaking the write down into multiple writes, or combining
multiple writes into a single write, would confuse the device.

> ...
> No, it is not swept under the carpet, it is clear from the
> RM (as has been explained in many threads on the subject), that
> if your application requires specific sequences of instructions
> to be generated, then the ONLY legitimate way of doing this is
> with machine language insertions. To think otherwise is a
> recipe for mysterious and ill-documented implementation
> dependencies (the GNU/Linux kernel suffered from these problems
> early on).

Well, I don't agree completely with these "many comp.lang.ada threads."
Atomic is designed to provide additional control over what
code the compiler generates.  It doesn't specify exactly what
instructions will be used, but it does require that each read/update
be its own indivisible operation, however that is accomplished.
In general, that means each read/update is a separate instruction.
Which particular instruction is not specified, though of course
in most cases it will be a load or a store.  I don't agree with
the advice of slipping into machine code to accomplish all of these
kinds of things, if atomic can do the job.  

I would agree that with the original code, which used an aggregate
assignment, there is no requirement to perform that as separate
byte assignments.  However, if the code is written as a sequence
(or a loop) of separate assignments, and the objects are atomic,
it is a bug (in my view) if the compiler combines these assignments 
into a single assignment.  Similarly, reordering such assignments
would be a bug, since it would change the external effect of the
program in an impermissible way.

> > ---------------
> > Mark Lundquist
> > Rational Software

-- 
-Tucker Taft   stt@avercom.net   http://www.averstar.com/~stt/
Chief Technology Officer, AverCom, Inc. (A Titan Company) Burlington, MA  USA
(AverCom was formed 1/1/01 from the Commercial Division of AverStar)
(http://www.averstar.com/services/ebusiness_applications.html)