wsmith@m.cs.uiuc.edu (09/26/88)
I realize this topic has been beat to death and its probably too late for the ANSI C committee to do anything about it, but here's a suggestion anyway. The problem: How can C know when it is safe to rearrange expressions, especially floating point expressions. A proposed solution: Expressions enclosed in double parentheses may not be rearranged, all other expressions may be rearranged in "semantically valid" ways. foo = (a + b - c + d); /* can be rearranged */ foo = ((a + b - c + d)); /* cannot be rearranged */ foo = a + ((b - c)) + d; /* c must be subtracted from b, but otherwise this may be rearranged. */ Does this satisfy the requirements of the problem and also meet the needs of both numerical analysts and bit-twiddlers? Bill Smith wsmith@cs.uiuc.edu uiucdcs!wsmith
english@panarea.usc.edu (Joe English) (09/27/88)
In article <4700017@m.cs.uiuc.edu> wsmith@m.cs.uiuc.edu writes: > >I realize this topic has been beat to death and its probably too late >for the ANSI C committee to do anything about it, but here's a suggestion >anyway. > >The problem: How can C know when it is safe to rearrange expressions, > especially floating point expressions. > Didn't I read somewhere that the unary + operator can be used to suppress rearrangement of the enclosed expression? (as in +(a + b - c + d) ) This could be ANSI, or it could just be another Borland or gcc extension that I remember seeing. Which reminds me: are there any good books out yet giving a complete description of the dpANS? I wish K&R had waited another coupla months before they published Edition 2... /|/| -----< | | Joe English O \|\| ARPA: english%lipari@oberon.usc.edu
rob@kaa.eng.ohio-state.edu (Rob Carriere) (09/27/88)
In article <4700017@m.cs.uiuc.edu> wsmith@m.cs.uiuc.edu writes: >[...] >The problem: How can C know when it is safe to rearrange expressions, > especially floating point expressions. > >A proposed solution: > Expressions enclosed in double parentheses may not be rearranged, > all other expressions may be rearranged in "semantically valid" > ways. >[examples] This could lead to trouble with macro expansions. Otherwise it looks fine to me at least. Another way of doing this might be a pair of pragma's, one to say ``hands off this one'', and one to say ``you can totally optimize this''. I know it is dubious whether the current standard allows such pragmae (sp :-), but the original poster was talking about future efforts anyway. Rob Carriere
henry@utzoo.uucp (Henry Spencer) (09/28/88)
In article <4700017@m.cs.uiuc.edu> wsmith@m.cs.uiuc.edu writes: >I realize this topic has been beat to death and its probably too late >for the ANSI C committee to do anything about it... Much too late, given that the matter has already been addressed: expressions must be evaluated as given unless rearrangement would yield the same results. ("The same" in a programming sense, not just in a mathematical sense.) >A proposed solution: > Expressions enclosed in double parentheses may not be rearranged, > all other expressions may be rearranged in "semantically valid" ways. Doesn't work too well. The trouble is that extra parentheses are common as a result of macro expansion. To do this sort of thing well, you really need another *kind* of parentheses. Such schemes have been proposed, but did not get accepted. -- NASA is into artificial | Henry Spencer at U of Toronto Zoology stupidity. - Jerry Pournelle | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
henry@utzoo.uucp (Henry Spencer) (09/29/88)
In article <12393@oberon.USC.EDU> english@panarea.usc.edu (Joe English) writes: >Didn't I read somewhere that the unary + operator can be used to >suppress rearrangement of the enclosed expression? ... In some intermediate drafts of X3J11 C it could; not any more. (One of the perils of knowing about non-final drafts is that some of what you know eventually turns out to be wrong.) >Which reminds me: are there any good books out yet giving a complete >description of the dpANS? ... Not unless you count K&R2. How can there be? The dpANS is still changing! (There is a hope that it won't change much more, but that is a hope only.) Once there is a real, true ANSI C standard, you can expect a flood of books about it. Until then, the closest you can come is the latest X3J11 draft (which isn't fun reading, let me tell you...). -- The meek can have the Earth; | Henry Spencer at U of Toronto Zoology the rest of us have other plans.|uunet!attcan!utzoo!henry henry@zoo.toronto.edu
gwyn@smoke.ARPA (Doug Gwyn ) (10/03/88)
In article <4700017@m.cs.uiuc.edu> wsmith@m.cs.uiuc.edu writes: >The problem: How can C know when it is safe to rearrange expressions, > especially floating point expressions. You seem to be assuming that it is obvious what constitutes a "rearranged" expression. That is not at all obvious. The current proposed C standard spells out what arithmetic order constraints must be obeyed by a conforming implementation, and it does appear to have adequately addressed this aspect of numerical programming needs.
gwyn@smoke.ARPA (Doug Gwyn ) (10/03/88)
In article <12393@oberon.USC.EDU> english@panarea.usc.edu (Joe English) writes: >Didn't I read somewhere that the unary + operator can be used to >suppress rearrangement of the enclosed expression? Unary plus was going to have this property, but when the decision was made to honor parenthesis grouping, that aspect of unary plus was rescinded. >Which reminds me: are there any good books out yet giving a complete >description of the dpANS? I wish K&R had waited another coupla months >before they published Edition 2... K&R/2 is close enough to the finally approved ANS to serve as a guide. Plum Hall has a book entitled something like "Notes on the Draft C Standard" by Tom Plum that covers the things you need to know. I don't recall whether it includes "noalias" but be advised that "noalias" did not survive to reach the final standard.