Может ли реализация рассматривать подсказки как фактические утверждения?

В C определитель хранилища register является подсказкой для реализации, по которой такой идентификатор должен быть доступен как можно быстрее (например, хранится в регистре CPU).

§6.7.1 Объявление идентификатора для объекта с регистром спецификатора classа хранения предполагает, что доступ к объекту должен быть как можно быстрее. Степень, в которой такие предложения эффективны, определяется реализацией.

а также

§6.7.3 Предполагаемое использование ограничителя (например, class хранения регистра) заключается в продвижении оптимизации […]

Однако я слышал о реализациях (особенно во встроенных системах), где register имеет более сильное значение: это команда, и компилятор помещает квалифицированный идентификатор в регистр.

Итак, реализована ли реализация этого поведения и, следовательно, считается стандартно-совместимой? Что бы это позволило?

Я поднимаю этот вопрос, потому что считаю, что обязательство поместить этот объект в регистр больше не является предложением, как это предусмотрено Стандартом; Другими словами, они конфликтуют.

Как вы говорите, в стандарте говорится: «Степень эффективности таких предложений зависит от реализации».

Это дает свободному диапазону реализации, чтобы что-либо сделать, игнорируя предложение о перемещении небес и земли для его реализации. Реализация, которая решает принять спецификатор register требующий использования регистра, безусловно, не противоречит стандарту, а также не является реализацией, которая только принимает собственные решения о размещении регистра независимо от спецификаторов.

Единственное, что реализация не должна делать, это отказаться от компиляции программы, потому что ей нужно будет пропустить register – по крайней мере, до пределов, указанных в п. 5.2.4.1. Ограничения перевода – но ничто не мешает компилятору выдавать предупреждение , (Ничто не мешает компилятору выдавать предупреждения о чем-либо, поэтому компиляторы часто предупреждают о совершенно законных конструкциях, которые считаются опасными).

Edit: Перечитывая 5.2.4.1, мне кажется, что реализация может фактически отказаться от компиляции программы, которая, как он считает, имеет слишком много спецификаторов register , поскольку предложение ограничений только связывает реализацию, чтобы иметь возможность переводить и выполнять «одну программу», который включает (например) «511 идентификаторов с областью блока, объявленной в одном блоке», а не любую программу, которая делает это. Итак, насколько я вижу, компилятор может настаивать на том, что «по крайней мере одна программа», которая попадает в этот предел, не имеет каких-либо спецификаций register .

Примечание. Не все процессоры имеют регистры в общем смысле этого слова, но стандарт ничего не говорит об аппаратном обеспечении. Он просто говорит, что спецификатор register связывает желание программиста сделать «доступ к объекту как можно быстрее». Более того, попытка компилятора удовлетворить это желание фактически не должна оптимизировать доступ к объекту; это не является нарушением стандарта для попыток оптимизации не оптимизировать.

Это разрешено делать до тех пор, пока оно не предотвращает компрометацию или изменение хорошо сформированных программ или поведение наблюдаемого поведения, как указано в стандарте.

Стандарт уже запрещает принимать адрес или выравнивание объекта, объявленного с помощью спецификатора register , так что эта часть не будет проблемой. Более сложный случай был бы, если вы объявите больше объектов с register чем есть доступные регистры. Если реализация по-прежнему не позволяет разливать объекты register (временно перемещая значения из регистров, например, в стек и обратно), тогда это будет случай, когда реализация не сможет скомпилировать программу, которая соответствует стандарту.