Date: Mon, 15 Mar 1999 21:27:52 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Andrew Reilly" <andrew@lake.com.au> Cc: andrew@lake.com.au, sjr@home.net, freebsd-hackers@FreeBSD.ORG Subject: Re: Use of "register" in code Message-ID: <199903160527.VAA06458@apollo.backplane.com> References: <19990316051721.40605.qmail@areilly.bpc-users.org>
index | next in thread | previous in thread | raw e-mail
:
:> Secondly, all modern C
:> compilers that I know about, including one I wrote years ago, can
:> trivially detect the stack locality of a variable and put it in a
:> register as part of standard optimizations. It's one of the *easiest*
:> optimizations a C compiler can do, in fact.
:
:Naturally. You'd hope so. But if your routine takes the address of
:_any_ auto variable, and hands that to a function or writes to some
:run-time computed index of it, then the compiler has to assume that any
:of the other auto variables in the stack frame could have been modified,
:and so it has to re-fetch any auto variables after such a write. It
:doesn't have to do that for register variables.
No, only the auto variable that you took the address of. If an array or
structure, the entire array or structure is put on a real stack. Other
auto variables are left uneffected.
While it is true that in the olden days people would take the address of
one auto variable in order to reference another by indexing it, in modern
days the alignment and reordering optimizations made by compilers pretty
much nixes such uses on auto variables. Such uses are considered
'bad code' these days, so compilers have no problem assuming that other
auto variables can remain optimized.
:> Some compilers will add a little weight to the potential optimization
:> if you use the 'register' keyword, but modern compilers tend to do a
:> better job without the manual weighting.
:
:One old compiler I've used won't ever put a variable into a register
:unless you tell it to, but neither example has a bearing on whether
:"register" has a specific meaning wrt aliasing.
:
:The closest reference I've found on the net is http://www.lysator.liu.se/c/rat/c5.html#3-5
:3.5.1, which says:
:
:"
:Because the address of a register variable cannot be taken, objects of storage
:class register effectively exist in a space distinct from other objects.
:(Functions occupy yet a third address space). This makes them candidates for
:optimal placement, the usual reason for declaring registers, but it also makes
:them candidates for more aggressive optimization.
:
:The practice of representing register variables as wider types (as when register
:char is quietly changed to register int) is no longer acceptable.
:"
:
:which seems to back up my assertion.
:
:In any case, what does taking the register keyword out buy you?
:
:--
:Andrew
A lot of the older kernel code used 'register' to optimize for a
specific processor or compiler - usually the VAX. As kernel code started
to migrate to other processors, such optimizations have historically
produced *WORSE* code on the other processors. So people stopped using
'register' and started expecting compilers to optimize it themselves.
For example, on an intel processor with only a handful of registers,
declaring 8 auto's as register and actually expecting the compiler to
do something with that is counter productive.
These days, 'register' is considered more of a nuisance that obscures the
readability of the code then anything else. Hence people have started
ripping out the keyword from code. The only reason it hasn't been ripped
out more quickly is because it adds garbage to the CVS diff's which
complicates the lives of people who try to sync code up ( such as device
drivers ) across platforms. This is why you do not see anyone doing any
wholesale removal of 'register' from existing source trees. It is removed
more slowly, as people work on other things in the kernel.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903160527.VAA06458>