Introduction
Toutes les applications embarquées utilisent les interruptions ; beaucoup supportent le traitement multitâches ou multitread des opérations. Les applications de ce type peuvent s'attendre a ce que le déroulement normal du programme change de contexte, à n'importe quel moment.
Quand une interruption survient, l'opération courante est suspendue et une fonction ou une tâche différente commence à fonctionner. Que se passe-t-il si les fonctions ou les tâches partagent des variables ? ....Un désastre si une fonction corrompt les données d'une autre fonction.

En contrôlant soigneusement comment les données sont partagées, on crée des fonctions réentrantes permettant des appels multiples et concourant qui n'interfèrent pas l'un avec l'autre : cette phrase est la définition même de la réentrance.
Dans les applications embarquées, une fonction ou une tâche est réentrante si elle satisfait aux conditions suivantes :

- Elle emploie toutes les variables partagées de manière "ATOMIQUE", à moins que ces variables soient     assignées spécifiquement à une fonction.
- Elle n'appelle pas de fonctions NON-REENTRANTES.
- Elle n'utilise pas le hard de manière "NON-ATOMIQUE".

Variables atomiques
Le mot "atomique" vient du Grec qui signifie "indivisible". Dans le monde informatique, une opération atomique est une opération qui ne peut être interrompue. Par exemple l'instruction assembleur : mov ax,bx

Puisque rien d'autre qu'un RESET du processeur ne peut stopper ou interrompre cette instruction, celle-ci est atomique : elle débute et se termine sans qu'elle soit perturbée par d'autres tâches ou des interruptions. Autre exemple typique pour gérer des ressources partagées, c'est l'instruction TAS de la famille des processeurs 68000 de Motorola : cette instruction a la particularité de lancer 3 cycles ( lecture - modification - écriture ) de façon indivisible.

La première condition requise pour une fonction réentrante c'est d'utiliser les variables partagées de manière atomique : supposons que deux fonctions partagent une variable globale Toto.

temp = toto;
temp += 1;
toto = temp;

Cette portion de code n'est pas réentrante, parce que toto n'est pas employé de façon atomique : il faut trois actions pour changer sa valeur et non une. La manipulation de la variable toto n'est pas indivisible : une interruption peut survenir entre ces instructions et commuter le contexte à l'autre fonction, qui peut également essayer de changer le contenu de la variable toto : il y a conflit !
Au lieu de cela on peut faire : toto += 1;

Maintenant l'opération est atomique ... ? Une interruption ne peut pas suspendre le traitement avec toto dans un état partiellement changé, ainsi cette routine est réentrante. A moins que ..... le compilateur C produise un code du genre :

mov ax,(toto)
inc ax
mov (toto),ax

Compilé sous cette forme, l'opération qui consiste à incrémenté la variable toto, n'est pas atomique et et n'est pas réentrante non plus. La version atomique doit être sous la forme : inc (toto)

Donc méfiance à l'égard des compilateurs et du code qu'ils sont susceptibles de générer.!!

SI l'aspect atomique est parfois difficilement maîtrisable autre qu'en assembleur, la première règle de la réentrance met en évidence le fait d'utiliser des variables spécifiques ( locales ) pour chaque fonctions : en C et C++, Il suffit d'employer les variables automatiques : c'est à dire les variables qui sont déclarées à l'intérieur d'une fonction et visibles uniquement par celle-ci ; chaque appel de la fonction crée une nouvelle version des variables sur la pile.

Les appels non-réentrants sont prohibés
Cette deuxième règle est évidente et indique qu'une fonction appelante hérite des problème de réentrance de la fonction appelée. En utilisant les langages compilés comme le C et le C++ cela peut générer des problèmes insidieux. Comment être sûr de toutes les fonctions des bibliothèques sont réentrantes ? Évidement, les opération sur les strings et beaucoup d'autres opérations ( calculs, conversion ...) font des appels aux bibliothèques pour effectuer le vrai travail.
Poser la question au fournisseur du compilateur C / C++ pour s'assurer que les fonctions des bibliothèques sont bien réentrantes ; idem pour les packages logiciels tels que les piles de protocoles ( TCP/IP ). En règle générale il faut bien se renseigner avant d'acheter ....

Accès non-atomiques aux interfaces de périphériques
La dernière règle concernant la réentrance s'applique au hard. Dans bon nombre d'architectures, les "entrées / sorties" ou interfaces de périphériques sont "projetés en mémoire", et vus comme de la mémoire ou des variables. Dans le cas ou un accès nécessite plus d'une opération simple pour accéder à l'interface, les problèmes de réentrance peuvent se développer.
C'est le cas par exemple avec certains composants ou contrôleur d'interface, où n'importe quel accès exige deux étapes : on écrit d'abord l'adresse du registre dans un registre d'adresse, puis lit ou on écrit la donnée dans le registre de donnée, à la même adresse.
C'est un cas isolé mais qu'il faut connaître, faute de quoi on retombe dans le même schéma qu'une opération non-atomique.

