Date: Thu, 18 Mar 1999 01:12:00 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dyson@iquest.net Cc: imp@harmony.village.org, alk@pobox.com, chat@FreeBSD.ORG Subject: Re: Use of "register" in code Message-ID: <199903180112.SAA23802@usr01.primenet.com> In-Reply-To: <199903170632.BAA03094@y.dyson.net> from "John S. Dyson" at Mar 17, 99 01:32:13 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > : Firstly, removing "register" declarations from a program can > > : cause correct code to become incorrect code. This is true, not only > > : of ANSI C, but of the GNU C 2 series compilers, as well as other > > : significant current compilers, such as Microsoft and SunPro. > > > > How? I can think of no way that removing the register part of a > > declaration can cause this (eg register int foo -> int foo). > > It is possible because of setjmp type things. However, the use of > register can be replaced by "auto?" Actually, I believe the issue is the change in semantics about the assumptions of the types of optimizations that are allowed under ANSI. The removal of the "register" qualifier in the code in question is freeing up a register for use in promotion of non-register variables to registers during loop unrolling. ANSI broke a lot of functioning code through the requirement for the use of the qualifier "volatile". Use of the qualifier "auto" is supposed to force a stack rather than a register allocation; however, it is still permissable for the compiler to optimize this into a register, for example, when it is doing loop unrolling, as well as several other circumstances (mostly short function for which peeophole optimization can cover the entire function). You can see this behaviour in detail by replacing loop constructs with if/goto constructs, which will "correct" the code in question by removing the unrolling hints to the optimizer. I personally would have been happy if the committe had merely specified that behaviour of an implementation lacking prototypes is implementation defined by the linker and object file formats (and left prototypes out, making IBM and Microsoft resolve the near/far problem in their linkers), and allowing the declaration of signal and interrupt handler *functions*, such that all external references were implicitly volatile, and nothing else was. They could have added a qualifier (nonvolatile) to apply to things that you didn't mid them doing loop unrolling optimizations on. Oh well. We're Microsft's bitch now... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903180112.SAA23802>