Prev: 100% without investment online part time jobs..(adsense,datawork,neobux..more jobs)
Next: installing SPARK GPL on Windows
From: Georg Bauhaus on 13 Aug 2010 14:01 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 13 Aug 2010 15:52 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 13 Aug 2010 16:22 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 13 Aug 2010 17:57 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 13 Aug 2010 18:37
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. |