Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!haven!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: const, volatile, etc Message-ID: <9180@smoke.BRL.MIL> Date: 14 Dec 88 23:44:53 GMT References: <674@quintus.UUCP> <117@halcdc.UUCP> <468@auspex.UUCP> <9016@smoke.BRL.MIL> <10919@ulysses.homer.nj.att.com> <1450@micomvax.UUCP> <369@aber-cs.UUCP> <9143@smoke.BRL.MIL> <377@aber-cs.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 136 In article <377@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >[Gwyn thinks:] if you want signed characters, the only way is to add >a signed keyword, if you want efficient code the only way is a complex >optimizer that relies on volatile. You really have not been listening at all, have you? X3J11 operates under certain rules and constraints to accomplish a particular task having particular scope. "signed" was not invented by X3J11; it was introduced in several commercial C compilers many years ago as one way -- the most obvious of several possibilities -- to provide the C programmer some way to obtain guaranteed signedness for char-sized objects. X3J11 had to determine first whether this was a problem in the base document (K&R 1st Ed. Appendix A) that needed fixing, and if so, how to fix it. They agreed with what appears to be your premise, that this lack in C's integral types needed to be provided in the new standard. Then the question became, how best to do that. In such cases, whenever there was widespread existing practice, unless it had some obvious problem it served as a guide for the standard. In cases where existing practice was ambiguous (multiple different solutions had been devised), X3J11 was at liberty to choose one over the other. The ONLY widespread existing practice for obtaining guaranteed signed char-sized objects in C was use of the "signed" specifier; since the only possible technical problem with adopting this (conflict of a new keyword with existing use as an identifier) was judged to not be likely to cause much practical problem, it was adopted. X3J11 could hardly have done otherwise; ignoring existing practice would run counter to the committee's charter. >Again, it has never been a usual rule that an optimizer is allowed to turn a >correct program into an incorrect one. The proposed standard is quite specific about the virtual machine semantics that the C implementation must correctly support. >But in any case I still must volatilize all other variables, otherwise the >compiler will do funny things behind my back. Wrong!!! >Volatile encourages people to think that a complex optimizer will clean up >their sloppy C code. Too bad that the cleanup cannot be as good as >competently written code, ... You don't seem to appreciate what modern optimization technology can accomplish. A good optimizer can significantly speed up well-written C code. In fact it often cannot do very much for sloppy code, such as code that follows your recommendation of declaring all variables volatile (thereby imposing a constraint that is totally unwarranted under nearly all circumstances). > The use of "volatile" does not require much analysis. If you were paying > attention, I already explained in response to Griff Smith the cases where > you need to use it. >My dear Doug Gwin, rest assured that your paternalistic innuendo is not >necessary. I know perfectly well the rationale for "volatile" (enable >optimizations where side effects may occur); I dispute that the only solution >to the problem is "volatile", as I dispute the rationale itself. My name is Gwyn (which as you should know is Welsh), not Gwin! Again you attempt to put false words in others' mouths. Please cease these sleazy debating ploys, as I will not let you get away with them and I'm sure others are also annoyed by them. I did NOT say that "volatile" was the only solution to a particular problem. However, the solution you suggest (in effect, requiring what is now known as the volatile attribute for ALL data) is not acceptable to a large fraction of the current C marketplace. The intention is to have a standard that will actually be used, not to make it unacceptable to a large segment of the C user population. The determination was made that as high a degree of optimization as possible should be permitted while remaining consistent with a reasonable C virtual machine model. Note that "noalias" arose out of the insistence of a sufficient number of committee members on this principle; the attempt to have "pointer to const" function parameters permit optimization that ignored possible aliasing was NOT considered reasonable. We deliberately prohibited the extra, sometimes quite significant, optimizations that this would have permitted. The "optimizer people" on the committee settled for having explicit programmer use of "noalias" required to permit such optimization. ("noalias" has unfortunately been dropped from the final standard, so this optimization is completely disallowed for conforming programs compiled by conforming implementations.) So, as you should be able to see from this example, X3J11 did NOT wish to trade off reasonable program semantics for the sake of better optimization. The thing you don't seem to agree with is, that we didn't think that the volatile property should be part of the reasonable C virtual machine model; in fact quite the contrary -- volatile behavior is quite UNreasaonable, and it is appropriate to require that the programmer explicitly flag those few instances where it really is expected. >I would also like to emphasize that the real big problem will be multi >threaded C code, not signal handlers or device drivers. As any Ada programmer >knows, if you use tasking and fail to stick pragmas volatile/shared wherever >they are needed, maybe in dozens of modules, and that may be a lot of places, >you get into BIG trouble. But the C standard does not attempt to define semantics for multitasking or multiple threads. This too was deliberate. If someone (for example, IEEE 1003) wants to establish additional C constraints for such an environment, they are free to do so. For example, it could be required that the volatile attribute automatically apply to every data object in such an environment. However, I guarantee that you have much worse problems than that to contend with in using any flavor of C in such an environment. > In pre-ANSI C the same problem existed, but there was no standard > solution for it. >The problem did not exist, because it was unthinkable that the compiler would >do funny things behind your back! Wrong. Even Ritchie's PDP-11 C compiler would occasionally do things when the peephole optimizer was enabled that caused trouble in device drivers, etc. This was not generally considered a bug; one merely revised the code to outwit the optimizer or else turned off the optimizer. Many of these problems could have been circumvented through the use of "volatile", if it had existed. I explained elsewhere about a horrible kludge that some PCCs had to selectively disable certain optimizations in a portion of virtual address space; again "volatile" could have rendered that unnecessary. > I would like to be able (maybe in C++ ?) to declare a procedure as > "register", to signify that the values it returns only depend on the > arguments and not on any globals, and thus it will always return the same > values given the same arguments. This is known as a "pure" function. It has been suggested before, but no existing C practice seems to be available to use to judge its merit. P.S. It's about time for another reminder that I'm not speaking officially for X3J11 here, although at least I WAS involved in the deliberations leading to the final form of the proposed standard, so there is SOME chance that I'm in a position to appreciate the trade-offs and decision criteria.