Використання летючих у вбудованій C розробці

Я читав деякі статті та відповіді Stack Exchange про використання volatileключового слова, щоб запобігти застосуванню компілятора будь-яких оптимізацій щодо об'єктів, які можуть змінюватися способами, які неможливо визначити компілятором.

Якщо я читаю з АЦП (давайте назвемо змінну adcValue), і я оголошу цю змінну як глобальну, чи варто volatileв цьому випадку використовувати ключове слово ?

1. Без використання volatileключового слова

   // Includes
   #include "adcDriver.h"
   
   // Global variables
   uint16_t adcValue;
   
   // Some code
   void readFromADC(void)
   {
      adcValue = readADC();
   }
   

2. Використання volatileключового слова

   // Includes
   #include "adcDriver.h"
   
   // Global variables
   volatile uint16_t adcValue;
   
   // Some code
   void readFromADC(void)
   {
      adcValue = readADC();
   }
   

Я задаю це питання, тому що при налагодженні я не бачу різниці між обома підходами, хоча найкраща практика говорить про те, що в моєму випадку (глобальна змінна, яка змінюється безпосередньо з обладнання), то використання volatileобов'язкове.

Визначення volatile

volatileповідомляє компілятору, що значення змінної може змінюватися, не знаючи компілятора. Отже, компілятор не може припустити, що значення не змінилося лише тому, що програма C, здається, не змінила його.

З іншого боку, це означає, що значення змінної може знадобитися (читати) десь ще, про який компілятор не знає, отже, він повинен переконатися, що кожне присвоєння змінній насправді виконується як операція запису.

Використовуйте випадки

volatile потрібно, коли

