Reprenons une version du programme académique ayant servi d'exemple au chapitre C4‑I  pour illustrer la notion de fonction. Ce programme teste en boucle si deux nombres entiers strictement positifs saisis par l'utilisateur sont premiers entre eux.

Dans le code, on a ajouté des commentaires pour indiquer les différents niveaux de ce programme – et ce même si, pour certains niveaux, aucune variable n'est déclarée.

#include <stdio.h>
#include <stdlib.h>
#include <stdbool.h>

/* ========================= LEVEL 0 ======================= */

// function prototypes
void enteringNumber(unsigned n, unsigned * number);
bool arePrime (unsigned a, unsigned b);


int main(void)
{ /* ======================= MAIN - LEVEL 1 ======================= */ 
  unsigned number1 = 0, number2 = 0;
  while (true) {
    /* ===================== MAIN - LEVEL 2 ======================= */
    enteringNumber(1, &number1);
    enteringNumber(2, &number2);
    if (arePrime(number1, number2)) {
      /* ===================== MAIN - LEVEL 3 ======================= */  
      printf("%u et %u sont PREMIERS ENTRE EUX.\n", number1, number2);
    }
    else {
      /* ================== MAIN - OTHER LEVEL 3 ==================== */
      printf("%u et %u ne sont PAS premiers entre eux.\n", number1, number2);
    }
  }
}

/* ========================= LEVEL 0 ======================= */

void enteringNumber(unsigned n, unsigned * number)
{ /* ======================= FUNCTION1 - LEVEL 1 ======================= */ 
  printf("Nombre entier %u (0 pour sortir): ", n);
  scanf("%u", number);
}

/* ========================= LEVEL 0 ======================= */

bool arePrime (unsigned a, unsigned b)
{ /* ======================= FUNCTION2 - LEVEL 1 ====================== */ 
  if (a == 0 || b == 0) exit(1);   /* <---- LEVEL 2  */
  while (b != 0) {
    /* ======================= FUNCTION2 - LEVEL 2 ====================== */
    unsigned c = b;
    b = a % b;      
    a = c;
  }
  /* ======================= FUNCTION2 - LEVEL 1 ====================== */
  return (a == 1);  
}

/* ========================= LEVEL 0 ======================= */

On va voir infra  comment les données déclarées se répartissent sur les différents niveaux identifiés.

Dans le programme académique commenté supra  :

• il n'y a aucune variable globale ;
• les variables locales number1 et number2 sont visibles dans toute la fonction main puisqu'elles sont déclarées au tout début de cette dernière ;
• les arguments formels a et b de la fonction arePrime sont aussi considéré comme des variables locales ; ils sont visibles seulement dans le bloc de définition de cette fonction ;
• la variable locale c est visible seulement dans le bloc de la boucle while de la fonction arePrime.

Dans l'environnement Arduino, on code le programme académique volontairement confus ci‑dessous qui crée trois variables ayant le même identificateur foo. On leur donne des types différents pour bien les distinguer.

                        /* ============ (LEVEL 0 - GLOBAL) */
float foo = 0.0;        // declaration of var. "foo #1"

void setup()
{                       /* ============ (LEVEL 1 - SETUP)  */
  Serial.begin(9600);   
  foo = 1.1;            // assignment of "foo #1"
  Serial.println(foo);  // display on the monitor -> 1.10
  int foo = 0;          // declaration of var. "foo #2"
  foo = 2.1;            // assignment of "foo #2"
  Serial.println(foo);  // display on the monitor -> 2 (int)
}

void loop()
{                       /* =========== (LEVEL 1 - LOOP)    */
  Serial.println(foo);  // display on the monitor -> 1.10
  bool foo = true;      // declaration of var."foo #3"
  Serial.println(foo);  // display on the monitor -> 1 (true)
  delay(100000);
}

Sur un poste de travail à architecture x86‑64 opérée sous Linux, en compilant avec GCC puis en exécutant son fichier source testSegments.c, le programme académique ci‑dessous affiche dans le terminal les adresses de différentes données déclarées ainsi que celle de la fonction  main. Il utilise pour cela l'opérateur d'adresse & qui sera étudié en détail au chapitre C5‑I .

#include <stdio.h>

const char GC_A = 0;   // GLOBAL CONSTANT = 0
const char GC_B = 1;   // GLOBAL CONSTANT ≠ 0
 
char gv_a = 1;         // global variable ≠ 0
char gv_b = 0;         // global variable = 0
char gv_c;             // global variable non initialized
 