Quel sont les meilleures options pour produire du code réentrant ?
Le premier principe c'est d'éviter les variables partagées : les variables globales sont souvent une source d'ennuis et de debug fastidieux. Employer les variables automatiques ( locales ) ou l'allocation dynamique de la mémoire. Pourtant les variables globales sont la manière la plus rapide d'échanger des données entre les fonctions ou les tâches : il n'est pas toujours possible de les éliminer entièrement des systèmes en temps réel. Ainsi, en utilisant une ressource partagée ( variable ou matériel ) il faut mettre en oeuvre d'autres techniques.

L'approche la plus simple consiste à neutraliser les interruptions dans la portion du code non-réentrant : avec le rejet des interruptions, le système devient un environnement simple processus. Le masquage des interruptions augmente le temps de latence du système pour la prise en compte des interruptions. Une approche plus élégante consiste à utiliser un "mutex" ( également connu sous le nom de sémaphore binaire ) pour indiquer quand une ressource est occupée. Les sémaphores binaires sont des indicateurs tout ou rien dont le traitement est en soi atomique. Presque tous les systèmes multitâches temps réel dispose d'un service de ce type.

Récursivité
Décrire la réentrance n'est pas complet sans parler de la récursivité, ne serait-ce que il y a souvent confusion entre les deux. Définition de la récursivité : une fonction est récursive si elle s'appelle .
C'est une manière classique d'enlever des itérations dans des algorithmes, bien qu'utilisant beaucoup la pile, et étant moins lisible et plus difficile à vérifier. Puisqu'une fonction récursive s'appelle, elle doit forcément être réentrante pour éviter la destruction de ses variables lors des appels multiples.
Toutes les fonctions récursives doivent être réentrantes, mais toutes les fonctions réentrantes ne sont pas forcément récursives.

Introduction
Dans bon nombre de systèmes à microprocesseur, l'unité centrale lit et écrit des données en mémoire, et communique avec l'extérieur par des messages ayant une structure définie. Le langage C / C++ par exemple, est souvent utilisé pour la programmation système et / ou embarquée et il permet de définir simplement des structures de données ; le problème c'est que souvent les compilateurs / microprocesseurs définissent une même structure de données de façon différentes, causant une incompatibilité dans la définition de l'interface.
Deux raisons à cela :

• Les restrictions d'alignement.
• Le modèle mémoire ( big endian / little endian ).

Le modèle mémoire "big endian" ou "little endian"
Le modèle mémoire défini la manière dont les données sont représentées en mémoire. Deux modèles s'affrontent depuis des années : le modèle "big-endian" Motorola et le modèle 'little endian" Intel. Big-endian signifie "big end" ( most significant byte ), indiquant que l'octet de poids fort est en premier ( à l'adresse basse ). Little-endian signifie "little end" ( least significant byte ), indiquant que l'octet de poids faible est en premier ( à l'adresse basse ).

Les microprocesseurs de la famille 80x86 d' Intel et leurs dérivés sont sur le modèle "little endian". Les microprocesseurs SPARC de Sun, les microprocesseurs de la famille 68xxx Motorola et leurs dérivés sont sur le modèle "big endian". Les microprocesseurs PowerPC sont universels, puisqu'il est possible de configurer le microprocesseur en mode "little endian" ou en mode "big endian", ce dernier étant le mode par défaut. On peut noter aussi que JAVA et sa machine virtuelle fonctionnent sur le modèle "big endian", tout comme les couches réseaux des protocoles TCP/IP .... La balance pencherait donc coté "big endian" ?

Exemple d'un mot long ( 32 bits ) 0x0AC0FF00, représenté sur un système "big-endian" et sur un système "little endian".

                         0x20000000 0x20000001 0x20000002 0x20000003
Big-endian     0x0A               0xC0              0xFF               0x00
Little-endian  0x00                0xFF              0xC0               0x0A


Problèmes engendrés par cette différence
D'une manière générale un programme compilé sur une machine "big endian" ne pourra pas fonctionner correctement sur une machine "little endian", et inversement : la représentation et le stockage des mots de 16, 32 et 64 bits est susceptible de poser des problèmes. L'exemple typique est deux machines reliées en réseau via le protocole TCP/IP : ce dernier étant sur le modèle "big endian", une adresse IP par exemple sera envoyée et reçue avec son octet le plus significatif en premier.
Sans traitement particulier, si une des machine ( un PC 80x86 ) envoi une adresse IP 192.0.1.2, qui en "little endian" fait 0x020100C0 ( représentation hexadécimale 32 bits ), à une machine de type SPARC, celle-ci reconstruit une fausse adresse ( 2.1.0.192 ) à partir des octets reçus 0x02,0x01,0x00 et 0xC0. D'où la nécessité d'identifier le type de modèle mémoire et de réaliser ou non les traitements particuliers pour stocker correctement les données en mémoire.


Pourquoi des modèles mémoires différents ?
Il n'y a pas de raisons logiques et valables pour que les fabricants de microprocesseurs décident d'utiliser des modèles mémoires différents. La raison est principalement historique : elle est née dans le combat qui à toujours opposé les deux géant du semi-conducteur, Motorola ( big-endian ) et Intel ( little-endian ). Malgré tout la balance penche plutôt du coté "big endian" notement en ce qui concerne les applications réseaux ( routeur, passerelle réseau, connectivité TCP/IP ... ) : le fonctionnement de telles applications sera pénalisé en durée d'exécution sur une machine "little endian", par la nécessité de convertir de façon bidirectionnelle les mots de 16, 32 et 64 bits ( adresses IP, checksum ... ).


