Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!gatech!hubcap!ncrcae!ncrlnk!uunet!mcvax!ukc!dcl-cs!aber-cs!pcg
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: comp.lang.c
Subject: Re: const, volatile, etc [was Re: #defines with parameters]
Message-ID: <423@aber-cs.UUCP>
Date: 17 Dec 88 20:24:09 GMT
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Distribution: eunet,world
Organization: CS Dept., University College of Wales, Aberystwyth, UK
	(Disclaimer: my statements are purely personal)
Lines: 69

In article <45697@yale-celray.yale.UUCP> wald-david@CS.YALE.EDU (david wald)
writes:

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

	[  .... quotes from K&R that form the basis of MY argument .... ]

    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."

Hey, here we start to read different thing. I read that "effective" refers to
putting things into registers, not to the register keywords itself.  Even if
a register variable is not in fact held in a register (either because they
have all been allocated or the type is not suitable) this does not mean that
the register keyword is being ignored; on the contrary, you still cannot take
its address, for example. "register" contains a hint, and it is the hint that
may or not be effective, not the keyword.

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

Realities that are not "mere"; they are quite important to portability.

    In this context, the rule about taking the address of a register variable
    appears simply as an afterthought,

I think it is the very core of the beauty of the idea of "register".

    due to the PDP-11 architecture, rather than an essential aspect of the
    semantics.

I disagree. First, *many* architectures do disallow pointers to registers, so
it was natural to introduce the restriction for the sake of portability.
Second, there is also the (at least equally important) consequence you may be
missing that the rule has on opportunities to alias a register variable...

    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.

This is a good point. My answer to it is that Ritchie was too hopeful and
that when he foresaw the rise of optimizers he could not anticipate that
aggressive optimizers would turn out to be as a rule large, mostly slow,
quite often very buggy, and how effective "register" could be in achieving
efficient code at far lower expense.

Also, he might have missed the important point that an automated optimizer
can do reliably only a static analysis of frequency of use of variables,
without resorting to really amazing technology and/or information on the
expected distribution of input data.

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

A different, but still equally plausible, and maybe better, reading of K&R
than yours. And, maybe, some extra contextual information on how and why C
was designed and evolved in its early (pre BSD, pre SysV) history.
-- 
Piercarlo "Peter" Grandi			INET: pcg@cs.aber.ac.uk
Sw.Eng. Group, Dept. of Computer Science	UUCP: ...!mcvax!ukc!aber-cs!pcg
UCW, Penglais, Aberystwyth, WALES SY23 3BZ (UK)