Re: optimizating compilers (VMS ADA)

Re: optimizating compilers (VMS ADA)

[TENE]

In reply to Norman Cohen:

>Noam Tene appears to be claiming that an optimizing compiler is free to
>change the meaning of a program in order to achieve faster execution.
>This is a dangerous attitude.

I agree. It is dangerous and as you pointed out can be taken to an
extreme. However I claim that ANY optimization that goes beyond "Good
code" generation must have such freedoms and could introduce these
dangers.

To repeat parts of my previous letter:

>>I think that expectating the results of an optimized compilation
>>to be the SAME as those of the non optimized one for erroneous
>>programs (or bad programs on the edge) is ridiculus.
>>There is one BIG difference - execution time, for that you must pay.

>>A program compiled with a NOCHECK qualifier (or its equivalent on other
>>compilers) clearly is not legaly compiled. I still want this option to be
>>available, (even though it should be used with care and only when the saving
>>justifies the risk).

>>"This is NOT a bug its an option".
>>you don't have to use it !!!

I am NOT saying that the optimized code is or should be legal I am
saying that IF you want faster execution you must PAY for it. VAX
ADA does NOT use the optimizer by default (unless the system manager
interferes with it) if it had it would have been a bug. As it is
trying to use the program with an optimizer is wrong. You may as
well compile with a NOCHECK qualifier and complain that the compiler
does not raise the neccesary exceptions, if it doesn't its because
you asked it not to.

>>I think that the optimizer must be allowed some room to work.
>>The above examples should be erroneous. I'm not sure what the book
>>says, I wouldn't write programs using these methods in any language.

Re-reading this statement after the reply from Norman Cohen I would like
to re-state it. These examples should have been erroneous (I am not sure
they can be classified as errors since it would be hard to detect them
at compilation time) but even when they are not erroneous they are
bad-programming.

I compile my ADA programs without the optimizer (If I wanted strong
optimization I would write in MACRO or C which I still have to do on
occasion) However when I write my programs I keep in mind that someday,
somebody (even me) may want to optimize it so I try not to write code
that may introduce errors on optimization.

I understand and passively support the "strict constructionist" attitude.
I agree that ADA (which started out this way) could (and maybe should)
have gone all the way and defined a strict language semantics.
Mathematical rigor in the design of programming languages, probably would
increase the number of truly safe and legal optimizations which would
then make the need for unsafe optimization less critical.

