TENE@TECHMAX.BITNET (01/21/88)
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
dday@mimsy.UUCP (Dennis Doubleday) (01/22/88)
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
sommar@enea.se (Erland Sommarskog) (01/22/88)
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
tpmsph@ecsvax.UUCP (Thomas P. Morris) (01/22/88)
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
djs@actnyc.UUCP (Dave Seward) (01/29/88)
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