From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fd3a5ba6349a6060 X-Google-Attributes: gid103376,public From: William Clodius Subject: Re: should I be interested in ada? Date: 1999/02/21 Message-ID: <36D04A5C.7DE1@lanl.gov> X-Deja-AN: 447533250 Content-Transfer-Encoding: 7bit References: <7a72e6$g55$1@probity.mcc.ac.uk> <36C93BB4.1429@ecs.soton.ac.uk> <7afc1o$3mi$2@plug.news.pipex.net> <7afttr$7v3$1@nnrp1.dejanews.com> <7aganu$qsc$1@plug.news.pipex.net> <36CC11A1.C7A71642@hercii.mar.lmco.com> <7ahkn0$kab$1@plug.news.pipex.net> <36CC6AC0.25DBE56D@erols.com> <7aikfp$nhq$3@plug.news.pipex.net> <7ajkhb$dol$1@nnrp1.dejanews.com> <7aknfn$au1$1@plug.news.pipex.net> <7akted$i86$1@nnrp1.dejanews.com> Content-Type: text/plain; charset=us-ascii Organization: Los Alamos National Lab Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-02-21T00:00:00+00:00 List-Id: robert_dewar@my-dejanews.com wrote: > > First of all, it is of course impossible to "enforce" the > no aliasing rule, that is why it such enforcement is > neither expected nor required (it is like uninitialized > variable access in Ada). While it is impossible to correctly identify all instances of aliasing, in practice: 1. The simplest forms of modifiable aliasing appear to be the most common, perhaps because most programmers are unsophisticated, and these forms can be correctly identified. 2. It may be possible to define a usefull heuristics that identifies all statements with possible instances of modifiable aliasing, but generates spuriouw warnings. Similar heuristics are being investigated for C in an attempt to generate acceptable performance with near linear aliasing analysis. Because detecting the simple cases does not detect all cases, and the second case generates spurious warnings, the standard does not require either capability. I believe some compilers and FTNCHK will generate warnings for many instances of the first case, and I believe some code quality verification tools will attempt the second. > > It is quite false that compilers do not take advantage of > the aliasing rules of Fortran, they very definitely do, and > I do not know from where you would get a contrary > impression. Even Fortran-2 on the 7090 took advantage of > these rules (which were already enshrined in the Fortran > 66 standard). > Odd! The 7090 is before my time and I have done very little, if any, IBM mainframe programming, but I have never heard of Fortran -2. I thought that untill the late 70's IBM consistently used Roman numerals for its Fortran compilers, after the first Fortran compiler Fortran - 1957 often subsesquently referred to as Fortran I Fortran II - 1958 Fortran III never commercially availlable, used in house and in beta testing around 1960 Fortran IV - 1962 - the name for most IBM compilers untill the late 70s Fortran V - 1964, never realy available Fortran VI - never really available - initial name for what became PL/I In the first volume of the History of Programming languages, edited by Wexelblat, Backus goes into detail about the optimizations available for Forran I and II, which actually match most of the optimizations of interest here, i.e., the optimizations predated both Fortran 66 and the 7090. I suspect you are actually thinking of Fortran II for the IBM 709. Most references I have seen state that Fortran IV was primarilly used to program the 7090, and that for a number of years the Fortran IV compiler had little or no optimization. (People disliked the long turnaround times of Fortran II.) I suppose the Fortran II compiler may have also been available for the 7090, however I would be very surprised if they put the effort in that would be required to make it compatible with Fortran 66, which was largely based on the Fortran IV documentation I had also always assumed that the description of Fortran's argument passing mechanism was taken with little modification from IBM's manuals for Fortran IV, which had in turn taken them from Fortran I and Fortran II for several reasons: 1. The manuals should have described the argument passing mechanism. 2. At the time the Fortran manuals were written no one at IBM (or perhaps elsewhere in the world) knew how to correctly describe call by reference, otherwise Backus would have suggested an alternative to call by name in the development of Algol 60. If call by reference was implied, the descripotion is the simplest that allows that implementation. 3. I think (my memory is hazy here) some of the optimizations Backus describes for Fortran II were not completely compatible with call by reference. For what its worth, most Fortran programmers are not aware of Fortran's argument passing mechanism, but they also don't use the sophisticated data structures or data access methods where a well defined call by reference mechanism would be usefull. Aliasing, when it occurs, was not desired and they would rather have it identified quickly rather than it have a well defined meaning. Still there are a number of programs that assume a close approximation to call by reference semantics. These appear to have been mostly created on mainframes in the sixties, and personal computers in the late 70's and early 80's, situations where highly optimizing compilers were rare or non-existent. In practice, most compilers have low optimization modes, principally for debugging purposes, which in essence process statements sequentially, which in turn is sufficient to provide the desired semantics. Another Fortran optimization "problem" is the language's assumption that functions have no significant side effects, which users often want to use for random number generators or warning flags of various kinds. In practice the warning flags usually work (although the language does not define their behavior) when the processor decides to execute the function, but random number generators implemented as functions are a notorious source of hard to detect problems with code. -- William B. Clodius Phone: (505)-665-9370 Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815 PO Box 1663, MS-C323 Group office: (505)-667-5776 Los Alamos, NM 87545 Email: wclodius@lanl.gov