enag@ifi.uio.no (Erik Naggum) (01/14/91)
I haven't been able to get ANSI X3.159-1989, yet, and I found a draft dated 11 Jan 1988. If my question does not apply to the approved standard, that answers my question. In the list of type qualifiers, along with the new const and volatile, a _noalias_ type qualifier is introduced, with a description that I have hard time just parsing. The text goes as follows: If the noalias-qualified lvalues that contains a particular noalias-handle had instead had the non-noalias-qualified version of their types, the set of all objects accessible by these lvalues constitue the _actual_objects_ of the particular noalias handle. ... It's an understatement to say that I spent some time trying to understand this passage, and the following. The Rationale was almost, but not quite, as helpful as the draft text. I haven't seen any mention of "noalias" in ANSI C compilers I've talked to, so I just wonder if I wasn't alone in not really grasping what noalias was good for and why its introduction was required. Can anybody shed some light on the fate of the "noalias" type qualifier? -- [Erik Naggum] Snail: Naggum Software / BOX 1570 VIKA / 0118 OSLO / NORWAY Mail: <erik@naggum.uu.no>, <enag@ifi.uio.no> My opinions. Wail: +47-2-836-863 Another int'l standards dude.
gwyn@smoke.brl.mil (Doug Gwyn) (01/15/91)
In article <ENAG.91Jan14003710@svarte.ifi.uio.no> enag@ifi.uio.no (Erik Naggum) writes: >I haven't seen any mention of "noalias" in ANSI C compilers I've >talked to, so I just wonder if I wasn't alone in not really grasping >what noalias was good for and why its introduction was required. "noalias" was removed as a result of unfavorable public comment. Also, the discussion of "top type" was changed to be more intelligible, again as the result of comments received during the public review. The intent of "noalias" was to provide a way for the programmer to specify that a type level for the specified identifier would not be used in any context where aliasing might occur, thereby allowing the compiler to optimize the code more tightly than is permitted in the general case.
henry@zoo.toronto.edu (Henry Spencer) (02/07/91)
In article <ENAG.91Jan14003710@svarte.ifi.uio.no> enag@ifi.uio.no (Erik Naggum) writes: >I haven't seen any mention of "noalias" in ANSI C compilers I've >talked to, so I just wonder if I wasn't alone in not really grasping >what noalias was good for and why its introduction was required. Its purpose was to let the programmer tell the compiler that arguments to a function were not aliases for each other, for the sake of optimization on vector machines and the like. The optimizing people really cared about it. Unfortunately, (a) the description was exceedingly cryptic and repeated efforts failed to produce one that "did the right thing", (b) it spread slimy tentacles everywhere in the standard libraries, and (c) it was introduced far too late in the development of the standard. The result was a firestorm of protest, including a declaration of war :-) from Dennis Ritchie and formal threats to vote against ratification of ANSI C as ISO C. The committee backed down and removed it. You really need to get a copy of the final standard; drafts that old are not reliable references. -- "Maybe we should tell the truth?" | Henry Spencer at U of Toronto Zoology "Surely we aren't that desperate yet." | henry@zoo.toronto.edu utzoo!henry
dhinds@elaine24.stanford.edu (David Hinds) (02/09/91)
In article <1991Feb7.050917.24550@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >In article <ENAG.91Jan14003710@svarte.ifi.uio.no> enag@ifi.uio.no (Erik Naggum) writes: >>I haven't seen any mention of "noalias" in ANSI C compilers I've >>talked to, so I just wonder if I wasn't alone in not really grasping >>what noalias was good for and why its introduction was required. > >Its purpose was to let the programmer tell the compiler that arguments to >a function were not aliases for each other, for the sake of optimization >on vector machines and the like. The optimizing people really cared about >it. Unfortunately, (a) the description was exceedingly cryptic and repeated >efforts failed to produce one that "did the right thing", (b) it spread >slimy tentacles everywhere in the standard libraries, and (c) it was >introduced far too late in the development of the standard. The result >was a firestorm of protest, including a declaration of war :-) from Dennis >Ritchie and formal threats to vote against ratification of ANSI C as ISO C. >The committee backed down and removed it. That's a shame. Pointers do allow the writing of more efficient code in some cases, but I hate having to tune really time-critical code by introducing lots of dummy variables to hold pointer dereferences, because the compiler can't optimize them worth a damn. Was it really that hard to come up with a clear and useful definition of "noalias", or was it just a result of committee politics fouling it up? Was the proposal to just have "noalias" apply to function parameters? It would seem to be much more useful if it could be used on any pointer variable. -David Hinds dhinds@cb-iris.stanford.edu
henry@zoo.toronto.edu (Henry Spencer) (02/09/91)
In article <1991Feb8.211734.22306@portia.Stanford.EDU> dhinds@elaine24.stanford.edu (David Hinds) writes: > That's a shame... Was it really that hard >to come up with a clear and useful definition of "noalias", or was it just >a result of committee politics fouling it up? Was the proposal to just >have "noalias" apply to function parameters? ... "noalias" was a qualifier, like "const" and "volatile", and could be applied to most anything. This may have been too ambitious, in retrospect. Doing something with function parameters and *only* function parameters might have been inoffensive enough to get by. (In fact, the standard lists as a "future direction" the possibility that declaring more than one parameter as an array -- remember that this is pointless today, since array parameters are really pointer parameters and might as well be written as such -- might someday come to mean "these are not aliases of each other".) I think it was exceedingly difficult to come up with a decent definition of "noalias", given its generality and the qualifier rules then in effect. Some very sharp people tried hard, since it was generally agreed that there *was* a real need. -- "Maybe we should tell the truth?" | Henry Spencer at U of Toronto Zoology "Surely we aren't that desperate yet." | henry@zoo.toronto.edu utzoo!henry
gwyn@smoke.brl.mil (Doug Gwyn) (02/09/91)
In article <1991Feb8.211734.22306@portia.Stanford.EDU> dhinds@elaine24.stanford.edu (David Hinds) writes: >Was it really that hard >to come up with a clear and useful definition of "noalias", or was it just >a result of committee politics fouling it up? Henry's presentation of the history is a bit biased. In fact it is remarkably hard to get a specification for nonaliasing right (meaning: the programmer is able to readily control when the compiler is allowed to hyperoptimize and when aliasing may occur). X3J11 has been wrangling with an interpretation request that involves similar logical issues for over a year now, with no resolution in sight. The root problem is that C serves both low-level and high-level programming goals, and this sort of thing is where no single compromise seems to satisfy both kinds of usage of the language. >Was the proposal to just >have "noalias" apply to function parameters? It would seem to be much >more useful if it could be used on any pointer variable. It was a type qualifier.