int main(void)
{
  gv_c = 2;
  const char LC_A = 1; // LOCAL CONSTANT ≠ 0
  const char LC_B = 0; // LOCAL CONSTANT = 0
  char lv_a = 1;       // local variable ≠ 0
  char lv_b = 0;       // local variable = 0
  printf("%p: main [text]\n",      (void *) main);
  printf("%p: GC_A [rodata]\n",    (void *) &GC_A);
  printf("%p: GC_B [rodata]\n",    (void *) &GC_B);
  printf("%p: gv_a [data]\n",      (void *) &gv_a);
  printf("%p: gv_b [data .bss]\n", (void *) &gv_b);
  printf("%p: gv_c [data .bss]\n", (void *) &gv_c);
  printf("\n");
  printf("%p: LC_A [stack - main frame]\n", (void *) &LC_A);
  printf("%p: LC_B [stack - main frame]\n", (void *) &LC_B);
  printf("%p: lv_a [stack - main frame]\n", (void *) &lv_a);
  printf("%p: lv_b [stack - main frame]\n", (void *) &lv_b);
  scanf("_");
  return 0;
}

La sortie standard ainsi obtenue sur le terminal d'exécution permet de déterminer les adresses attribuées par la machine aux éléments déclarés. Les indications entre crochets [] précisent pour chacune le segment principal ou la région dans laquelle chaque élément est stocké en mémoire.

0x62bfa3ed11a9: main [text]
0x62bfa3ed2008: GC_A [rodata]
0x62bfa3ed2009: GC_B [rodata]
0x62bfa3ed4010: gv_a [data]
0x62bfa3ed4012: gv_b [data .bss]
0x62bfa3ed4013: gv_c [data .bss]

0x7ffca8331e14: LC_A [stack - main frame]
0x7ffca8331e15: LC_B [stack - main frame]
0x7ffca8331e16: lv_a [stack - main frame]
0x7ffca8331e17: lv_b [stack - main frame]

Grâce à cette sortie, on peut aisément distinguer :

• la zone statique, dont les adresses commencent par 0x62bfa3ed ;
• la zone dynamique , dont les adresses commencent par 0x7ffca833.

De plus, dans la zone statiques, on voit que les allocations se font pour des données de même catégorie par groupes d'adresses consécutives, qui sont décalés les uns des autres par multiples de 0x1000 octets. Ces décalages sont dûs aux alignements de pagination et témoignent de changements de segment.

Plus en détails, on observe que, comme attendu, la fonction main se voit bien attribuer une adresse « basse » (par rapport aux données), puisqu'elle est censée être placée dans le segment text.

De plus, sachant que toutes les données déclarées sont de type char, donc encodées sur un seul octet et sans contraintes d'alignement (cf. chap. C3‑I ), on peut faire les déductions suivantes (qui seront vérifiées par la suite).

• Les constantes globales GC_A et GC_B obtiennent des adresses consécutives. Quelle que soit leur valeur (0 ou autre), elles sont a priori placées dans le même segment rodata.
• Les variables globales gv_a, gv_b et gv_c obtiennent des adresses très proches. Elles sont donc placées dans le même segment, a priori data.
De plus, les variables gv_b et gv_c, respectivement initialisée nulle et non initialisée sont placées à des adresses consécutives, avec un « saut » de 2 octets après gv_a, qui témoigne vraisemblablement du passage dans la section .bss.

Quant aux quatre données locales LC_A,  LC_B, lv_a et lv_b, elles se trouvent dans la zone dynamique, plus précisément tout en bas dans la pile, et plus précisément encore dans le cadre (frame) alloué à la fonction main. Peu importe alors que ces données soient constantes ou variables, initialisées ou non, elles obtiennent des adresses consécutives.

./testSegments & cat /proc/$!/maps

