Handling Addressing Errors

Handling Addressing Errors

[Charles H. Sampson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]

     Is there a standard way to detect an addressing error, specifi-
cally, addressing a location that does not exist?

     Here is a piece of Ada 83 code that was determining dynamically if 
a slave board was present in a VME embedded system:

-----

     function CHECK_FOR_BOARD (BOARD_ADDR : in SYSTEM.ADDRESS)
      return BOOLEAN is

      BOARD_LOCATION : INTEGER;
       for BOARD_LOCATION use at BOARD_ADDR;
      BOGUS          : INTEGER;

     begin
       BOGUS := BOARD_LOCATION;
       return TRUE;

     exception
       when PROGRAM_ERROR =>
         return FALSE;    
     
     end CHECK_FOR_BOARD; 

-----

     This code worked for a particular version of a particular com-
piler, but I see a couple of problems.  The first is that, as well as I 
can tell, this is a non-standard raising of Program_error; I�ve gone 
through all references to Program_error in LRM 83 and LRM 95 and I ha-
ven�t seen this issue addressed in either.  The second is, what prevents 
an optimizing compiler from deciding that the assignment statement is 
unnecessary (BOGUS is never referenced after being set) so that it 
doesn�t need to access BOARD_LOCATION?

     As I�ve 95�ed this code I added a pragma VOLATILE (BOARD_LOCATION), 
but the definition of that pragma says that "all reads and updates of 
the object as a whole are performed direct to memory."  I think it could 
be argued that this means "all reads and updates that are necessary ..." 
and, since it's not necessary to read BOARD_LOCATION at all, the memory 
read could still be optimized away.

     I know that I can probably solve the optimization problem by put-
ting BOGUS outside of the function or even sending BOARD_LOCATION to a 
null procedure located in another package.  That should take care of all 
but the most hyper-aggressive optimizers, but it's a lot of baggage.  
I'd prefer to do something more straightforward.

				Charlie
--
******

     For an email response, my user name is "sampson" and my host
is "spawar.navy.mil".

Re: Handling Addressing Errors

[robert_dewar]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]

In article <1999Mar3.212443.1898@nosc.mil>,
  claveman@cod.nosc.mil (Charles H. Sampson) wrote:
> This code worked for a particular version of a particular
> compiler, but I see a couple of problems.  The first is
> that, as well as I can tell, this is a non-standard
> raising of Program_error;

Absolutely, this is quite non-standard. Obviously your
program is erroneous and anything could happen if the
address is invalid.

The proper solution is to write a separate target dependent
unit (in an appropriate language) that determines if an
address is valid.


> The second is, what prevents an optimizing compiler from
> deciding that the assignment statement is unnecessary
> (BOGUS is never referenced after being set) so that it
> doesn�t need to access BOARD_LOCATION?

Common sense and reasonable behavior!

Any compiler that does not use an address clause to trigger
an implicit volatility is poorly designed in my view. Of
course it does not harm to put in a specific pragma
Volatile, and that will most certainly solve this problem

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Handling Addressing Errors

[Charles H. Sampson]

In article <7bm0v3$933$1@nnrp1.dejanews.com>,
 <robert_dewar@my-dejanews.com> wrote:
>In article <1999Mar3.212443.1898@nosc.mil>,
>  claveman@cod.nosc.mil (me) wrote:
>
>>            ... what prevents an optimizing compiler from
>> deciding that the assignment statement is unnecessary
>> (BOGUS is never referenced after being set) so that it
>> doesn't need to access BOARD_LOCATION?
>
>Common sense and reasonable behavior!

     In short, there's not much hope.  :-)

     Seriously, while it's hard to argue against common sense and rea-
sonable behavior, I wish the LRM had explicitly said what should happen.

>Any compiler that does not use an address clause to trigger
>an implicit volatility is poorly designed in my view. Of
>course it does not harm to put in a specific pragma
>Volatile, and that will most certainly solve this problem

     Fair enough that an address clause should implicitly trigger vola-
