问题
In C, the register storage qualifier is an hint to the implementation that such identifier should be accessed as fast as possible (e.g. stored in a CPU register).
§6.7.1 A declaration of an identifier for an object with storage-class specifier register suggests that access to the object be as fast as possible. The extent to which such suggestions are effective is implementation-defined.
and
§6.7.3 The intended use of the restrict qualifier (like the register storage class) is to promote optimization [...]
However, I've heard about implementations (specifically found in embedded systems) where register has a stronger meaning: it is a command and the compiler shall place the qualified identifier in a register.
So, is an implementation allowed to follow that behavior and thus considered as standard-compliant? What would permit that?
I'm raising this question because I find that being obligated to place that object in a register is no longer suggestion, as mandated by the Standard; they conflict, in other words.
回答1:
As you say, the standard says "The extent to which such suggestions are effective is implementation-defined."
That gives the implementation free range to do anything from ignoring the suggestion to moving heaven and earth to implement it. An implementation which chooses to accept the register specifier as requiring the use of a register is certainly not contradicting the standard, and nor is an implementation which just makes its own decisions about register placements regardless of specifiers.
The one thing the implementation should not do is refuse to compile a program because it would need to spill a register -- at least, up to the limits specified in §5.2.4.1 Translation limits -- but nothing stops the compiler from issuing a warning. (Nothing stops the compiler from issuing warnings about anything; it's common for compilers to warn about perfectly legal constructs which are considered dangerous.)
Edit: Rereading 5.2.4.1, it seems to me that an implementation could actually refuse to compile a program which it considers to have too many register specifiers, since the limits clause only binds the implementation to be able to translate and execute "one program" which includes (for example) "511 identifiers with block scope declared in one block", and not any program which does so. So as far as I can see, the compiler could insist that the "at least one program" which hits that limit not have any register specifications.
Note: Not all CPUs have registers in the common sense of the word, but the standard does not actually say anything about hardware. It simply says that the register specifier communicates the programmer's desire to make "access to the object be as fast as possible". Moreover, the compiler's attempt to satisfy that desire does not actually have to optimize access to the object; it's not a violation of the standard for optimization attempts to fail to optimize.
回答2:
It is allowed to do it as long as it doesn't prevent well-formed programs from compiling or affects the observed behavior as specified in the standard in any way.
The standard already forbids taking the address or alignment of an object declared with the register specifier, so that part wouldn't be a problem. A trickier case would be if you declare more objects with register than there are available registers. Unless the implementation still allows spilling for register objects (temporarily moving values from registers to e.g. the stack, and back), then this would be a case where the implementation would fail to compile a program that's conformant according to the standard.
来源：https://stackoverflow.com/questions/28928674/can-an-implementation-consider-hints-as-actual-statements