62bfa3ed0000-62bfa3ed1000 r--p 00000000 08:23 50466151 […]/testSegments
62bfa3ed1000-62bfa3ed2000 r-xp 00001000 08:23 50466151 […]/testSegments
62bfa3ed2000-62bfa3ed3000 r--p 00002000 08:23 50466151 […]/testSegments
62bfa3ed3000-62bfa3ed4000 r--p 00002000 08:23 50466151 […]/testSegments
62bfa3ed4000-62bfa3ed5000 rw-p 00003000 08:23 50466151 […]/testSegments
62bfbd5ca000-62bfbd5eb000 rw-p 00000000 00:00 0        [heap]
756b4ea00000-756b4ea28000 r--p 00000000 08:01 1576680  […]/libc.so.6
756b4ea28000-756b4ebb0000 r-xp 00028000 08:01 1576680  […]/libc.so.6
756b4ebb0000-756b4ebff000 r--p 001b0000 08:01 1576680  […]/libc.so.6
756b4ebff000-756b4ec03000 r--p 001fe000 08:01 1576680  […]/libc.so.6
756b4ec03000-756b4ec05000 rw-p 00202000 08:01 1576680  […]/libc.so.6
756b4ec05000-756b4ec12000 rw-p 00000000 00:00 0 
756b4eddf000-756b4ede4000 rw-p 00000000 00:00 0 
756b4ede4000-756b4ede5000 r--p 00000000 08:01 1573349  […]/ld-linux-x86-64.so.2
756b4ede5000-756b4ee10000 r-xp 00001000 08:01 1573349  […]/ld-linux-x86-64.so.2
756b4ee10000-756b4ee1a000 r--p 0002c000 08:01 1573349  […]/ld-linux-x86-64.so.2
756b4ee1a000-756b4ee1c000 r--p 00036000 08:01 1573349  […]/ld-linux-x86-64.so.2
756b4ee1c000-756b4ee1e000 rw-p 00038000 08:01 1573349  […]/ld-linux-x86-64.so.2
7ffca8312000-7ffca8334000 rw-p 00000000 00:00 0        [stack]

Adaptons dans le framework Arduino le programme académique d'étude de l'allocation mémoire proposé supra  pour une machine de type ordinateur.

• La déclaration des données est presque inchangée, à l'exception de la constante globale GC_A qui utilise la macro‑définition PROGMEM (cf. supra ).
• L'affichage des adresses des données déclarées est effectué dans le moniteur série à l'aide une fonction spécifique nommée displaySymb. Pour pallier l'incommodité de la méthode Serial.print (compararivement à printf), elle utilise des pointeurs – notion qui est abordée seulement au chapitre C5‑I .
Et l'ordre des instructions d'affichage est adapté aux spécificités du framework Arduino pour suivre l'ordre croissant des adresses.

Le code source du programme, stocké dans un fichier nommé testSegmentsUNO.ino est donnée ci‑dessous.

const char GC_A PROGMEM = 1;
const char GC_B = 0;
 
char gv_a = 1;         // global variable ≠ 0
char gv_b = 0;         // global variable = 0
char gv_c;             // global variable non initialized
 
void setup()
{
  Serial.begin(115200);
  Serial.println();
 
  gv_c = 2;
  const char LC_A = 1; // LOCAL CONSTANT ≠ 0
  const char LC_B = 0; // LOCAL CONSTANT = 0
  char lv_a = 1;       // local variable ≠ 0
  char lv_b = 0;       // local variable = 0
  
  Serial.println("Flash content:");
  displaySymb(&GC_A,               "GC_A        [text]");
  displaySymb((void*) setup,       "setup       [text]");
  displaySymb((void*) loop,        "loop        [text]");
  displaySymb((void*) displaySymb, "displaySymb [text]");
 
  Serial.println();
  Serial.println("SRAM content:");
  displaySymb(&gv_a, "gv_a [data]");
  displaySymb(&gv_a, "GC_B [data]");
  displaySymb(&gv_b, "gv_b [bss]");
  displaySymb(&gv_c, "gv_c [bss]");
  displaySymb(&LC_A, "LC_A [stack - setup frame]");
  displaySymb(&LC_B, "LC_B [stack - setup frame]");
  displaySymb(&lv_a, "lv_a [stack - setup frame]");
  displaySymb(&lv_b, "lv_b [stack - setup frame]");
}
 
void loop()
{
  delay(1000);
}
 
void displaySymb(const void * address, const char * name)
{
  Serial.print("0x"); Serial.print(int(address), HEX); 
  Serial.print(": "); Serial.println(name);
}

Compilé et téléversé avec Arduino IDE sur une carte Arduino Uno R3 (32 ko de mémoire flash pour le programme, 2048 octets de mémoire SRAM pour les données), ce programme produit sur le moniteur série la sortie suivante :

Flash content:
0x68: GC_A        [text]
0x234: setup       [text]
0x192: loop        [text]
0x1E7: displaySymb [text]

SRAM content:
0x100: gv_a [data]
0x101: GC_B [data]
0x220: gv_b [bss]
0x221: gv_c [bss]
0x8F5: LC_A [stack - setup frame]
0x8F6: LC_B [stack - setup frame]
0x8F7: lv_a [stack - setup frame]
0x8F8: lv_b [stack - setup frame]

On peut ainsi bien visualiser la séparation de la zone statique en deux parties avec :

• dans la mémoire flash, formant le segment text, le code des fonctions du programme et la constante globale GC_A déclarée avec la macro‑définition PROGMEM ;
• dans la mémoire SRAM, les segments data et bss contenant les données globales.
À noter que la constante globale GC_B est bien placée dans le segment data puisqu'il n'y pas de segment  rodata.

