const, volatile, etc [was Re: #defines with parameters]
david wald
wald-david at CS.YALE.EDU
Thu Dec 15 08:18:29 AEST 1988
In article <377 at aber-cs.UUCP> pcg at 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 at yale.UUCP
waldave at yalevm.bitnet
============================================================================
More information about the Comp.lang.c
mailing list