tility, but that's not quite the issue.  Suppose the address clause had 
caused an overlay of two objects (rather than creating an access to a 
slave board location, as in my original example).  Then any reasonable 
compiler--any correct compiler--must access memory any time the value of 
one of the objects is needed, to prevent using a stale value held else-
where.  But in my example, dead store elimination would determine that 
storing BOGUS is not necessary.  It's only a small jump from that to 
determining that the value of BOARD_VALUE isn't needed, so there's no 
point in fetching it.

     By my reading, even pragma Volatile doesn't help, because C.6(10) 
only says that all reads are performed directly to memory.  It doesn't 
say that the read must be performed even if it is known that the value 
is not used.  I think it's well beyond the LRM to say that a read of a 
volatile object might have some effect in addition to obtaining its 
value and, therefore, all reads must be performed whether the value is 
needed or not.

				Charlie
--
******

     For an email response, my user name is "sampson" and my host
is "spawar.navy.mil".

Re: Handling Addressing Errors

[Tucker Taft]

Charles H. Sampson wrote:
> 
> ... 
>      By my reading, even pragma Volatile doesn't help, because C.6(10)
> only says that all reads are performed directly to memory.  It doesn't
> say that the read must be performed even if it is known that the value
> is not used.  I think it's well beyond the LRM to say that a read of a
> volatile object might have some effect in addition to obtaining its
> value and, therefore, all reads must be performed whether the value is
> needed or not.

Your reading does not conform to the intent of pragma "Volatile."
It is intended to be useful for "active" memory locations, where
a "read" may have a side effect of some sort.  It is also intended
for memory locations where some unknown mechanism is changing the
value.

This is made explicit in RM95 C.6(20) and 1.1.3(13), which indicates
that the "external effect" of a program includes *each*
read and update of a volatile or atomic object.
It is illegal to optimize away an external effect (RM95 1.1.3(15)).

>                                 Charlie

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Handling Addressing Errors

[Mikko Levanto]

Tucker Taft wrote:

> This is made explicit in RM95 C.6(20) and 1.1.3(13), which indicates
> that the "external effect" of a program includes *each*
> read and update of a volatile or atomic object.
> It is illegal to optimize away an external effect (RM95 1.1.3(15)).

Can optimization affect the number of accesses ?
E.g., if A is volatile, does

   A := A + A;

always cause two reads and one write?

-- 
Mikko J. Levanto
mailto:mikko.levanto@vtt.fi

Re: Handling Addressing Errors

[Nick Roberts]

Mikko Levanto wrote in message <36F21863.7D71@iki.fi>...
[...]
|Can optimization affect the number of accesses ?

No.

|E.g., if A is volatile, does
|
|   A := A + A;
|
|always cause two reads and one write?


Yes it does (or else you have a really nasty compiler).

|Mikko J. Levanto
|mailto:mikko.levanto@vtt.fi

-------------------------------------
Nick Roberts
-------------------------------------

Re: Handling Addressing Errors

[Tucker Taft]

Mikko Levanto (mikko.levanto@iki.fi) wrote:
: Tucker Taft wrote:

: > This is made explicit in RM95 C.6(20) and 1.1.3(13), which indicates
: > that the "external effect" of a program includes *each*
: > read and update of a volatile or atomic object.
: > It is illegal to optimize away an external effect (RM95 1.1.3(15)).

: Can optimization affect the number of accesses ?

No.  A correct optimization may not change the number of reads or writes.

: E.g., if A is volatile, does

:    A := A + A;

: always cause two reads and one write?

Yes.  Each read and update is an external effect, and an optimization
may not add or remove required external effects.

An example of an external effect is printing the digit "2".
It would obviously be wrong for an optimization to change output
from "1223" to "123" simply because there were 2 "2"s in a row.
The same applies to reads of a volatile object.

: -- 
: Mikko J. Levanto
: mailto:mikko.levanto@vtt.fi

--
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Handling Addressing Errors

[Charles H. Sampson]

