11.6

11.6

[Matthew Heaney]

Suppose we have a bounded stack:

  type Stack_Type (Size : Positive) is limited private;

  procedure Push
    (Stack : in out Stack_Type;
     Item  : in Item_Type);

private

  type Stack_Type (Size : Positive) is
    limited record
      Top : Natural := 0;
      Items : Item_Array (1 .. Size);
    end record;

end Stacks;


Now consider an implementation of Push:

  procedure Push
    (Stack : in out Stack_Type;
     Item  : in     Item_Type) is

     subtype Top_Range is Positive range 1 .. Stack.Size;

     Top : Natural renames Stack.Top;
  begin
     Top := Top_Range'(Top + 1);    --???
     Stack.Items (Top) := Item;
  end Push;


Is it possible, because of 11.6 permissions, that the explicit range
check in the marked line can be optimized away?

Another question: if I compile this (or the instantiation?) with checks
off, then will that cause the explicit range check to be omitted?

Re: 11.6

[Mats Weber]

Matthew Heaney wrote:

>   procedure Push
>     (Stack : in out Stack_Type;
>      Item  : in     Item_Type) is
> 
>      subtype Top_Range is Positive range 1 .. Stack.Size;
> 
>      Top : Natural renames Stack.Top;
>   begin
>      Top := Top_Range'(Top + 1);    --???
>      Stack.Items (Top) := Item;
>   end Push;
> 
> Is it possible, because of 11.6 permissions, that the explicit range
> check in the marked line can be optimized away?
> 
> Another question: if I compile this (or the instantiation?) with checks
> off, then will that cause the explicit range check to be omitted?

Yes, it will. As a rule, I never handle Constraint_Error, but use an if
statement instead in places I know overflow could happen, e.g.

   if Top >= Stack.Size then
      raise Overflow;
   end if;
   Top := Top + 1;

Re: 11.6

[Robert Dewar]

In article <38393F42.EE13CEE5@mail.com>,
  Mats Weber <matsw@mail.com> wrote:
> > Another question: if I compile this (or the instantiation?)
> > with checks off, then will that cause the explicit range
> > check to be omitted?

> Yes, it will

That's a misleading response. There is no requirement that
suppressing checks will cause checks to be omitted, that is
not what the pragma requires. in particular, on a machine
where the checks are free (e.g. integer overflow on a MIPS 3000)
then it is entirely reasonable for the compiler to leave in the
checks. The idea of suppress is to get rid of checking code, not
necessarily to get rid of checks.

> As a rule, I never handle Constraint_Error, but use an if
> statement instead in places I know overflow could happen, e.g.
>
>    if Top >= Stack.Size then
>       raise Overflow;
>    end if;
>    Top := Top + 1;

Of course some checks are pretty painful
to test for explicitly. In GNAT we have added the pragma
Unsuppress, precisely so that you can have a region of code
where you KNOW the tests will be turned on, even if they are
turned off at some higher level. FOr example, we expect the
GNAT runtime to be compiled with checks off (-gnatp), but in
some cases (e.g. look in a-calend.adb) we need the check and
we use an explicit pragma Unsuppress.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: 11.6

[Robert A Duff]

"Matthew Heaney" <matthew_heaney@acm.org> writes:

> Suppose we have a bounded stack:
> 
>   type Stack_Type (Size : Positive) is limited private;
> 
>   procedure Push
>     (Stack : in out Stack_Type;
>      Item  : in Item_Type);
> 
> private
> 
>   type Stack_Type (Size : Positive) is
>     limited record
>       Top : Natural := 0;
>       Items : Item_Array (1 .. Size);
>     end record;
> 
> end Stacks;
> 
> 
> Now consider an implementation of Push:
> 
>   procedure Push
>     (Stack : in out Stack_Type;
>      Item  : in     Item_Type) is
> 
>      subtype Top_Range is Positive range 1 .. Stack.Size;
> 
>      Top : Natural renames Stack.Top;
>   begin
>      Top := Top_Range'(Top + 1);    --???
>      Stack.Items (Top) := Item;
>   end Push;
> 
> 
> Is it possible, because of 11.6 permissions, that the explicit range
> check in the marked line can be optimized away?