• представляючи регістри апаратних засобів (або вбудований введення / виведення з картою пам'яті) як змінні - навіть якщо реєстр ніколи не буде прочитаний, компілятор не повинен просто пропускати операцію запису, думаючи: "Дурний програміст. Намагається зберігати значення в змінній, яку він / вона" він ніколи не прочитає назад. Він / вона навіть не помітить, якщо ми пропустимо написання ". І навпаки, навіть якщо програма ніколи не записує значення в змінну, її значення все одно може бути змінено апаратними засобами.
• обмін змінними між контекстами виконання (наприклад, ISR / основна програма) (див. відповідь @ kkramo)

Ефекти volatile

Коли оголошена змінна, volatileкомпілятор повинен переконатися, що кожне присвоєння їй у програмному коді відображається в дійсній операції запису і що кожне прочитане в програмному коді зчитує значення з (mmapped) пам'яті.

Для енергонезалежних змінних компілятор припускає, що він знає, чи / коли значення змінної змінюється, і може оптимізувати код різними способами.

Для одного, компілятор може зменшити кількість читання / запису в пам'яті, зберігаючи значення в регістрах процесора.

Приклад:

void uint8_t compute(uint8_t input) {
  uint8_t result = input + 2;
  result = result * 2;
  if ( result > 100 ) {
    result -= 100;
  }
  return result;
}

Тут компілятор, ймовірно, навіть не виділяє оперативну пам’ять для resultзмінної і ніколи не зберігатиме проміжні значення ніде, а не в регістрі процесора.

Якщо resultвін мінливий, кожне виникнення resultкоду С вимагає від компілятора здійснити доступ до оперативної пам'яті (або порту вводу / виводу), що призводить до зниження продуктивності.

По-друге, компілятор може переупорядкувати операції над енергонезалежними змінними для продуктивності та / або розміру коду. Простий приклад:

int a = 99;
int b = 1;
int c = 99;

можна було переупорядкувати

int a = 99;
int c = 99;
int b = 1;

що може зберегти інструкцію асемблера, оскільки значення 99не доведеться завантажувати двічі.

Якщо a, bі cбули нестійким компілятор повинен випромінювати інструкції , які привласнюють значення в точному порядку , як вони вказані в програмі.

Інший класичний приклад такий:

volatile uint8_t signal;

void waitForSignal() {
  while ( signal == 0 ) {
    // Do nothing.
  }
}

Якби в цьому випадку цього signalне було volatile, компілятор "подумає", що це while( signal == 0 )може бути нескінченна петля (тому що signalвона ніколи не буде змінена кодом всередині циклу ) і може генерувати еквівалент

void waitForSignal() {
  if ( signal != 0 ) {
    return; 
  } else {
    while(true) { // <-- Endless loop!
      // do nothing.
    }
  }
}

Розгляньте обробку volatileцінностей

Як зазначено вище, volatileзмінна може вводити штрафну ефективність, коли до неї звертаються частіше, ніж потрібно фактично. Щоб пом'якшити цю проблему, ви можете "не змінювати" значення шляхом присвоєння енергонезалежної змінної, наприклад

volatile uint32_t sysTickCount;

void doSysTick() {
  uint32_t ticks = sysTickCount; // A single read access to sysTickCount

  ticks = ticks + 1; 

  setLEDState( ticks < 500000L );

  if ( ticks >= 1000000L ) {
    ticks = 0;
  }
  sysTickCount = ticks; // A single write access to volatile sysTickCount
}

Це може бути особливо корисно в ISR, де ви хочете бути якомога скоріше не має доступу ті ж апаратні пам'яті або кілька разів , коли ви знаєте , що це не потрібно , тому що значення не зміниться , поки ваш ISR працює. Це часто, коли ISR є "виробником" значень для змінної, як sysTickCountу наведеному вище прикладі. На AVR було б особливо болісно мати функцію doSysTick()доступу до тих самих чотирьох байтів у пам'яті (чотири інструкції = 8 циклів процесора на доступ до sysTickCount) п'ять-шість разів, а не лише двічі, оскільки програміст знає, що значення не буде під час doSysTick()запуску його можна змінити з іншого коду .

Цим трюком ви по суті робите те саме, що робить компілятор для енергонезалежних змінних, тобто читаєте їх з пам'яті лише тоді, коли це потрібно, зберігайте значення в регістрі деякий час і записуйте в пам'ять лише тоді, коли це потрібно ; але цього разу ви знаєте краще, ніж компілятор, якщо / коли читання / запис має відбуватися, тому ви позбавите компілятора від цієї задачі з оптимізації та виконайте це самостійно.

Обмеження volatile

Неатомний доступ

volatileніяк НЕ забезпечує атомарний доступ до змінних з декількох слів. У цих випадках вам потрібно буде забезпечити взаємне виключення іншими способами, крім використання volatile. На AVR можна використовувати ATOMIC_BLOCKз <util/atomic.h>або прості cli(); ... sei();дзвінки. Відповідні макроси також виступають бар'єром пам'яті, що важливо, коли йдеться про порядок доступу:

Порядок виконання

volatileнакладає суворий порядок виконання лише стосовно інших змінних змінних. Це означає, що, наприклад

volatile int i;
volatile int j;
int a;

...

i = 1;
a = 99;
j = 2;

гарантовано спочатку призначити 1 до, iа потім призначити 2 j. Однак не гарантується, що aбуде призначено між ними; компілятор може виконувати це призначення до або після фрагмента коду, в основному в будь-який час до першого (видимого) зчитування a.

Якби не бар'єр пам'яті вищезгаданих макросів, компілятору було б дозволено перекладати

uint32_t x;

cli();
x = volatileVar;
sei();

до

x = volatileVar;
cli();
sei();

або

cli();
sei();
x = volatileVar;

(Для повноти я мушу сказати, що бар'єри пам’яті, як і ті, що маються на увазі макроси sei / cli, насправді можуть унеможливити використання volatile, якщо всі звернення закреслені цими бар'єрами.)

Мінливе ключове слово повідомляє компілятору, що доступ до змінної має ефект, що спостерігається. Це означає, що кожен раз, коли ваш вихідний код використовує змінну, компілятор ПОВИНЕН створити доступ до змінної. Будь то доступ для читання чи запису.

Ефект цього полягає в тому, що будь-яка зміна змінної за межами нормального потоку коду також буде спостерігатися кодом. Наприклад, якщо обробник переривання змінює значення. Або якщо змінна - це фактично якийсь апаратний реєстр, який змінюється самостійно.

Ця велика користь також є його недоліком. Кожен окремий доступ до змінної проходить через змінну, і значення ніколи не зберігається в регістрі для швидшого доступу протягом будь-якого часу. Це означає, що мінлива зміна буде повільною. Величини повільніші. Тож використовуйте летючі лише там, де це фактично необхідно.

У вашому випадку, наскільки ви показали код, глобальна змінна змінюється лише тоді, коли ви її оновите самостійно adcValue = readADC();. Компілятор знає, коли це станеться, і ніколи не буде містити значення adcValue в регістрі через щось, що може викликати readFromADC()функцію. Або будь-яку функцію, про яку вона не знає. Або все, що буде маніпулювати покажчиками, які можуть вказувати на adcValueтаке і таке. Справді немає необхідності в мінливості, оскільки змінна ніколи не змінюється непередбачуваними способами.

Основне використання енергонезалежного ключового слова у вбудованих додатках C - це маркування глобальної змінної, записаної в обробник переривання. Це, звичайно, необов'язково.

Без цього компілятор не може довести, що значення коли-небудь записується після ініціалізації, оскільки він не може довести, що обробник переривання коли-небудь викликається. Тому він вважає, що може оптимізувати змінну поза існуванням.

Існує два випадки, коли потрібно використовувати volatileвбудовані системи.

• При читанні з апаратного реєстру.

  Це означає, що зареєстрований на пам'ять регістр, сам апаратний периферійний апарат всередині MCU. Це, ймовірно, матиме якусь криптовану назву на кшталт "ADC0DR". Цей реєстр повинен бути визначений у коді С, або через якусь карту реєстру, яку постачає постачальник інструментів, або сам. Щоб зробити це самостійно, ви зробите (якщо припустити 16-бітний реєстр):

  #define ADC0DR (*(volatile uint16_t*)0x1234)

  де 0x1234 - адреса, де MCU відобразила реєстр. Оскільки volatileвін вже є частиною вищевказаного макросу, будь-який доступ до нього буде кваліфікований на непостійні. Тож цей код чудово:

  uint16_t adc_data;
  adc_data = ADC0DR;

• При спільному використанні змінної між ISR та пов'язаним кодом з використанням результату ISR.

  Якщо у вас є щось подібне:

  uint16_t adc_data = 0;
  
  void adc_stuff (void)
  {
    if(adc_data > 0)
    {
      do_stuff(adc_data);
    } 
  }
  
  interrupt void ADC0_interrupt (void)
  {
    adc_data = ADC0DR;
  }

  Тоді компілятор може подумати: "adc_data завжди 0, тому що він ніде не оновлюється. І що функція ADC0_interrupt () ніколи не викликається, тому змінну неможливо змінити". Компілятор зазвичай не усвідомлює, що переривання викликає апаратне, а не програмне забезпечення. Таким чином, компілятор вимикає і видаляє код, if(adc_data > 0){ do_stuff(adc_data); }оскільки вважає, що він ніколи не може бути правдою, викликаючи дуже дивний і важкий для налагодження помилку.

  Заявляючи adc_data volatile, компілятору заборонено робити такі припущення, і не дозволяється оптимізувати доступ до змінної.

Важливі примітки:

• ISR завжди декларується всередині драйвера обладнання. У цьому випадку ADR ISR повинен знаходитися всередині драйвера АЦП. Ніхто інший, крім водія, не повинен спілкуватися з ISR - все інше - це програвання спагетті.

• Під час написання C вся комунікація між ISR та фоновою програмою повинна бути захищена від перегонів. Завжди , кожного разу, не виняток. Розмір шини даних MCU не має значення, оскільки навіть якщо ви робите одну 8-бітну копію на C, мова не може гарантувати атомність операцій. Якщо ви не використовуєте функцію C11 _Atomic. Якщо ця функція недоступна, потрібно використовувати певний спосіб семафору або відключити переривання під час зчитування тощо. Інший варіант асемблера - інший варіант. volatileне гарантує атомність.

  Що може статися, це таке:
  -Завантажити значення зі стека в регістр
  -Постає перерва
  -Використовувати значення з регістра

  І тоді не має значення, чи частина "використання значення" сама по собі є однією інструкцією. На жаль, значна частина всіх програмістів із вбудованими системами про це не звертає уваги, ймовірно, що робить його найпоширенішою помилкою з вбудованими системами. Завжди переривчастий, важко спровокувати, важко знайти.

Приклад правильно написаного драйвера АЦП виглядатиме так (припустимо, що C11 _Atomicнедоступний):

adc.h

// adc.h
#ifndef ADC_H
#define ADC_H

/* misc init routines here */

uint16_t adc_get_val (void);

#endif

adc.c

// adc.c
#include "adc.h"

#define ADC0DR (*(volatile uint16_t*)0x1234)

static volatile bool semaphore = false;
static volatile uint16_t adc_val = 0;

uint16_t adc_get_val (void)
{
  uint16_t result;
  semaphore = true;
    result = adc_val;
  semaphore = false;
  return result;
}

interrupt void ADC0_interrupt (void)
{
  if(!semaphore)
  {
    adc_val = ADC0DR;
  }
}

• Цей код передбачає, що переривання не може бути перерване само по собі. У таких системах простий булевий може діяти як семафор, і він не повинен бути атомним, оскільки немає шкоди, якщо переривання відбудеться до встановлення булева. Недоліком вищезгаданого спрощеного методу є те, що він буде відкидати зчитування ADC, коли виникають умови перегонів, використовуючи замість цього попереднє значення. Цього можна також уникнути, але тоді код стає складнішим.

• Тут volatileзахищено від помилок оптимізації. Це не має нічого спільного з даними, що походять з апаратного реєстру, лише те, що дані спільно використовуються з ISR.

• staticзахищає від програмування спагетті та забруднення простору імен, роблячи змінну локальною для водія. (Це добре в одноядерних, однопотокових програмах, але не в багатопотокових.)

У фрагментах коду, представлених у запитанні, ще немає причини використовувати летючі. Неважливо, що значення adcValueпоходить від АЦП. А adcValueглобальність повинна adcValueвикликати у вас підозри щодо того, чи має бути мінливою, але це не є причиною сама по собі.

Бути глобальним є поняттям, оскільки це відкриває можливість adcValueотримати доступ до більш ніж одного програмного контексту. Контекст програми включає обробник переривання і завдання RTOS. Якщо глобальна змінна змінюється одним контекстом, то інші контексти програми не можуть припустити, що вони знають значення попереднього доступу. Кожен контекст повинен перечитувати значення змінної кожного разу, коли вони використовують його, оскільки це значення, можливо, було змінено в іншому контексті програми. Контекст програми не усвідомлюється, коли відбувається переривання або переключення завдань, тому він повинен припускати, що будь-які глобальні змінні, що використовуються у декількох контекстах, можуть змінюватися між будь-яким доступом до змінної через можливий контекстний комутатор. Саме для цього є мінливою декларацією. Він повідомляє компілятору, що ця змінна може змінюватися поза вашим контекстом, тому читайте її кожен доступ і не припускайте, що ви вже знаєте значення.

Якщо змінна відображена в пам'яті на апаратній адресі, то зміни, внесені апаратним забезпеченням, фактично є іншим контекстом поза контекстом вашої програми. Тож карта з пам’яттю також є підказкою. Наприклад, якщо ваша readADC()функція отримує доступ до значення, відображеного в пам'яті, щоб отримати значення АЦП, то ця змінна карта, що зберігається в пам'яті, повинна бути мінливою.

Тож повертаючись до свого питання, якщо до вашого коду є більше і adcValueдо нього звертається інший код, який працює в іншому контексті, то так, це adcValueповинно бути мінливим.

"Глобальна змінна, яка змінюється безпосередньо з обладнання"

Тільки тому, що значення надходить з якогось апаратного реєстру АЦП, не означає, що воно "безпосередньо" змінюється апаратним забезпеченням.

У вашому прикладі ви просто викликаєте readADC (), який повертає деяке значення регістра ADC. Це добре стосовно компілятора, знаючи, що adcValue присвоюється нове значення в цій точці.

Було б інакше, якби ви використовували процедуру переривання ADC, щоб призначити нове значення, яке викликається тоді, коли готове нове значення АЦП. У цьому випадку компілятор не матиме поняття про те, коли викликається відповідна ISR, і може вирішити, що таким чином не буде доступний adcValue. Саме тут міг би допомогти мінливий.

Поведінка volatileаргументу багато в чому залежить від вашого коду, компілятора та зробленої оптимізації.

Є два випадки використання volatile:

• Якщо є змінна, яку я хочу переглянути за допомогою налагоджувача, але компілятор її оптимізував (значить, видалив її, оскільки виявив, що не потрібно мати цю змінну), додавання volatileзмусить компілятор зберегти її, отже можна побачити на налагодження.

• Якщо змінна може змінити "поза кодом", як правило, якщо у вас є якесь апаратне забезпечення доступу до неї, або якщо ви переміщуєте змінну безпосередньо на адресу.

У вбудованих також іноді в компіляторах є досить багато помилок, які роблять оптимізацію, яка насправді не працює, а іноді volatileможе вирішити проблеми.

З огляду на те, що ваша змінна оголошена в усьому світі, вона, ймовірно, не буде оптимізована, якщо ця зміна використовується в коді, принаймні, записана та прочитана.

Приклад:

void test()
{
    int a = 1;
    printf("%i", a);
}

У цьому випадку змінна, ймовірно, буде оптимізована до printf ("% i", 1);

void test()
{
    volatile int a = 1;
    printf("%i", a);
}

не буде оптимізовано

Інший:

void delay1Ms()
{
    unsigned int i;
    for (i=0; i<10; i++)
    {
        delay10us( 10);
    }
}

У цьому випадку компілятор може оптимізуватись (якщо ви оптимізуєте швидкість) і тим самим відкидає змінну

void delay1Ms()
{
       delay10us( 10);
       delay10us( 10);
       delay10us( 10);
       delay10us( 10);
       delay10us( 10);
       delay10us( 10);
       delay10us( 10);
       delay10us( 10);
       delay10us( 10);
       delay10us( 10);
}

Для вашого випадку використання "це може залежати" від решти вашого коду, способу adcValueвикористання в іншому місці та параметрів версії / компілятора, які ви використовуєте.

Іноді може бути прикро мати код, який працює без оптимізації, але перерви одного разу оптимізовані.

uint16_t adcValue;
void readFromADC(void)
{
  adcValue = readADC();
  printf("%i", adcValue);
}

Це може бути оптимізовано до printf ("% i", readADC ());

uint16_t adcValue;
void readFromADC(void)
{
  adcValue = readADC();
  printf("%i", adcValue);
  callAnotherFunction(adcValue);
}

-

uint16_t adcValue;
void readFromADC(void)
{
  adcValue = readADC();
  printf("%i", adcValue);
}

void anotherFunction()
{
   // Do something with adcValue
}

Вони, ймовірно, не будуть оптимізовані, але ви ніколи не знаєте "наскільки хороший компілятор" і можуть змінюватися за допомогою параметрів компілятора. Зазвичай компілятори з хорошою оптимізацією ліцензуються.

Багато технічних пояснень, але я хочу зосередитися на практичному застосуванні.

У volatileключових слів сили компілятор для читання або запису значення змінної з пам'яті кожного разу , коли він використовується. Зазвичай компілятор намагатиметься оптимізувати, але не робити зайвих читання і запису, наприклад, зберігаючи значення в регістрі процесора, а не отримуючи доступ до пам'яті кожен раз.

У вбудованому коді є два основних напрямки використання. По-перше, він використовується для апаратних регістрів. Реєстри обладнання можуть змінюватися, наприклад, регістр результатів АЦП може бути записаний периферійним пристроєм АЦП. Реєстри обладнання також можуть виконувати дії при зверненні. Поширений приклад - реєстр даних UART, який часто видаляє прапорці переривання під час читання.

Компілятор, як правило, намагається оптимізувати повторне читання та запис реєстру з припущенням, що значення ніколи не зміниться, тому немає необхідності постійно отримувати доступ до нього, але volatileключове слово змушує кожного разу виконувати операцію зчитування.

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

Важливо зауважити, що volatileключове слово не є повноцінним вирішенням цих питань, і їх потрібно обережно уникати. Наприклад, для 8-бітної системи для 16-бітної змінної потрібні два доступу до пам'яті для читання або запису, і, навіть, якщо компілятор змушений робити ті доступи, вони виникають послідовно, і апаратне забезпечення може діяти на перший доступ або перерва між двома.

За відсутності volatileкваліфікатора, значення об'єкта може зберігатися в більш ніж одному місці протягом певних частин коду. Розглянемо, наприклад, щось таке:

int foo;
int someArray[64];
void test(void)
{
  int i;
  foo = 0;
  for (i=0; i<64; i++)
    if (someArray[i] > 0)
      foo++;
}

У перші дні C компілятор обробляв би заяву

foo++;

через кроки:

load foo into a register
increment that register
store that register back to foo

Однак більш складні компілятори визнають, що якщо значення "foo" зберігається в регістрі під час циклу, його потрібно буде завантажувати лише один раз перед циклом і зберігати один раз після. Однак під час циклу це означає, що значення "foo" зберігається в двох місцях - всередині глобального сховища та в межах реєстру. Це не буде проблемою, якщо компілятор може бачити всі способи доступу до "foo" в циклі, але це може спричинити проблеми, якщо до значення "foo" можна отримати доступ до якогось механізму, про який компілятор не знає ( наприклад, обробник переривання).

Можливо, авторам Стандарту можна було б додати новий класифікатор, який явно запропонував би компілятору здійснити такі оптимізації та сказати, що старомодна семантика застосовуватиметься за її відсутності, але випадки, коли оптимізація корисна, значно перевищує кількість ті, де це було б проблематично, тому Стандарт замість цього дозволяє компіляторам припускати, що такі оптимізації безпечні за відсутності доказів того, що вони не є. Метою volatileключового слова є надання таких доказів.

Декілька суперечок між деякими авторами-компіляторами та програмістами виникають у таких ситуаціях, як:

unsigned short volatile *volatile output_ptr;
unsigned volatile output_count;

void interrupt_handler(void)
{
  if (output_count)
  {
    *((unsigned short*)0xC0001230) = *output_ptr; // Hardware I/O register
    *((unsigned short*)0xC0001234) = 1; // Hardware I/O register
    *((unsigned short*)0xC0001234) = 0; // Hardware I/O register
    output_ptr++;
    output_count--;
  }
}

void output_data_via_interrupt(unsigned short *dat, unsigned count)
{
  output_ptr = dat;
  output_count = count;
  while(output_count)
     ; // Wait for interrupt to output the data
}

unsigned short output_buffer[10];

void test(void)
{
  output_buffer[0] = 0x1234;
  output_data_via_interrupt(output_buffer, 1);
  output_buffer[0] = 0x2345;
  output_buffer[1] = 0x6789;
  output_data_via_interrupt(output_buffer,2);
}

Історично більшість компіляторів допускали б можливість того, що запис місця volatileзберігання може викликати довільні побічні ефекти, і уникнути кешування будь-яких значень у регістрах у такому магазині, або ж вони утримаються від кешування значень у регістрах через виклики до функцій, які є не кваліфікований "вбудований", і, таким чином, записати 0x1234 в output_buffer[0], налаштувати речі для виведення даних, дочекатися їх завершення, потім написати 0x2345 до output_buffer[0]та продовжувати звідти. Стандарт не вимагає реалізації для обробки акта збереження адреси output_bufferв avolatile-кваліфікований покажчик як знак того, що щось може статися з ним через засоби, що компілятор не розуміє, однак, оскільки автори думали, що компілятор автори компіляторів, призначені для різних платформ і цілей, визнають, коли це робитимуть ці цілі на цих платформах без того, щоб говорити. Отже, деякі "розумні" компілятори, такі як gcc і clang, будуть вважати, що, хоча адреса output_bufferзаписується на мінливий покажчик між двома сховищами до output_buffer[0], це не є підставою припускати, що що-небудь може хвилювати значення, що міститься в цьому об'єкті того часу.

Крім того, хоча вказівники, які безпосередньо передаються з цілих чисел, рідко використовуються для будь-якої іншої мети, ніж для маніпулювання речами способами, які компілятори, мабуть, не зрозуміють, стандарт знову не вимагає від компіляторів для такого доступу як volatile. Отже, перше записування, яке *((unsigned short*)0xC0001234)може бути опущене, "розумні" компілятори, такі як gcc та clang, тому що керівники таких компіляторів швидше заявляють, що код, який нехтує кваліфікацією таких речей, як volatile"порушений", ніж визнає, що сумісність, якщо такий код корисний . Багато файлів заголовків, що постачаються постачальниками, опускають volatileкваліфікатори, а компілятор, сумісний із файлами заголовків, що постачаються постачальниками, є більш корисним, ніж той, який не є.