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: robert_dewar@my-dejanews.com Subject: Re: should I be interested in ada? Date: 1999/02/21 Message-ID: <7anl92$om3$1@nnrp1.dejanews.com> X-Deja-AN: 446549259 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> <36CDE19E.2F1C@lanl.gov> <7ald0t$sb$1@plug.news.pipex.net> X-Http-Proxy: 1.0 x9.dejanews.com:80 (Squid/1.1.22) for client 129.37.79.86 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Sun Feb 21 00:50:44 1999 GMT Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I) Date: 1999-02-21T00:00:00+00:00 List-Id: In article <7ald0t$sb$1@plug.news.pipex.net>, "Nick Roberts" wrote: > I concede this; it is true. Well that's a remarkable statement, yes I agree something being true should be reason to "concede" :-) :-) > However, I would assert that situations where the > occurrence of aliasing cannot be disproved are rare, in > practice. It is moderately unusual for a subprogram to be > declared which has two parameters of the same type (or > the same dimensionality and base type), and which > updates one or both. Well as I said before, more and more, I suspect you have not written many large Fortran codes. Certainly in the Fortran systems I have worked on, this is not "moderately unusual" it is absolutely typical. Furthermore, this is not a consequence of the language, but rather it is typical of numerical codes. A trivial case would be a transposition of a square matrix with an input array and an output array. A Fortran compiler can just assume that the two parameters are not aliased, but an Ada compiler may not make this assumption (even in Ada 83, where the rules were vaguer and may have allowed more liberal assumptions, this one is tricky). Nick, I assume you are aware of the fairly radical change between Ada 83 and Ada 95 here. In Ada 83, programs that whose behavior depended on whether parameters are passed by reference or value are considered erroneous, but in Ada 95 such programs are merely non-deterministic. This can actually make the situation worse in Ada 95 (the reason for the change was that the Ada 83 statement was impossible to formalize). The history here is odd, the original Ada 83 design was an attempt to copy the freedom of Fortran, but it did not get it quite right, and in particular, the very clean Fortran rule on when aliasing is invalid was not copied. The Fortran rule is that assignment via one path is erroneous if there is more than one path to a variable. There is no doubt at all that the aliasing information that can be gathered in an Ada program is less precise than that in a corresponding Fortran program in this particular case, and that this situation arises pretty frequently in practice (Nick, there was a long discussion of this point in the design process, but I do not know if clear documentation of this discussion survives). What is not clear is how much effect this has in practice. It is reminiscent of the argument that Ada can get more precise aliasing information than C, and that therefore Ada compilers should be able to generate better code than C compilers, other things being equal. The trouble is that other things are almost never equal, and individual optimizations are almost always disappointing in practice. I would therefore tend to agree that the bottom line effect here is probably infrequent, but it may occur in tricky situations. For example, it is easy for a general formulation of matrix multiplication to run into trouble: type X is array (integer range <>, integer range <>) of float; procedure Matrix_Mult (A, B : in X; C : out X); Now remember the Ada rules here, you cannot assume that A and B are not aliased with C. If this aliasing *does* occur, it means that the effect of the code in the body of Matrix_Mult must reflect the proper semantics with respect to the ordering of statements if the parameters are passed by reference. This can *considerably* restrict the ability of the compiler to reorder statements. For example, if one of the multiplications in the processing causes a Constraint_Error, then we must be able to see that exactly the "right" set of assignments has occured up to that point, and we can see that effect on the calling parameters. This means that at least theoretically, the Fortran compiler may have an advantage. As I say, whether this advantage is important in practice, who knows. But note that this is VERY different from the point Nick makes. Nick is claiming that this situation does not arise in practice, when in fact it does arise very often in practice. The question is not whether it arises, but how significant it is when it does arise. > It is quite possible for the compiler to generate two > object code versions for such a subprogram (one for > parameters definitely non-aliased, one for > otherwise), and call the appropriate one at different > call sites. Maybe possible ... practical, no! > I would be interested if anyone could cite (or show) an > example of a real world Fortran or Ada program having > such a subprogram which is called using parameters that > could be aliased, and where an optimiser is unlikely to > be able to determine they are not. (I suspect that there > are such programs, but that they are very rare.) They are in fact common, I gave two obvious examples here, but if you want more, look at any large linear algebra package. One piece of history here is that when this issue was discussed (rather extensively) by the DR's, I cannot remember anyone making Nick's claim that the situation was uncommon. On the contrary we all agreed it was common, the issue was (a) can we figure out clean rules in Ada that would allow appropriate aliasing assumptions to be made (bottom line answer, we couldn't, the Fortran approach seemed to radical, since it invalidated previously valid programs). (b) is the difference important enough to worry about. Bootom line answer: probably not, based on the kind of reasoning given above. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own