实现可以将提示视为实际语句吗？
在C中， register存储限定符是对实现的暗示 ，应尽可能快地访问此标识符（例如，存储在CPU寄存器中）。
§6.7.1具有存储类说明符寄存器的对象的标识符声明建议尽可能快地访问对象。 这些建议有效的程度是实施定义的。
和
§6.7.3限制限定符的预期用途（如寄存器存储类）是为了促进优化[…]
但是，我听说过register具有更强意义的实现（特别是嵌入式系统中的实现）：它是一个命令 ，编译器应将限定标识符放在寄存器中。
那么， 是否允许实现遵循该行为并因此被视为符合标准？ 什么会允许？
我提出这个问题是因为我发现有必要将该物品放在登记册中，这不再是标准规定的建议; 换句话说，他们发生冲突。
如你所说，标准说“这些建议有效的程度是实施定义的”。
这使得实施自由范围可以做任何事情，从忽视建议到移动天地来实现它。 选择接受register指定符要求使用寄存器的实现当然不会与标准相矛盾，并且也不是一种只关于寄存器放置而不管指定符做出自己决定的实现。
实现不应该做的一件事是拒绝编译程序，因为它需要溢出register – 至少，达到§5.2.4.1 转换限制中指定的限制 – 但没有什么能阻止编译器发出警告。 （没有什么能阻止编译器发出关于任何事情的警告;编译器通常会警告那些被认为是危险的完全合法的结构。）
编辑：重读5.2.4.1，在我看来，一个实现实际上可以拒绝编译它认为有太多register说明符的程序，因为limits子句只绑定实现能够翻译和执行“一个程序”其中包括（例如）“在一个块中声明了块范围的511个标识符”，而不是任何这样做的程序。 因此，据我所知，编译器可能会坚持认为达到该限制的“至少一个程序”没有任何register规范。
注意：并非所有CPU都具有常识中的寄存器，但标准实际上并未说明硬件。 它只是说register说明符传达了程序员希望“尽可能快地访问对象”的愿望。 而且，编译器满足该需求的尝试实际上不必优化对象的访问; 它不会违反优化尝试未能优化的标准。
只要它不能阻止格式良好的程序以任何方式编译或影响标准中规定的观察到的行为，就可以这样做。
该标准已经禁止使用register说明符声明对象的地址或对齐，因此该部分不会成为问题。 如果你用register声明更多的对象而不是可用的寄存器，则会出现一个棘手的情况。 除非实现仍允许溢出register对象（暂时将值从寄存器移动到例如堆栈，然后返回），否则这将是实现无法编译符合标准的程序的情况。