From: Georg Bauhaus on
On 13.08.10 17:10, Elias Salom�o Helou Neto wrote:

>> 1) You can, in more than one way, tell the compiler to suppress most
>> (any?) checks, but people do not advise to do so. Even if I say that I
>> do need that :(

Don't worry. A rule frequently heard is that if your requirements,
either directly or by implication, include highest possible speed,
lowest possible overhead, or whatever, then these are requirements
and Ada (designed to be usable also in hard real-time environments,
as might be mentioned...), must provide for meeting the requirements.
If the LRM did not address absence of checks, Unchecked_Conversion etc.,
this goal would not be met, nor Ada's, see below.

Some here have been involved in an almost insane effort to achieve
highest possible speeds, very much at the cost of a clear,
obvious algorithm. And of course we couldn't tolerate any
checks in a program that we knew wouldn't need them!
A nice result is that the programs still do not need
to resort to CPU-specific macros, say, to achieve highest speed.
They use plain Ada and the compiler produces good code.
(BTW, one can use standard Ada facilities to have the compiler
"try" different object code, via representation clauses, or suitably
defined (and sized) types.)

>> 2) It is not necessary for the compiler to actually suppress any
>> checking! It seems that the LRM demands the compiler to allow you to
>> misunderstood something here.

> ask for the suppression, but it does NOT mandate the compiler to
> actually
> skip such checks. Well, this is, to say the least, funny - unless I

1. An authoritative comment from an ARG member has been (more than
once) that the LRM never requires anything stupid, or funny, as
you have put it. Range checking can be turned off. (In fact,
the SPARK effort can be understood to mean that a SPARK
program can run without checks because it has been analyzed
and found to be without need for any checks.)

2. By the AS-IF rule, a compiler need not even introduce checks
where it can show at compile time that none are needed. I think
Dmitry has hinted at this.

3. Even though pedantically one might insist on what seems written
in the LRM and dismiss the implications of equally dependable
1. and 2., it helps remembering that you cannot do so in the
real world:
From the outset Ada was made by and for customers. This is documented
in the archives. If the LRM had mandated funny things, like
precluding perfectly normal compiler pragmatics, there would have
been little support (and the whole thing wouldn't be consistent
with Ada language requirements).

4. The description (however obsolescent) of pragma Suppress
mentions "permission"; an indication that programmer allows
compiler to suppress. Consequently, and consistent with what
is usually the case with many other language AFAIK, suppressing
checks is a compiler thing, and the LRM even expressly mentions
this.

In fact, documents have been more explicit.
This is from the June 1978 Requirements

"1D. Efficiency. The language design should aid the production of efficient
object programs. Constructs that have unexpectedly expensive implementations
should be easily recognizable by translators and by users. Features should
be chosen to have a simple and efficient implementation in many object
machines, to avoid execution costs for available generality where it is not
needed, to maximize the number of safe optimizations available to
translators, and to ensure that unused and constant portions of programs
will not add to execution costs. Execution time support packages of the
language shall not be included in object code unless they are called."

http://archive.adaic.com/docs/reports/steelman/steelman.txt

I think you can rely on programmer control over checks.


Georg
From: Robert A Duff on
Georg Bauhaus <rm.dash-bauhaus(a)futureapps.de> writes:

> 4. The description (however obsolescent) of pragma Suppress
>...

Pragma Suppress is not obsolescent. Just the "On => ..."
feature is.

- Bob
From: Robert A Duff on
Elias Salom�o Helou Neto <eshneto(a)gmail.com> writes:

>> Anyway, someone prematurely implied that I may be doing premature
>> optimization. The fact is that I do know, from profiling, how
>> important is _not_ to range check in my specific application, so I
>> will try to give you a "bottom line" of what have been said that
>> really matters to me.
>>
>> 1) You can, in more than one way, tell the compiler to suppress most
>> (any?) checks, but people do not advise to do so. Even if I say that I
>> do need that :(

Even if it's true that it is "important _not_ to range check",
that does not necessarily mean that you need to suppress checks.
As Dmitry pointed out, many checks will be removed by the
compiler even if you don't suppress them -- it will remove the
ones it can prove will not fail. The only way to determine
whether that's good enough is to measure it, and/or look
at the machine code.

As for the advice you mention, if it said "Never suppress checks",
it's bad advice.

> ask for the suppression, but it does NOT mandate the compiler to
> actually
> skip such checks. ...

Of course! That's true of all higher-level languages, including C.
Higher-level language never formally define what machine code gets
generated, nor how efficient it has to be -- there's no way to do so.
A C compiler is allowed by the C standard to do array bounds checking,
and I assure you that if such a C compiler exists, the checks are
FAR more expensive than for Ada.

The Ada RM has some informal rules, called "Implementation Advice"
and "Implementation Requirements", and there's one in there
somewhere saying compilers really ought to skip the checks
when it makes sense.

Don't worry, Ada compiler writers do not deliberately try
to harm their customers -- of course they actually skip the
checks when it makes sense. Note that it doesn't always make
sense, since some checks are done for free by the hardware.

- Bob
From: Jeffrey Carter on
On 08/13/2010 08:10 AM, Elias Salom�o Helou Neto wrote:
>
> ask for the suppression, but it does NOT mandate the compiler to
> actually
> skip such checks. Well, this is, to say the least, funny - unless I

Right. As others have pointed out, are some platforms on which a check cannot be
suppressed, and since the ARM is platform-independent, it does not mandate the
impossible.

But economics plays an important role. Customers won't pay for a compiler that
doesn't behave as expected. As a result, I'm not aware of any compiler that
doesn't actually suppress checks (that can be suppressed) when requested. (If
there is one, no doubt someone will set me straight.)

It's also been noted that some hardware performs some checks for free. On such a
platform, suppressing the check may take more time than leaving it it. So if you
are not able to meet timing requirements with checks, blindly suppressing checks
may make the timing worse, not better.

--
Jeff Carter
"Have you gone berserk? Can't you see that that man is a ni?"
Blazing Saddles
38

--- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: Yannick Duchêne (Hibou57) on
Le Fri, 13 Aug 2010 23:57:44 +0200, Jeffrey Carter
<spam.jrcarter.not(a)spam.not.acm.org> a écrit:
> It's also been noted that some hardware performs some checks for free.
> On such a platform, suppressing the check may take more time than
> leaving it it. So if you are not able to meet timing requirements with
> checks, blindly suppressing checks may make the timing worse, not better.
When you are talking about hardware level checks, are you talking about
check for null address divide par zero and so on or something else ? I
have never heard about a machine with a level array type and an hardware
check for array access index. Would be interesting if you could be more
explicit about these hardware checks.


--
There is even better than a pragma Assert: a SPARK --# check.
--# check C and WhoKnowWhat and YouKnowWho;
--# assert Ada;
-- i.e. forget about previous premises which leads to conclusion
-- and start with new conclusion as premise.