Драйвер Atmel и случай использования защитного барьера GCC

Question

Пока я смотрел некоторые версии драйверов от Atmel Software Framework, я столкнулся с несколькими случаями, когда они использовали барьер памяти.

определение Барьерный:

#define barrier()  asm volatile("" ::: "memory") 

Пример 1 (вспомогательные функции прерывания):

static inline void cpu_irq_restore(irqflags_t flags) 
{ 
    barrier(); 
    SREG = flags; 
} 

Этот барьер имеет смысл для меня. Так как cpu_irq_restore получает неявное вложение, он предотвращает перераспределение критического (с точки зрения порядка выполнения) переназначения SREG из фактического местоположения вызова функции.

В качестве примечания: SREG определяется как специальной функции регистра определяется как:

#define _SFR_MEM8(mem_addr) (*(volatile uint8_t *)(mem_addr)) 

Пример 2 (от драйвера AVR TWI):

static inline status_code_t twim_release(void) 
{ 
    /* First wait for the driver event handler to indicate something 
    * other than a transfer in-progress, then test the bus interface 
    * for an Idle bus state. 
    */ 
    while (OPERATION_IN_PROGRESS == transfer.status); 

    while (! twim_idle(transfer.bus)) { barrier(); } 

    status_code_t const status = transfer.status; 

    transfer.locked = false; 

    return status; 
} 

В этом втором случае варианта использования, однако , мне непонятно. Каким образом компилятор мог бы оптимизировать этот код, чтобы он разрывался без barrier()?

Я думаю, что понимаю основные соображения по поводу барьеров программной памяти после чтения this article.

Не могли бы вы объяснить причину использования барьера во втором примере?

Answer 1

Функция twim_idle, вероятно, что-то вроде считывает значение специального регистра функций TWI и проверяет некоторые бит в нем. Без барьера опасность состоит в том, что компилятор может оптимизировать чтение этого регистра и переместить его до второго цикла. Итак, что второй цикл будет вести себя так:

bool idle = twim_idle(transfer.bus); 
while (!idle); 

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

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