In article <36F17DAC.E80F01DD@averstar.com>,
Tucker Taft  <stt@averstar.com> wrote:
>Charles H. Sampson wrote:
>> 
>> ... 
>>      By my reading, even pragma Volatile doesn't help, because C.6(10)
>> only says that all reads are performed directly to memory.  It doesn't
>> say that the read must be performed even if it is known that the value
>> is not used.  ...
>
>Your reading does not conform to the intent of pragma "Volatile."
>It is intended to be useful for "active" memory locations, where
>a "read" may have a side effect of some sort.  It is also intended
>for memory locations where some unknown mechanism is changing the
>value.
>
>This is made explicit in RM95 C.6(20) and 1.1.3(13), which indicates
>that the "external effect" of a program includes *each*
>read and update of a volatile or atomic object.
>It is illegal to optimize away an external effect (RM95 1.1.3(15)).
>

     Thanks yet again, Tucker.  Those are the kinds of words I was look-
ing for.  That I didn't find them as I "researched" the issue is attrib-
utable to several errors, some of them mine, some not.

     Summarizing this and other responses as they apply to my original 
question, pragma Volatile forces the read of the board, as I had in-
tended.  The address clause alone doesn't, unless you accept the claim 
that all "decent" compilers treat the appearance of an address clause 
for an object as implying that the object is volatile.

				Charlie

P. S.  I know I'm late in following up on this nearly dead thread, but 
my official, government furnished, news reader has been unbelievably 
flaky recently.  Tucker's response, along with six others, only arrived 
yesterday.
--
******

     For an email response, my user name is "sampson" and my host
is "spawar.navy.mil".

Re: Handling Addressing Errors

[Nick Roberts]

I think Charles' query with the RM95 is largely addressed by the AARM, if I
may quote AARM C.6:

16   For a volatile object all reads and updates of the object as a whole
are
performed directly to memory.

        16.a   Implementation Note:  This precludes any use of register
        temporaries, caches, and other similar optimizations for that
object.

and:

20   {external effect [volatile/atomic objects]} The external effect of a
program (see 1.1.3) is defined to include each read and update of a volatile
or atomic object.  The implementation shall not generate any memory reads or
updates of atomic or volatile objects other than those specified by the
program.

        20.a   Discussion:  The presumption is that volatile or atomic
        objects might reside in an ``active'' part of the address space
where
        each read has a potential side-effect, and at the very least might
        deliver a different value.

        20.b   The rule above and the definition of external effect are
        intended to prevent (at least) the following incorrect
optimizations,
        where V is a volatile variable:

         20.c  X:= V; Y:=V; cannot be allowed to be translated as Y:=V;
               X:=V;

         20.d  Deleting redundant loads: X:= V; X:= V; shall read the
               value of V from memory twice.

         20.e  Deleting redundant stores: V:= X; V:= X; shall write into
               V twice.

         20.f  Extra stores: V:= X+Y; should not translate to something
               like V:= X; V:= V+Y;

         20.g  Extra loads: X:= V; Y:= X+Z; X:=X+B; should not translate
               to something like Y:= V+Z; X:= V+B;

         20.h  Reordering of loads from volatile variables: X:= V1; Y:=
               V2; (whether or not V1 = V2) should not translate to Y:=
               V2; X:= V1;

         20.i  Reordering of stores to volatile variables: V1:= X; V2:=
               X; should not translate to V2:=X; V1:= X;

I think the additional notes pretty well settle any doubts Charles may have,
except perhaps that the wording in the RM (rather than just the AARM) might
have been stronger or more explicit.  On the assumption that all compiler
writers will have read and inwardly digested the AARM (as well as the
Rationale, the AI95s, etc.)*, I think Charles can feel reasonably safe.

-------------------------------------
Nick Roberts
-------------------------------------

*e.g. me ;-)

Re: Handling Addressing Errors

[robert_dewar]

In article <7cttko$348$1@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> I think Charles' query with the RM95 is largely addressed
> by the AARM, if I
> may quote AARM C.6:

You may quote the AARM, but please remember that it has
no official status whatsoever, it is simply some informal
comments by the designers and writers of the RM. It may
be useful in some cases to infer intent, but it has no
official normative status. In other words, if the RM is
unclear, and the AARM is clear, then the language
definition is still unclear!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Handling Addressing Errors

