Path: utzoo!attcan!uunet!yale!wald-david
From: wald-david@CS.YALE.EDU (david wald)
Newsgroups: comp.lang.c
Subject: Re: const, volatile, etc [was Re: #defines with parameters]
Message-ID: <45697@yale-celray.yale.UUCP>
Date: 14 Dec 88 22:18:29 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>
Sender: root@yale.UUCP
Reply-To: wald-david@CS.YALE.EDU (david wald)
Organization: Yale University Computer Science Dept, New Haven CT  06520-2158
Lines: 77

In article <377@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
>You mean that nobody explicitly stated the obvious rule that an optimizer
>shall not turn a correct program into in incorrect one? Of course! As I said,
>C was not designed for optimizing compilers; it was designed as a low level
>language, and the very idea that an optimizer could do nasty things behind
>the programmer's back was unthinkable.

and:

>Again, it has never been a usual rule that an optimizer is allowed to turn a
>correct program into an incorrect one. If an existing implementation does it,
>it is buggy. This volatile argument is as old as programming; every PL/1
>programmer knows that many a compiler will generate buggy code when the
>optimizer is let loose on code with exception handlers.

You twice invoke this rule that "an optimizer shall not turn a correct
program into an incorrect one," and I have yet to see someone hint that
this statement is false.  But I have still not seen any supporting
references for your view of what constitutes "correctness." Your view
seems to be that all variables are volatile unless declared register,
and you assert that this was the intention of the "register" keyword.

K&R's statement of the meaning of register is

   "A register declaration advises the compiler that the variable in
   question will be heavily used.  When possible, register variables
   are placed in machine registers, which may result in smaller and
   faster programs." [4.7]

Clearly, the intent is to allow the optimization of placing the most
heavily used variables in processor registers.  Similarly,

    A register declaration is best thought of as an auto declaration,
    together with a hint to the compiler that the variables declared
    will be heavily used.  Only the first few such declarations are
    effective.  Moreover, only variables of certain types will be
    stored in registers....[Appendix A, 8.1]


As for your suggested use of "register," (i.e., saying "not volatile"),
I fail to see how this purpose is served if "only the first few such
declarations are effective."

Further, the semantic distinctions you refer to between "register" and
"auto" variables merely reflect the realities of registers on many
architectures:

   "In practice, there are some restrictions on register variables,
   reflecting the realities of underlying hardware.  Only a few
   variables in each function may be kept in registers, and only
   certain types are allowed.  The word register is ignored for
   excess or disallowed declarations.  And it is not possible to
   take the address of a register variable....  The specific
   restirictions vary from machine to machine....[4.7]

In this context, the rule about taking the address of a register
variable appears simply as an afterthought, due to the PDP-11
architecture, rather than an essential aspect of the semantics.

Finally, with regard to your comments about the place of optimizing
compilers in C:

   "Smaller, faster programs can be expected if register declarations
   are used appropriately, but future improvements in code
   generation may render them unnecessary" [Appendix A, 8.1]

Thus anticipating the future obsolesence of "register" as optimizers
improve.

If K&R is not a good sign of the original intent of a keyword, what are
you using as your authority?


============================================================================
David Wald                                              wald-david@yale.UUCP
						       waldave@yalevm.bitnet
============================================================================