Управление шириной доступа для чтения и записи в отображенные в память регистры в C

Ваши проблемы покрываются квалификатором volatile.

6.7.3 / 6 «Квалификаторы типа» говорят:

Объект, имеющий тип с изменяемым типом, может быть изменен способами, неизвестными реализации, или иметь другие неизвестные побочные эффекты. Следовательно, любое выражение, относящееся к такому объекту, должно оцениваться строго в соответствии с правилами абстрактной машины, как описано в 5.1.2.3. Более того, в каждой точке последовательности последнее сохраненное в объекте значение должно соответствовать значению, предписанному абстрактной машиной, за исключением случаев, когда оно изменено неизвестными факторами, упомянутыми ранее. То, что составляет доступ к объекту, который имеет тип с изменяемым типом, определяется реализацией.

5.1.2.3 «Выполнение программы» говорит (среди прочего):

В абстрактной машине все выражения оцениваются в соответствии с семантикой.

За этим следует предложение, которое обычно называют правилом «как если бы», которое позволяет реализации не следовать семантике абстрактной машины, если конечный результат тот же:

Фактической реализации не требуется оценивать часть выражения, если она может сделать вывод, что его значение не используется и что никаких побочных эффектов не возникает (включая любые, вызванные вызовом функции или доступом к изменчивому объекту).

Но в 6.7.3 / 6, по сути, говорится, что к типам с изменяемым атрибутом, используемым в выражении, не может применяться правило «как если бы» - необходимо соблюдать фактическую семантику абстрактной машины. Следовательно, если указатель на энергозависимый 32-битный тип разыменован, то полное 32-битное значение должно быть прочитано или записано (в зависимости от операции).

ЕДИНСТВЕННЫЙ способ ГАРАНТИИ, что компилятор будет делать правильные вещи, - это написать свои процедуры загрузки и сохранения на ассемблере и вызвать их из C. 100% компиляторов, которые я использовал на протяжении многих лет, могут и будут ошибаться (включая GCC) .

Иногда оптимизатор получает вас, например, вы хотите сохранить некоторую константу, которая отображается компилятору как небольшое число, скажем, 0x10, в 32-битный регистр, это то, что вы конкретно просили, и то, что я наблюдал, в противном случае хорошие компиляторы пытаются сделать . Некоторые компиляторы решат, что дешевле сделать 8-битную запись вместо 32-битной, и изменят инструкцию. Цели с переменной длиной инструкций усугубят ситуацию, поскольку компилятор пытается сэкономить место в программе, а не только циклы памяти на том, что, по его мнению, является шиной. (xor ax, ax вместо mov eax, например 0)

А с чем-то, что постоянно развивается, например, gcc, код, который работает сегодня, не имеет никаких гарантий работы завтра (вы даже не можете скомпилировать некоторые версии gcc с текущей версией gcc). Точно так же код, который работает с компилятором на вашем столе, может не работать универсально для других.

Избавьтесь от догадок и экспериментов и создайте функции загрузки и сохранения.

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

Ну, вообще говоря, я бы не ожидал, что он оптимизирует байты старшего разряда, если у вас есть регистр, набранный как 32-битный изменчивый. Из-за использования ключевого слова volatile компилятор не может предположить, что значения в старших байтах равны 0x00. Таким образом, он должен записывать полные 32 бита, даже если вы используете только 8-битное буквальное значение. У меня никогда не возникало проблем с этим на процессорах 0x86, Ti или других встроенных процессорах. Обычно достаточно ключевого слова volatile. Единственный раз, когда все становится немного странно, - это если процессор изначально не поддерживает размер слова, который вы пытаетесь записать, но это не должно быть проблемой для 0x86 для 32-битного числа.

Хотя компилятор мог бы сгенерировать поток инструкций, который использовал бы 4-битную запись, это не было бы оптимизацией ни процессорного времени, ни пространства инструкций за одну 32-битную запись.

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

volatile uint32_t* p_reg = 0xCAFE0000;
const uint32_t value = 0x01;  // This trick tells the compiler the constant is 32 bits.
*p_reg |= value;

Вам нужно будет прочитать порт как 32-битное значение, изменить значение, а затем записать обратно:

uint32_t reg_value = *p_reg;
reg_value |= 0x01;
*p_reg = reg_value;

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

В зависимости от того, каким типом регистра вы манипулируете, он может измениться на этапе изменения, и тогда вы вернете ложное значение.

Я бы порекомендовал, поскольку dwelch предлагает написать свою собственную функцию чтения-изменения-записи в сборке, если это критично.

Я никогда не слышал о компиляторе, который оптимизирует тип (выполняет преобразование типа с целью оптимизации). Если он объявлен как int32, он всегда будет int32 и всегда будет выровнен прямо в памяти. Проверьте документацию к вашему компилятору, чтобы увидеть, как работают различные оптимизации.

Думаю, я знаю, откуда взялось ваше беспокойство, структуры. Конструкции обычно набиваются до оптимального выравнивания. Вот почему вам нужно обернуть их #pragma pack (), чтобы они выровнялись по байтам.

Вы можете выполнить сборку всего за один шаг, и тогда вы увидите, как компилятор транслировал ваш код. Я почти уверен, что это не изменило ваш типаж.