Détection du type de modèle mémoire sur une machine en langage C.
Ci-dessous un exemple d'une routine permettant de détecter le modèle mémoire utilisé par le microprocesseur de la machine sur laquelle elle est exécutée.
int Little_Endian (void)
{
   int x = 1;
   return ( x == *((char *)&x)); /* Retourne 1 si Little endian, si différent de 1 c'est Big endian */
}


Conversion big-endian<>little-endian en langage C
Ci-dessous un exemple de deux routines de conversion big-endian > little-endian et inversement, permettant la conversion d'un mot et d'un mot long.
short convert_short (short in)
{
    short out;
    char *p_in = (char *) &in;
    char *p_out = (char *) &out;
    p_out[0] = p_in[1];
    p_out[1] = p_in[0];
    return out;
}

long convert_long (long in)
{
   long out;
  char *p_in = (char *) &in;
  char *p_out = (char *) &out;
  p_out[0] = p_in[3];
  p_out[1] = p_in[2];
  p_out[2] = p_in[1];
  p_out[3] = p_in[0];
  return out;
}

Le mode Thumb est un mode indépendant et un second jeu d’instruction greffé sur le jeu d'instructions ARM RISC standard. Il est possible d’alterner entre les deux séries d'instructions par l'intermédiaire d'un commutateur de mode dans le code. Le cœur du processeur exécute toujours des instructrions ARM 32 bits : un décompresseur matériel convertit les instructions Thumb vers leur équivalent en instruction ARM ; la décompression matérielle s’effectue à l’étage du décodage du pipeline. Le mode « Thumb Instruction Set Architecture » ( ISA ) est composé d’environ 36 instructions sur 16 bits, permettant de faire des opérations de base telles que : addition, soustraction, branchements, et les opérations de rotation. En utilisant ces instructions à la place des instructions ARM normales sur 32 bits, il est possible de réduire la taille du code de 20 à 30 %.

Il y a plusieurs méthodes pour passer du mode ARM à un mode thumb et vice versa. La méthode la plus usuelle est d’utiliser l’instruction de branchement spéciale BX (Branch and eXchange).
Etant donné que les instructions ARM et Thumb sont alignés sur des frontières de 16 ou 32 bits, le bit 0 du PC n’est jamais utilisé par les instructions de branchements standards. Ainsi, l’instruction BX se branchera à l’adresse spécifiée dans le registre argument Rm en passant en mode Thumb si le bit Rm[0] est égal à 1, en mode ARM sinon. D’autre part il est possible de retourner en mode ARM sur une Exception, une interruption matérielle ou une interruption logicielle ( Software Interrupt ).

Label_ARM_code:
      mov r3, label_Thumb_code
      or r3, r3, #1
      bx r3

Label_Thumb_code:
       ……..
      retour en mode ARM identique en mettant le bit 0 à 0 ....

En langage évolué une simple directive de compilation sera suffisante ( exemple ) :

#Pragma __ARM__

#Pragma __THUMB__

Si l’instruction BX Rm est exécutée, alors le processeur se branche a l’adresse specifiee par Rm[31..1], et fait le changement de mode:
_ Si Rm[0]=1⇒mode Thumb
_ Si Rm[0]=0 ⇒mode ARM

Il n’est pas possible de mixer n’importe comment du code Thumb et du code ARM ;  il faut expressément switcher d’un mode à l’autre, et donc de séparer les blocs de code 16 bits Thumb du code ARM 32 bits. D’autre part le mode Thumb est abrégé et simplifié par rapport au mode ARM, et il n’est pas possible de faire certaines opérations : gérer les interruptions, les exceptions, les sauts longs, les transactions atomiques en mémoire ou des opérations coprocesseur. De petites séquences d’instructions ARM deviennent des séquences plus longues si elles sont traduites en instructions Thumb.  Une autre limitation c’est les registres disponibles : en mode Thumb plus que 8 registres au lieu de 16 ; le passage de paramètres entre mode ARM et mode Thumb code n'est pas difficile, tant qu’ils sont passés par la pile ou par le biais du processeur et des huit premiers registres. Passer et sortir du mode Thumb prend aussi du temps et, paradoxalement, ajoute du code ( c’est un comble ) : quelques dizaines d'octets de préambule et postambule sont nécessaires pour organiser des pointeurs et vider le cache CPU.

Que faire alors du mode Thumb ? l’utiliser quand le budget de taille du code / taille mémoire est serré et / ou pour du code non critique. D’autre part il ne faut pas utiliser le mode Thumb pour quelques instructions mais une dizaine au minimum. Les performances sont globalement affectées, d’environ 15 % par rapport au mode ARM, pénalisées par la commutation ARM / thumb qu’il faut vraiment utiliser avec parcimonie. Un point positif sur la gestion du cache plus efficace du fait des instructions sur 16 bits….