bleikamp@convex.UUCP (Richard Bleikamp) (08/29/89)
In article <123897@sun.Eng.Sun.COM> khb@sun.UUCP (Keith Bierman - Advanced Languages - Floating Point Group ) writes: >In article <1598@convex.UUCP> psmith@convex.com (Presley Smith) writes: >> >> stuff about f77 codes not running under f8x compilers ... > >>What about the vote in X3J3 on Document 58, 111-RRR-12, "Extra Precision >>option for DATA statement", that was DEFEATED on a role call vote by 24-13? >>To quote from document 111-RRR-12: >> >> "The committee (X3J3), in a previous action, REMOVED the Fortran 77 >> permission for processor to supply extra precision. >> >My experience in porting many large codes amongst machines from over >20 different vendors is that codes which rely on this feature (and >most of the others brought up in debate) are, in fact, not portable >now. Users who have _never_ moved their code off the first processor >it was coded on _may_ be bitten by this (very rarely, I suspect). >Those that moved vendors, or processors (e.g. cdc 7600 to cyber 180) >or even compilers (cft 114 -> cft77) are likely to have purged their >code of anything similar to this (or simply not care that answers >don't match digit for digit ... in fp codes that is an unreasonable >test anyway). >> What I've experienced (in a previous job) contradicts this. I've helped port programs, originally from a CDC or Cray, where single precision has plenty of significant digits for their application. When it was ported to a VAX, only the variables were re-typed (from REAL to DP). The VAX appears to supply a double precision value for real constants ANYWHERE in the program where they are used in a double precision context. So, when the user was considering buying one of our (Harris') machines, it was necessary to imitate the VAX, or lose the business (arguing about non-portable code is hopeless!). So, imitating common existing practice (VAXen) is appropriate. One of X3J3's charters is to standardize existing practice, and this looks like a good example of where they should. Implementing real constants is this manner is unlikely to break any programs (some answers will get "better"?), some programs will become more portable, but when implemented correctly, the run-time penalty is insignificant (it may actually improve performance). ------------------------------------------------------------------------------ Rich Bleikamp bleikamp@convex.com Convex Computer Corporation
achille@cernvax.UUCP (achille petrilli) (08/30/89)
In article <1621@convex.UUCP> bleikamp@convex.UUCP (Richard Bleikamp) writes: >In article <123897@sun.Eng.Sun.COM> khb@sun.UUCP (Keith Bierman - Advanced Languages - Floating Point Group ) writes: >>In article <1598@convex.UUCP> psmith@convex.com (Presley Smith) writes: >>> >>> stuff about f77 codes not running under f8x compilers ... >> >>My experience in porting many large codes amongst machines from over >>20 different vendors is that codes which rely on this feature (and >>most of the others brought up in debate) are, in fact, not portable >>now. Users who have _never_ moved their code off the first processor >>> ........ > >What I've experienced (in a previous job) contradicts this. I've helped port >programs, originally from a CDC or Cray, where single precision has plenty of >significant digits for their application. When it was ported to a VAX, > Now, I like f8x and after having seen this debate presenting even the possibility of having to REWRITE code to have it work in f8x, I'd be\ glad to see some REAL code, that, for the draft std, will have to be rewritten to work under f8x. I'm not talking about precision, this even changes (or could change) with a new release of the fortran library, nothing to do with f77, f8x or whatever, I agree in this with Keith. I guess the opponents to f8x have nothing better to do that try to have people feel f77 and f8x are 2 different things. Let get pragmatic, what should I rewrite under f8x ? do loops, ifs, I/O statements ? what ? I'm really interested to know (despite the fact I like f8x, I'm still able to listen to different ideas :-). Thank you Achille Petrilli Cray Operation
psmith@mozart.uucp (Presley Smith) (08/31/89)
In article <1068@cernvax.UUCP> achille@cernvax.UUCP (achille petrilli) writes: > >Now, I like f8x and after having seen this debate presenting even the >possibility of having to REWRITE code to have it work in f8x, I'd be\ >glad to see some REAL code, that, for the draft std, will have to be >rewritten to work under f8x. I'm not talking about precision, this even >changes (or could change) with a new release of the fortran library, >nothing to do with f77, f8x or whatever, I agree in this with Keith. > Certainly the Fortran 8x standard claims to contain all of FORTRAN 77. And in fact, the compatibility between Fortran 77 and 8x is defined in section 1.4.1 of the proposed standard that is out for public review. The ANSI SD-9 requires the committee to document all changes in the standard that "represents a potential incompatibiltiy from the last existing standard." You will note that section 1.4.1 was ADDED to this proposed standard between the 1st public review and this public review as a result of the committee's attempt to conform to the SD-9. Thus 1.4.1 represents what the committee believes the incompatibilities are. Now, the SD-9 states that the committee must analyze each "addition, deletion, or modification that represents a potential incompatibility from the last existing standard" by the following criteria: 1. Rationale, with benefits and costs, for proposed change 2. Type of difference between versions. 3. Conversion complexity 4. Breadth of impact of incompatibility or variation from existing practice. In fact, changes have been made to this proposed standard for 10 years and each of those changes has NOT been analyzed in this manner specified by the SD-9. Some of the documented differences in section 1.4.1 have been found by reviewers of the document. No list has been kept by the committee of incompatibilities that have been introduced and why. So, one worries... is this a complete set? Many lines of text have been added to this document in the last few meetings and many lines have been changed or removed. How many of the changes to the document and the language effect the FORTRAN 77 part of this proposed standard. Since I don't know of anyone that has implemented Fortran 8x or tested it even by hand for FORTRAN 77 comptability, I certainly am not willing to say that it's FORTRAN 77 compatible with only the things in 1.4.1 being different. You can believe what you want in this matter and must make your own judgement. I have entered the 4 things from 1.4.1 of the proposed new standard. Included are: 1. FORTRAN 77 permitted a processor to supply more precision derived from a real constant than can be contained in a real datum when the constant is used to initialize a DOUBLE PRECISION data object in a DATA statement. This standard does not permit a processor this option. 2. If a named variable initialized in a DATA statement, and does not have the SAVE attribute specified, FORTRAN 77 leaves its SAVE attribute processor dependent. This standard specifies that this named variable has the SAVE attribute. 3. FORTRAN 77 requires that the number of values required by the input list must be less than or equal to the number of values in the record during formatted input. This standard specifies that the input record is logically padded with blanks if there are not enought values in the input list unless the PAD = NO option is specified in an appropriate OPEN statement. 4. This standard has more instrinsic functions than did FORTRAN 77 and adds a few intrinsic subroutines. Therefore, a standard- conforming FORTRAN 77 program may have a different interpretation under this standard if it invokes a procedure having the same name as one of the new standard intrinsic procedures, unless that procedure is specified in an EXTERNAL statement as recommended for nonintrinsic functions in the appendix to the FORTRAN 77 standard. >I guess the opponents to f8x have nothing better to do that try to have >people feel f77 and f8x are 2 different things. Certainly f77 and f8x are two different things. As to whether f77 is completely contained in f8x, you should form your own opinion on this subject. I've given you my rationale and worries in the above explanation. > >Let get pragmatic, what should I rewrite under f8x ? do loops, ifs, >I/O statements ? what ? That's up to you. do loops... do you want to use array notation for an example? If you don't want to use new features, then don't change your code. > >I'm really interested to know (despite the fact I like f8x, I'm still >able to listen to different ideas :-). I believe that those that want 8x should have 8x. And those that don't want it should not have it forced on them. Seems like a simple enough concept to me.
khb@road.Sun.COM (Keith Bierman - Advanced Languages - Floating Point Group ) (08/31/89)
In article <1068@cernvax.UUCP> achille@cernvax.UUCP (achille petrilli) writes: > >Let get pragmatic, what should I rewrite under f8x ? do loops, ifs, >I/O statements ? what ? > Back when I was in the business of crafting portable estimation library software, I determined that most of the "bugs" reported to us were misuse of the programatic interface. Most frequently someone would make a mistake in the use of "scratch" memory which had to be passed to the subroutines, e.g. call WGSG(W,IMAXW,IW,JW,DW,F,V,U) F, and V are JW long ... must be non-overlapping, etc. Many "solve" this sort of problem with COMMON, but we chose to have "clean" interfaces. In many modules the length of the scratch storage required was a complex function, so even good compiler assistence for range checking was not always feasible. Use of dynamic memory clearly allows us to shorten the argument list, reduce the errors, and otherwise make the world a better place. Thanks to KEYWORD argument passing, and DEFAULT clauses, most calls to WGSG would have become something like call wgsg(W=w,U=u) ! or some such Old code would still work, so by concentrating on certain types of declaration magic in the library ONLY, all old user code can be preserved. In Kalman filtering (and many other applications), one has equations of the sort U = PHI*U to perform a deterministic time update. U is upper triangular, PHI is a square transition matrix (though the special case of PHI being triangular is key to performance in many applications ... or other special structures of PHI are typically worth of exploitation). In f77 the code to operate on a UT matrix (vector stored) * a rectangular PHI looked something like CALL PHIU(PHI,MAXPHI,IRPHI,JCPHI,U,N,W,IMAXW) !multiply into temp W CALL U2D(U,NX,DW,1) ! save diagonal CALL WGSG(W,MAXN,NX,NX,DW,F,V,U) ! gram schmidt I had proposed a phased f8x transition, phase #1 to employ every device of the new standard to allow the old interfaces to work with old code + allow simpiler usage (as above). Phase #2 would have required the user to know about the new data typing, and modules so that PHI and U would be typed appropriately, then their code would devolve to U = PHI*U Which makes the name Formula Translator really mean something! Of course, the performance savvy might very well still call the underlying phiu, u2d, wgsg in clever ways to minimize computation ... but most users could get reference quality code trivially. Keith H. Bierman |*My thoughts are my own. !! kbierman@sun.com It's Not My Fault | MTS --Only my work belongs to Sun* I Voted for Bill & | Advanced Languages/Floating Point Group Opus | "When the going gets Weird .. the Weird turn PRO"