Re: Help with Atomic_Components and whole array assignment

[Robert Dewar <robert_dewar@my-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.

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

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

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.

At most addressing this would involve adding a note that points
out that the only way to ensure specific sequences of machine
instructions being generated is to write the specific sequence
that you want as a machine language insert.

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.

But we could only make this implementation advice, since there
is really no clear way at the semantic level to talk about
generated instructions (consider for example that such a rule
is completely meaningless when you are running in a JVM
environment).


>
> I agree, it would be very nice not to have to work around
this.
>
> Here's another embedded systems issue I'd like to see taken
up: I'd
> like to see bit order fixed, i.e. the ability to write
endian-
> independent record representation clauses.
>
> ---------------
> Mark Lundquist
> Rational Software
>
> Sent via Deja.com
> http://www.deja.com/
>


Sent via Deja.com
http://www.deja.com/