When I first encountered the concept of an erroneous program in ADA I
was bothered by the fact that these could not always be detected by
compilers (some of the problems are NP complete so you have to live with
this but I don't have to like it). This means that a program can pass
compilation, work correctly and still be erroneous. The concept of an
erroneous program leaves the resposibility on the programmer, not the
compiler. When we come to the use of optimization this is once again
a case where the responibility is on the programmer, this time the
program may even be legal ADA but using an optimizer on programs
which do not take its effects into account is bad programming.

> However, Tene considers it appropriate for an optimizing compiler to take
> even further liberties than those generously allowed by the Ada RM.  He
> states, for example:
>>      would resolve the problem ONLY IF no optimization is done."
>>      "If you want optimization ... you must pay by being more careful
>... if a compiler treats "nearly erroneous programs" or "bad programs
> on the edge" as if they WERE erroneous, that compiler violates the Ada
> standard.

Once again, the VAX ADA compiler does NOT do these by default, ONLY
when you ask it to optimize.

>The writer of the program that deallocates a variable used earlier as
>the initial-value expression in a constant declaration has every right to
>expect that his program will execute normally.  Even if his program has a
>vague resemblance to one that is erroneous, it is not itself erroneous.
>(In fact, I would not even characterize it as a "bad program on the
>edge."  I am a stickler for good Ada style, but this usage seems quite
>appropriate to me.)

The program as you said is not erroneous. However the vague resemblence
is fatal for any optimizer. You may expect the optimizer to recognize
that disposing A will free A.all in this simple case... , But would you
expect it to recognize the same condition it A.all was not so simple but
rather the a node of some global tree which you could have freed using
UNCHECKED deallocation? You're asking too much from the optimizer.
If you want such a program to work DON'T use an optimizer on it.

>Tene suggests a NOOPTIMIZE pragma if one wants to guarantee that a
>program will execute with the meaning stipulated by the Ada RM, but he's
>got it backwards.
> ...
>In effect, such a pragma is a promise by the programmer to
>the compiler to obey certain programming restrictions that will make
>the optimization safe; execution of the program is erroneous if it
>violates this promise.

I'm afraid you got me backwards. In this I'm on your side and so is the
VMS ADA compiler. The user made that promise when he compiled with
an OPTIMIZE qualifier which is not the default, using the NOOPTIMIZE
pragma would override that qualifier and may solve his problem.

                              Noam Tene
                            System manager
                        Bio-Medical Engineering
                        Technion, Haifa, Israel
                          tene@techmax.bitnnet

Re: optimizating compilers (VMS ADA)

[Dennis Doubleday]

In article <8801201714.AA15107@ajpo.sei.cmu.edu> TENE@TECHMAX.BITNET writes:
>Once again, the VAX ADA compiler does NOT do these by default, ONLY
>when you ask it to optimize.
>...
>If you want such a program to work DON'T use an optimizer on it.
> The user made that promise when he compiled with
>an OPTIMIZE qualifier which is not the default...

I don't really think that this is a convincing argument.  I agree completely
with Mr. Cohen and Mr. Firth that an optimizer should not change the
meaning of a program.  To allow otherwise is to allow any sort of dubious
"optimization" that improves a program's time or space usage while
introducing unintended and unpredictable consequences.  In any event, Mr.
Tene, your claim is flatly wrong:  page A-21 of DEC's publication
"Developing Ada Programs on VAX VMS" says :
    "By default, the COMPILE command applies full optimimization..."
-- 
UUCP:	seismo!mimsy!dday                        Dennis Doubleday
CSNet:	dday@mimsy				 University of Maryland
ARPA:	dday@mimsy.umd.edu			 College Park, MD 20742
Fan of: Chicago Cubs, Chicago Bears, OU Sooners	 (301) 454-6154

Re: optimizating compilers (VMS ADA)

[Erland Sommarskog]

Noam Tene (TENE@TECHMAX.BITNET) writes:
>I am NOT saying that the optimized code is or should be legal I am
>saying that IF you want faster execution you must PAY for it. VAX
>ADA does NOT use the optimizer by default (unless the system manager
>interferes with it) if it had it would have been a bug. As it is
>trying to use the program with an optimizer is wrong. You may as
>well compile with a NOCHECK qualifier and complain that the compiler
>does not raise the necessary exceptions, if it doesn't its because
>you asked it not to.

This discussion is going round and round it seems. It would at
least be grateful if the debateurs kept to facts. I've just check
out two VMS machines. Extracting the Ada command on both gives
that /OPTIMIZE is the deafult. (To be accurate /OPTIMIZE=TIME is
the default.) This was Ada V1.4. Have you a newer version?
  So according to Tene there is a bug the compiler at that point, 
but I can't see where the bug lies. Can you point me the page in 
the LRM that forbids optimization?

>I'm afraid you got me backwards. In this I'm on your side and so is the
>VMS ADA compiler. The user made that promise when he compiled with
>an OPTIMIZE qualifier which is not the default, using the NOOPTIMIZE
>pragma would override that qualifier and may solve his problem.

Wrong again. At least my understanding of HELP ADA/OPTIMIZE was 
that the qualifier overrides the pragma.
-- 
Erland Sommarskog       
ENEA Data, Stockholm        "Will you remember president Reagan
sommar@enea.UUCP             will you rememeber all the bills we'll have to pay
                             or even yesterday, tomorrow?" - David Bowie

Re: optimizating compilers (VMS ADA)

[Thomas P. Morris]

In article <8801201714.AA15107@ajpo.sei.cmu.edu>, TENE@TECHMAX.BITNET writes:
> In reply to Norman Cohen:
>             ... These examples should have been erroneous (I am not sure
> they can be classified as errors since it would be hard to detect them
> at compilation time) but even when they are not erroneous they are
> bad-programming.

	I don't believe the code in the original example was erroneous.
Where in the LRM does it classify the actions of that code as erroneous?
If anything, the compiler's optimization ought to be considered erroneous,
tenously in violation of LRM 3.2.1.6-8 (object elaboration rules), in that
the "initial value" obtained by evaluation of the explicit initialization
should be the CONTENTS of the STRING pointed to, not the ADDRESS of the
STRING pointed to. Yes, I know that most compilers and runtimes consider
a string and its address as one and the same thing. But compile-time semantic
checks should not do so. Structure-sharing between the physical storage occupied
by a constant and a variable must be erroneous, although there is no 
explicit statement in the LRM to that effect.

> I understand and passively support the "strict constructionist" attitude.
> I agree that ADA (which started out this way) could (and maybe should)
> have gone all the way and defined a strict language semantics.
> Mathematical rigor in the design of programming languages, probably would
> increase the number of truly safe and legal optimizations which would
> then make the need for unsafe optimization less critical.
> 
     Definition of strict language sematics would certainly have helped
greatly in this case. As above, if strict semantics had been defined, it
would have been quite clear that the compiler ought not to share storage
occupied by a variable (A.all) and a constant.

Tom Morris

Re: optimizating compilers (VMS ADA)

[Dave Seward]

In article <8801201714.AA15107@ajpo.sei.cmu.edu> TENE@TECHMAX.BITNET writes:
>In reply to Norman Cohen:
>
>>Noam Tene appears to be claiming that an optimizing compiler is free to
>>change the meaning of a program in order to achieve faster execution.
>>This is a dangerous attitude.
>
>I agree. It is dangerous and as you pointed out can be taken to an
>extreme. However I claim that ANY optimization that goes beyond "Good
>code" generation must have such freedoms and could introduce these
>dangers.

As an Ada compiler developer, I am of course very interested in this issue.
I personally side with Mr Cohen on this issue, but I must produce a product
that satisfys a marketplace, *as well as being validated*. I would, therefore
appreciate feedback (e-mail) from as wide an audience as possible, indicating
opinions about this issue. I can summarize the responses for this group, if
desired. Thanks, in advance...

Dave Seward
uunet!actnyc!djs