bernhold@qtp.ufl.edu (David E. Bernholdt) (03/13/89)
I must apologize to everyone for rehashing in my "DO loops, anyone?" posting a problem which was discussed at length recently. My memory of the original code was only approximate, and I did not think mine was the same problem. Now with the reminders and remarks on this group and from email, I have been set straight. Thanks to those who replied. -- David Bernholdt bernhold@qtp.ufl.edu Quantum Theory Project bernhold@ufpine.bitnet University of Florida Gainesville, FL 32611 904/392 6365
hirchert@uxe.cso.uiuc.edu (03/18/89)
Steven R Weintraub (steve@oakhill.UUCP) writes: >As I stated in my previous post. There is NO problem with the code as >posted. It is not ambiguous. The problem is that the compiler, in >order to prevent any posssible ambiguity, generates bad code. As I stated in MY previous post, there is a big problem with the code as posted -- it doesn't conform to X3.9-1978, the ANSI FORTRAN standard. Just because a compiler doesn't extend FORTRAN in the way you want it to (even if the extension you want is reasonable) doesn't mean the compiler is generating "bad code". Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications
hirchert@uxe.cso.uiuc.edu (03/18/89)
Rostyslaw Jarema Lewyckyj (urjlew@ecsvax.UUCP) writes: >The problem is that the standard allows a code construction that >easily leads to misuse and stepping over the legal limits. I.e. >the standard permits a DO loop to end with non trivial executable >statements (eg k=k+1 rather than continue or enddo) and it allows >the closure of multiple DO loops on one statement. >... >I think that the rational solution is to amend the standard (put it >in 8x or 9x if 8x never makes it) to require DO loops to be terminated >one at a time with CONTINUE or ENDDO statements. Fortran 8x has been designed on the assumption that it must be upwards compatible from FORTRAN 77, but that features can be changed in the next revision if we warn them about the change in this this revision. The warning is declare a feature to be obsolescent. Both of the practices you mention have been declared obsolescent. This means that a Fortran 8x processor will have to be able to warn you about these practices and that future processors may make them errors. Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications
steve@oakhill.UUCP (steve) (03/20/89)
In article <50500107@uxe.cso.uiuc.edu>, hirchert@uxe.cso.uiuc.edu writes: > > Steven R Weintraub (steve@oakhill.UUCP) writes: > > >As I stated in my previous post. There is NO problem with the code as > >posted. It is not ambiguous. The problem is that the compiler, in > >order to prevent any posssible ambiguity, generates bad code. > > As I stated in MY previous post, there is a big problem with the code as > posted -- it doesn't conform to X3.9-1978, the ANSI FORTRAN standard. Just > because a compiler doesn't extend FORTRAN in the way you want it to (even if > the extension you want is reasonable) doesn't mean the compiler is generating > "bad code". > > Kurt W. Hirchert hirchert@ncsa.uiuc.edu > National Center for Supercomputing Applications If you read my articles, you will see I repeatedly state this is officially illegal. You claim that since this code is illegal whatever the customer gets, he deserves. Since there is no definition, there is no defined behavior. Theoretically you are right. But, the problem does appear repeatedly in the real world. And there is an assumed behavior. The behavior is that these two do loops act concurrently, that the jump to the terminating statement increments the last active loop and goes through the next loop cycle. The question arises on what to do if the terminating statement is exectuable, which is what started this line of discussion originally (Actually this hiccup was started because of bad code generated). The assumed behavior does not include creating an infinitie loop, causing the internal loop to run if it was to be skipped, or executing the last statement twice. And if you generate something that does any of these, it is wrong. enough from this mooncalf - Steven ---------------------------------------------------------------------------- To flame someone for bad spelling or grammer is a discouragement to net discussion in a timely fashion. ---------------------------------------------------------------------------- These opinions aren't necessarily Motorola's or Remora's - but I'd like to think we share some common views. ---------------------------------------------------------------------------- Steven R Weintraub cs.utexas.edu!oakhill!devsys!steve Motorola Inc. Austin, Texas (512) 440-3023 (office) (512) 453-6953 (home) ----------------------------------------------------------------------------
chris@mimsy.UUCP (Chris Torek) (03/20/89)
In article <1919@devsys.oakhill.UUCP> steve@oakhill.UUCP (steve) writes: >... the problem [of branching into inactive DO-loops, in particular to >terminating CONTINUE statements] does appear repeatedly in the real >world. And there is an assumed behavior. Not so. The problem does appear; but there are *two* assumed behaviours. Yours is only one of them. (The other is for the compiler to manufacture extra labels so that the branch is not into an inactive DO-loop.) It is not clear which to choose; I say the compiler should reject the code, unless one of two switches is used, each of which causes the compiler to run the code at about 1% full speed (by inserting delay loops). *That* should get people to fix their code! :-) `Well, we *did* say it would run slower if you demanded it work your way' :-) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
steve@oakhill.UUCP (steve) (03/20/89)
In article <16448@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > In article <1919@devsys.oakhill.UUCP> steve@oakhill.UUCP (steve) writes: > >... the problem [of branching into inactive DO-loops, in particular to > >terminating CONTINUE statements] does appear repeatedly in the real > >world. And there is an assumed behavior. > > Not so. The problem does appear; but there are *two* assumed behaviours. > Yours is only one of them. (The other is for the compiler to manufacture > extra labels so that the branch is not into an inactive DO-loop.) It is > not clear which to choose; I say the compiler should reject the code, > unless one of two switches is used, each of which causes the compiler > to run the code at about 1% full speed (by inserting delay loops). > > *That* should get people to fix their code! :-) > > `Well, we *did* say it would run slower if you demanded it work your way' :-) > -- > In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) > Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris I don't know about you, but I am in the business of selling the software I write. I would much like the safe, protected life of theoretical programming. One of the reasons I got into compiler work is I thought it of all computer science fields was the nearest to theory. I have repeated said there are three behaviors. 1) Error out. 2) Act as if there is an implicit CONTINUE at the end for the external loop. 3) Act as if the last statement was in a special class that gets run once every loop interation (external or internal). In the a previous post I told you I tried option one. When the market cried, I had to try something else. I did option 2. I also made it so you had to ask for option 2. Your solution is only making a phyiscal representation of option 2. I always felt that compilers which generated code that it knew should be there (like a CONTINUE in this case) were somewhat odd. If you create the blocks orderly as you are generating this code, there is no need to remind oneself what you mean. (If you want to get me into a discussion on indepth generation of DO loops, I'm game). As for the sugestion of delay loops, well any company that did that would not last in the business long. To tell the buyer that he does not know how to program is not the best way of drumming up business. (If you want to get me into a discussion of what I think is the problems in the software field, I'm game too, but it probably doesn't belong in this group). enough from this mooncalf - Steven ---------------------------------------------------------------------------- To flame someone for bad spelling or grammer is a discouragement to net discussion in a timely fashion. ---------------------------------------------------------------------------- These opinions aren't necessarily Motorola's or Remora's - but I'd like to think we share some common views. ---------------------------------------------------------------------------- Steven R Weintraub cs.utexas.edu!oakhill!devsys!steve Motorola Inc. Austin, Texas (512) 440-3023 (office) (512) 453-6953 (home) ----------------------------------------------------------------------------
hirchert@uxe.cso.uiuc.edu (03/21/89)
Steven R Weintraub (steve@oakhill.UUCP) writes: >If you read my articles, you will see I repeatedly state this is >officially illegal. My news feed has been a bit sporadic lately, so I may have missed you earlier postings. The posting to which I replied did not acknowledge that the code was not standard conforming. If it had, I probably woudln't have bothered posting myself. > You claim that since this code is illegal >whatever the customer gets, he deserves. Since there is no definition, >there is no defined behavior. This is an overstatement of my position. I believe . that people writing standard-conforming programs deserve correct behavior, . that people knowingly trying to port nonstandard code deserve the problems that they are likely to encounter, and . that people inadvertantly violate the standard deserve help as much help as can practically be given in finding these violations. This latter point is a "quality of implementation" issue. I would label a processor that doesn't provide such help as "of low quality" or even as "junk" but not as "wrong" or generating "bad code", since these latter terms imply (to me, at least) a failure to handle correct programs correctly. >(paragraph about assumed behavior deleted) >The assumed behavior does not include creating an infinitie loop, >causing the internal loop to run if it was to be skipped, or >executing the last statement twice. And if you generate something >that does any of these, it is wrong. You have to be careful about these "assumed behavior" arguments. People make lots of incorrect assumptions. For example, many people assume you can pass a double precision actual argument to a single precision dummy argument and that this will "work" because the first half of a double precision value looks like a single precision number with approximately the same value. On many machine, this will work, but on many others (including machines with IEEE floating point arithmetic) the result will be just as disastrous as the loop examples we have been discussing. I would not call these latter machines "wrong" because they failed to match the assumed behavior (which was utterly unambiguous). I _would_ give credit for a higher quality implementation to processors that can identify such cases where the actual behavior is not in agreement with the programmer's expectations. Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications
mcdonald@uxe.cso.uiuc.edu (03/21/89)
>> You claim that since this code is illegal >>whatever the customer gets, he deserves. Since there is no definition, >>there is no defined behavior. >This is an overstatement of my position. I believe >. that people writing standard-conforming programs deserve correct behavior, >. that people knowingly trying to port nonstandard code deserve the problems > that they are likely to encounter, and >. that people inadvertantly violate the standard deserve help as much help as > can practically be given in finding these violations. >This latter point is a "quality of implementation" issue. I would label a >processor that doesn't provide such help as "of low quality" or even as "junk" >but not as "wrong" or generating "bad code", since these latter terms imply >(to me, at least) a failure to handle correct programs correctly. I certainly agree that a processor should clearly warn about any non-standard thing it accepts as an extension. And, it would be very nice if a command line switch could turn these warnings into errors, if the user wished. But - but - both Fortran 77 and the proposed Fortran 89+x are lacking in many useful things. Vendors really do need to add extensions if they are going to sell things. I have gotten used to the "quality of implementation" that is standard in the PC C compiler world. (It is true that some of the goodies constitute namespace pollution, but they were added before that concept was set in concrete by X3J11). Graphics libraries - system calls - added operators - calls to do console io - all these are expected by the prospective buyer. In Fortrans these things seem to be left out. Now, if you are using PC compilers, as I do, from Microsoft and MicroWay, then you can cough up the bundle for the C compiler and use the libraries there, and if a given functionality is missing in Fortran, call C routines to do the job. But, you ought not to have to. The vendors ought to supply, either as language extensions (i.e. bit operators) or as subroutines (getting command line arguments, graphics routines, system calls), he same spiffies one gets in C. This is known as "meeting the competition" or "avoiding bankruptcy". Doug McDonald