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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8f8cea8602e61aba X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: The Red Language Date: 1997/09/12 Message-ID: #1/1 X-Deja-AN: 272069681 References: <340ED5D8.2DEF6D3@ux4.sp.cs.cmu.edu> <199709051335.PAA25952@basement.replay.com> <34102DF5.36D589F1@ux4.sp.cs.cmu.edu> Organization: New York University Newsgroups: comp.lang.ada Date: 1997-09-12T00:00:00+00:00 List-Id: Art says <> No, Art, you are still confusing a language definition with implementation notes. Who implements the language specification is quite irrelevant! <> A very common confusion, actually two confusions mixed up. 1. A language definition usually has nothing to say about timing performance, so a compiler is free to implement any statement efficiently or inefficiently. Since there is no constraint on efficiency, a change in efficiency is NOT a semantic effect, even though it may affect the timing of the program. Basically if you take timing into consideration, then all the language semantics are non-deterministic, and a change in performance is simply a manifestation of this non-determinism. 2. You are assuming that inlining necessarily makes the program run faster. This is not at all the case: 2a. Any movement of code like this may alter instruction cache effects, and arbitrarily slow down or speed up execution. 2b. On some machines it is simply less efficient to inline the code. For example, on the IBM 360, if you inline, then you increase base register pressure, whereas out of line, the call establishes a convenient local base register. So it cannot be the case that ignoring inlining is an effect because it would slow things down and make the app miss its deadline, it is equally likely that *doing* the inlining would slow things down and make the deadline be missed. It is point 2 incidentally which leads us to be a bit vague in Ada about what pragma Inline means, even informally. Generally a programmer who specifies pragma Inline is asking for the compiler to generate code that is as fast as possible, even if it requires more space. In a situation where inlining would slow things down, it seems quite reasonable, even desirable for the compiler to ignore the request. > As for "we believed him, why not?", the why not is because the claim was > on its face unsupportable! <> But the issue is whether GNAL achieved the effect of requiring inlining *at the language definition level*. That's the issue here. Sure you can believe an implementor who says something about his implementation, and it was quite reasononable for you to believe that. However, you have given no basis at all for believing that he achieved the goal of requiring inlining at the language definition level. Remember it was you who started this thread with the claim that GNAL, unlike Ada, required inlining at the language definition level. You have not at all substantiated that claim (nor do I think it is possible for you to do so!)