Re: Help with Atomic_Components and whole array assignment

["Mark Lundquist" <mark@rational.com>]

Robert Dewar <robert_dewar@my-deja.com> wrote in message
news:94hn5p$on4$1@nnrp1.deja.com...
> 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'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.

Ah, I didn't mean for the loop... but unfortunately, it's the loop that's
relevant :-(.  What I just meant for the assignment statement itself.  That
is, you'd expect a byte-addressable machine to generate a byte-wide access
for an assignment of a byte-wide type, not, for instance, a 32-bit read,
mask, logical or, then 32-bit write -- and I was saying that although you
can't otherwise assume that behavior, the atomicity rules would enforce it
(which you shot down in flames below :-).  But anyway, I missed the forest
for the trees at that point -- of course the compiler *can* say, "oh, he's
initializing this array... I know a better way".

Now then... if you pull out the byte write into its own procedure, then as
long as you know the compiler doesn't do any automatic inlining before it
tries to optimize the loop(and it doesn't do global optimization)...

Hah!  I just said that to get to you... and it worked, didn't it?  Eh?...
:-) :-)

Yeah, I know, if I have to say "as long as you know the compiler X" then
it's wrong.

Reminds me of the old Benny Hill episode... "Never ASSUME!  It makes an ASS
out of U and ME!"

>
> > 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.

Phooey... you're right.

>
> > > Personally; this seems to be a recurrent embedded systems
> > > proble (that
> > > is either agonized over or [in]conveniently swept under the
> > > carpet).
>

[note,  someone else said this -- it was just part of the post I was
replying to...]

> 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).
>
> > > It would be nice if it were addressed at the next language
> > > revision.
>
> [...]
> I suppose we could add
>
>    pragma Full_Memory_Access (type);
>
> but at most we could only have implementation advice that this
> meant that every read or write must be done with a single
> instruction that affects those bits and nothing else (this
> basically would be a stronger and weaker condition than atomic,
> stronger, because it forbids, e.g., combing writes, or reading
> more than is needed, weaker, because at the bus level, there is
> no requirement for invidisibility.

Well, yeah, I think that is the idea! :-)

>
> But we could only make this implementation advice, since there
> is really no clear way at the semantic level to talk about
> generated instructions

Don't volatility/atomicity kind of suffer from this in general?  And why
couldn't you go stronger than implementation advice, and say the
implementation is required to do X on platforms where X is meaningful?

>  (consider for example that such a rule
> is completely meaningless when you are running in a JVM
> environment).

Sorry, I don't really know anything about the JVM so this example doesn't
mean anything to me...  So if you feel like elaborating, I'm interested,
otherwise no need...

Best,
-- mark