nm -n testSegmentsUNO.ino.elf | grep -E '\<[TtRrDdBb]\>' | grep -vE '__|_e|ZN|ZT|Z14|Z17|\.|ti'
00000068 t _ZL4GC_A
000000c0 t micros
00000324 t loop
000003ce t _Z11displaySymbPKvPKc
00000468 t setup
000006d6 T main
00800100 d gv_a
00800101 d _ZL4GC_B
00800220 b gv_b
00800221 b gv_c
0080022b b Serial

readelf -lW testSegmentsUNO.ino.elf
Elf file type is EXEC (Executable file)
Entry point 0x0
There are 3 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000094 0x00000000 0x00000000 0x007e4 0x007e4 R E 0x2
  LOAD           0x000878 0x00800100 0x000007e4 0x00120 0x00120 RW  0x1
  LOAD           0x000998 0x00800220 0x00800220 0x00000 0x000a8 RW  0x1

 Section to Segment mapping:
  Segment Sections...
   00     .text
   01     .data
   02     .bss

Reprenons l'exemple volontairement confus élaboré supra  dans l'environnement Arduino avec trois variables différentes portant le même identificateur foo. Bien que contraire aux bonnes pratiques, ce programme permet d'illustrer la notion de durée de vie.

float foo = 0.0;        // global var. "foo #1" (.data segment)
                        // exists all along the run-time
void setup()
{
 Serial.begin(115200);
 foo = 1.1;             // global var. "foo #1" is modified   
 Serial.println(foo);   // display on the monitor -> 1.10
 int foo = 0;           // local var. "foo #2" starts to exist 
 foo = 2.1;             // local var. "foo #2" is modified 
 Serial.println(foo);   // display on the monitor -> 2 ("foo #2" is int)
}                       
                        // local var. "foo #2" has ceased to exist
void loop()
{
  Serial.println(foo);  // display on the monitor -> 1.10 ("foo #1")
  bool foo = true;      // local var. "foo #3" starts to exist 
  Serial.println(foo);  // display on the monitor -> 1 ("foo #3" is boolean)
}                       
                        // local var. "foo #3" has ceased to exist 

// But just after that, a new local variable "foo #4" will be created 
// and so on…
// NB: the global variable "foo #1" still and always exists 

Au regard des mécanismes d'allocation mémoire, on peut maintenant préciser que :

• la variable globale foo « #1 » déclarée à la ligne nº 2 est permanente (elle existe durant toute l'exécution du programme) ;
• la variable locale foo « #2 » déclarée à la ligne nº 9 (dans setup) est temporaire (elle n'existe que jusqu'à la fin de l'exécution de la ligne nº 11) ;
• la variable locale foo « #3 » déclarée à la ligne nº 17 (dans loop) est temporaire (elle n'existe que jusqu'à la fin de l'exécution de la ligne nº 18) ;
sachant qu'une nouvelle variable locale foo « #4 » sera créée lors de la deuxième itération de la fonction loop ; et ainsi de suite…

Reprenons le programme de démonstration de clignotement de la led intégrée sur une carte Arduino, dans sa version réactive – c'est‑à‑dire sans recours à la fonction delay, qui a été proposé au chapitre C2‑IX .

Dans ce programme, on avait déclaré deux données globales :

• en ligne nº 1, la constante BLINK_HALF_PERIOD pour mémoriser la demi‑période de clignotement souhaitée ;
• en ligne nº 9, la variable previousMillis pour mémoriser la valeur retournée par la fonction millis lors du dernier changement d'état de la led.

Mais au regard des bonnes pratiques, il est préférable de déclarer ces deux données non pas globales mais locales dans la fonction loop puisqu'elles ne sont pas utilisées ailleurs dans le code. Pour ce faire, on leur attribue la classe statique, ainsi qu'on peut le lire ci‑dessous dans la nouvelle version du programme :

void setup()
{
  pinMode(LED_BUILTIN, OUTPUT);
}

void loop()
{
  static const unsigned BLINK_HALF_PERIOD = 1000; // 1 seconde
  static unsigned long  previousMillis = millis();
  if (millis() - previousMillis >= BLINK_HALF_PERIOD) {
    previousMillis += BLINK_HALF_PERIOD;
    digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));
  }
}

On peut observer que :

• dans le cas de previousMillis, la classe statique est indispensable, sinon elle ne garderait pas en mémoire sa valeur puisqu'elle serait réinitialisée à chaque nouvelle itération de la fonction loop ;
• dans le cas de BLINK_HALF_PERIOD, la classe statique est préférable, pour éviter que le programme re‑crée la même constante à chaque itération de la fonction loop.