C - volatile

volatile

Savez-vous ce qui se cache réellement derrière ce mot ?

En embarqué, il nous arrive souvent de croiser ce mot-clé en pensant “c’est mieux pour les registres”… mais pourquoi ?

D’ordinaire, le compilateur peut se permettre des optimisations quant à l’ordre d’exécution pour réduire les accès aux variables tout en garantissant la cohérence avec votre code. 🙂

Par exemple, une variable modifiée puis lue quelques lignes plus bas peut être optimisée si la portée de celle-ci est limitée. Le compilateur choisit alors de modifier la variable au moment nécessaire pour éviter un deuxième accès superflu en lecture.

Cela perturbe parfois le debug pas-à-pas mais ces optimisations permettent un réel gain de temps à l’exécution.

Ces optimisations fonctionnent uniquement si le programme est le seul à accéder à cette variable.

Or en embarqué, le matériel peut aussi accéder à la mémoire. 🙂

Prenons ce code :

register.flag = 0;
while (!register.flag)
	{} // wait

À première vue, le programme rentre dans une boucle infinie. En effet, pas la peine de relire le flag à chaque tour, la boucle est vide ! (C’est ce que voit et pense le compilateur)

Le soft ne fait rien, mais le hardware oui. 🙂

C’est ici que le volatile est utile. Ça interdit les optimisations sur une variable et force une lecture à chaque passage.

Un transfert DMA ? Un registre du microcontrôleur ? FIFO Hardware ? Pensez volatile 🙂

Un autre cas utile et bien pratique pour le debug (utilisé et approuvé 😀) :

Vous pouvez créer une variable temporaire pour y stocker des infos de debug, le résultat de calculs intermédiaires, ou simplement compter dans un while… Mais cette nouvelle variable ne sera jamais lue par votre code et sera donc optimisée par le compilateur, autrement dit même pas allouée…

Sauf avec un volatile 🙂

Interdiction d’optimiser, donc merci d’allouer quelques octets en stack pour ma variable que je puisse voir ce qu’il y a dedans ! 😀

À vous de jouer !

On se revoit à la rentrée 🙂