在C中，register存储限定符是hint对于实现来说，应该尽可能快地访问此类标识符（例如，存储在 CPU 寄存器中）。
§6.7.1具有存储类说明符寄存器的对象的标识符声明表明对该对象的访问应尽可能快。这些建议的有效程度取决于实施情况。
and
§6.7.3限制限定符的预期用途（如寄存器存储
类）是为了促进优化[...]
但是，我听说过一些实现（特别是在嵌入式系统中），其中register有一个更强烈的含义：它是command编译器应将合格标识符放入寄存器中。
So, 是一个实现allowed遵循该行为并因此被视为符合标准？什么会允许这样做？
我提出这个问题是因为我发现有义务将该对象放入寄存器中不再是建议，正如标准所规定的那样；换句话说，它们是冲突的。
正如您所说，该标准说“此类建议的有效程度是由实施定义的”。
这给了实施者自由的范围，可以做任何事情，从忽略建议到竭尽全力去实施它。选择接受的实现register要求使用寄存器的说明符当然并不与标准相矛盾，而且无论说明符如何，只对寄存器放置做出自己的决定的实现也不矛盾。
实现不应该做的一件事是拒绝编译程序，因为它需要溢出register——至少，达到§5.2.4.1中规定的限制翻译限制-- 但没有什么可以阻止编译器发出警告。 （没有什么可以阻止编译器发出有关任何内容的警告；编译器通常会警告被认为是危险的完全合法的构造。）
Edit:重读 5.2.4.1，在我看来，一个实现实际上可能拒绝编译它认为有太多的程序register说明符，因为 Limits 子句仅将实现绑定为能够翻译和执行“一个程序”，其中包括（例如）“在一个块中声明了块作用域的 511 个标识符”，而不是任何执行此操作的程序。据我所知，编译器可以坚持认为达到该限制的“至少一个程序”没有任何register规格。
Note:并非所有 CPU 都具有一般意义上的寄存器，但该标准实际上并未提及任何有关硬件的内容。它只是说register说明符传达了程序员希望“尽可能快地访问对象”的愿望。此外，编译器尝试满足该愿望实际上并不需要优化对对象的访问；而是需要优化对对象的访问。尝试优化失败并不违反优化标准。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