Only in rather strange cases.  E.g., if you said:

    X: Stack_Type;
    ...
    Push(X, Some_Item);

and then never again referred to X, I believe 11.6 allows the compiler
to eliminate all the code, including the marked range check.

But why would you push some information onto a stack if it's provable
that you're never going to use that information?

Whether any given compiler is smart enough to do the above is another
question...

> Another question: if I compile this (or the instantiation?) with checks
> off, then will that cause the explicit range check to be omitted?

Yes, in practice.  A compiler should remove any suppressed check that
costs anything at run time, and on almost all machines I can think of, a
range check will cost something.  But that's just "Advice" -- formally
speaking, pragma Suppress doesn't *require* the compiler to do anything;
it merely *allows* the compiler to do something (namely, leave out
otherwise-necessary checks).

There are some machines on which overflow checking is free (or nearly
free), and a compiler might well ignore suppression of the overflow
check.  Similarly, it is possible to implement Storage_Error
(stack-overflow) checking for free using virtual-memory tricks -- I
would expect such a compiler to ignore the suppression of those checks,
since it would have to go to extra trouble for no benefit.

As to whether the pragma Suppress belongs on the generic or the
instantiation, I'm not sure if the RM really makes that clear (and I'm
too lazy to look it up), and I wouldn't be surprised if compilers differ
in that regard.  Certainly, a compiler that shares code for generic
bodies isn't going to pay attention to a pragma applied to the instance.
On the other hand, a macro-expansion implementation could conceivably
pay attention to either, or both.  I'm not sure what our compiler does.

In practise, a lot of people don't use pragma Suppress -- they use some
sort of compiler switch instead, and of course the semantics of that
switch are not addressed by the RM.  The compiler writer might define
the semantics of the switch in terms of an imaginary pragma Suppress.

- Bob

Re: 11.6

[Matthew Heaney]

In article <wcchfiexwj3.fsf@world.std.com> , Robert A Duff 
<bobduff@world.std.com>  wrote:

>>   procedure Push
>>     (Stack : in out Stack_Type;
>>      Item  : in     Item_Type) is
>>
>>      subtype Top_Range is Positive range 1 .. Stack.Size;
>>
>>      Top : Natural renames Stack.Top;
>>   begin
>>      Top := Top_Range'(Top + 1);    --???
>>      Stack.Items (Top) := Item;
>>   end Push;


Compare that Push with this one:

 procedure Push
   (Stack : in out Stack_Type;
    Item  : in     Item_Type) is

    Stack_Not_Full : constant Boolean range True .. True :=  --???
      Stack.Top < Stack.Size;

    Top : Natural renames Stack.Top;
 begin
    Top := Top + 1;
    Stack.Items (Top) := Item;
 end Push;


Can the marked line be optimized away per 11.6?


--
Why stop at evolution and cosmology, though? Let's make sure that the
schoolkids of Kansas get a really first-rate education by loosening up
the teaching standards for other so-called scientific ideas that are,
after all, just theories. The atomic theory, for example. The theory of
relativity. Heck, the Copernican theory--do we really know that the
universe doesn't revolve around the earth?

John Rennie, Scientific American, Oct 1999

Re: 11.6

[Robert A Duff]

"Matthew Heaney" <matthew_heaney@acm.org> writes:

> Compare that Push with this one:
> 
>  procedure Push
>    (Stack : in out Stack_Type;
>     Item  : in     Item_Type) is
> 
>     Stack_Not_Full : constant Boolean range True .. True :=  --???
>       Stack.Top < Stack.Size;
> 
>     Top : Natural renames Stack.Top;
>  begin
>     Top := Top + 1;
>     Stack.Items (Top) := Item;
>  end Push;
> 
> 
> Can the marked line be optimized away per 11.6?

Yes.  (I don't like 11.6, by the way.)

But in the above you will still get a check on the array indexing.

- Bob