[robert_dewar]

In article <1999Mar18.005620.19189@nosc.mil>,
  claveman@fern.com (Charles H. Sampson) wrote:
>
> By my reading, even pragma Volatile doesn't help,
> because C.6(10)
> only says that all reads are performed directly to
> memory.  It doesn't
> say that the read must be performed even if it is known
> that the value
> is not used.  I think it's well beyond the LRM to say
> that a read of a
> volatile object might have some effect in addition to
> obtaining its
> value and, therefore, all reads must be performed whether
> the value is
> needed or not.

No, that is just a wrong reading, and it is NOT worth
arguing the delicate semantics of the wording, since
everyone knows what is intended here. I guess as a low
priority task the ARG could worry about defending the
RM from Charles' obviously incorrect reading, but
changing the language in the RM will not make one tiny
little bit of difference in real life.

THe whole POINT of volatile is to make sure that every
read and write happens from memory. AN optimizer that
eliminates a volatile read or write is broken!

One important rule in reading the RM is that you must not
ignore the unstated very important rule:

  "No other rule in this manual can be used to derive a
   silly conclusion."

Basically what this means is that if you sit down and try
to read the RM in a hostile manner, you may discover cases
in which the wording could be improved, but that does not
mean these are cases where compilers will do the wrong
thing.

For example, it is 100% clear in the original Ada 83
RM that

  subtype x is integer range 1 .. 10;

defines a non-static subtype. But of *course* all compilers
treated this as a static subtype, since that is the obvious
intent.

Similarly the obvious intent of volatile is that it means
that all reads and writes happen and that they happen to
memory (one very important use of volatile is for example
mapping to memory mapped I/O devices and everyone knows
this).

I am not saying all cases are clear cut.

But this one is definitely an example of one that is
indeed clear cut.

In any case, and especially if you do not agree, you should
follow the directions in the RM

59   Informal comments on this International Standard may
be sent via e-mail
to ada-comment@sei.cmu.edu.  If appropriate, the Project
Editor will initiate
a Technical Corrigendum to be issued for the standard.


and let the ARG look at it :-)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Handling Addressing Errors

[Nick Roberts]

Assuming you mean a memory board, the standard technique is something like
this:

   with System.Storage_Elements;
   use System, System.Storage_Elements;

   procedure Check_For_Board (Bottom, Top: in System.Address; Present: out
Boolean);
      Mask: array (1..4) of Storage_Element;
      Board: Storage_Array(0..Top-Bottom);
      for Board'Address use Bottom;
      pragma Volatile_Components(Board);
   begin
      Mask(1) := 0;
      Mask(2) := 16#A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5# and
(2**Storage_Unit-1);
      Mask(3) := not Mask(2);
      Mask(4) := not Mask(1);
      Present := False;
      for i in Board'Range loop
         for m in 1..4 loop
            Board(i) := Mask(m);
            if Board(i) /= Mask(m) then return; end if;
         end loop;
      end loop;
      Present := True;
   exception
       when Program_Error => Present := False; return; -- ?
   end Check_For_Board;

This is designed for all architectures, BTW, not just VME.

I believe some VME boards provide a way to detect their presence (and to
configure them) via I/O ports (usu memory mapped, as it happens), but, as
ever, they're all different!  VME memory boards tug the NMI to indicate
memory failure.  I take it that the RTOS your program ran on caught the NMI
and raised Program_Error.  If you could find a way to intercept the NMI
explicitly, so much the better.  (This might provide you with a more
graceful way to handle genuine memory failures, BTW.)

As for pragma Volatile, if you ever find a compiler which 'optimises' away a
reference to a volatile object, do us all a favour: (a) find the
person/people responsible for this compiler; (b) shoot them all, or commit
them to a secure mental institution; (c) destroy all copies of the compiler,
and any evidence that it ever existed.  (Thanks :-)

-------------------------------------
Nick Roberts
-------------------------------------