Changes between Version 50 and Version 51 of AS6-TME-B6

Timestamp:

Mar 30, 2022, 8:19:48 AM (3 years ago)

Author:

franck

Comment:

--

AS6-TME-B6

@@ -314 +314 @@
 On voit que les blocs sont parcouru depuis `Heap.beg` le premier bloc jusqu'au dernier `Heap.end` (qui n'est pas vraiment un bloc mais une frontière). Lisez le code et trouvez comment recommencer le prochain `try_malloc()` à partir de dernier bloc alloué. Ce n'est pas difficile, mais il faut comprendre...
 
+**ulib/memory.c**
 {{{#!c
 static size_t CacheLineSize;    // cache line size set by malloc_init()
@@ -328 +329 @@
 } Heap;
 
+// C Macros to align a pointer p to the current cache line address or the next one 
+// For example, let the CacheLineSize is 0x10 Bytes (4 int), then 
+// if p = 0x76543214 then LINE_FLOOR(p) = 0x76543210 and LINE_CEIL(p) = 0x76543220
+
 #define LINE_FLOOR(p)   (block_info_t *)FLOOR((size_t)(p),CacheLineSize)
 #define LINE_CEIL(p)    (block_info_t *)CEIL((size_t)(p),CacheLineSize)
@@ -351 +356 @@
         new->size = newnext - new;                          // new size of current block
         new->magic = MAGIC_HEAP;                            // to try detect Heap corruption
-        newnext->size = oldnext - newnext;                  // new size of remainning space
+        newnext->size = oldnext - newnext;                  // new size of remaining space
         newnext->full = 0;                                  // that is free space
         newnext->magic = MAGIC_HEAP;                        // to try detect Heap corruption
@@ -372 +377 @@
 == B.2. Transformer l'allocateur first-fit en allocateur best-fit
 
-Plus difficile, passer l'allocateur en best-fit. Je ne vous demande pas d'écrire le code, sauf si vous avez du temps et de la motivation. En revanche, vous pouvez réfléchir à la manière de procéder. Pour vous aidez, l'idée, c'est de ne pas toucher aux chaînages des blocs utilisés par first-fit. Il faut créer un chaînage ordonné par taille des blocs libres en utilisant l'API `list`.
-
-== B.3. Tester que les piles n'ont pas débordées
-
-
+
+Plus difficile, passer l'allocateur en best-fit. Je ne vous demande pas d'écrire le code, sauf si vous avez le temps et la motivation. En revanche, vous pouvez réfléchir à la manière de procéder. Pour vous aidez, l'idée, c'est de ne pas toucher aux chaînages des blocs utilisés par first-fit. Il faut créer un chaînage ordonné par taille des blocs libres en utilisant l'API `list` et l'utiliser pour trouver le bloc de la bonne taille. Ce n'est très difficile mais il y a pleins de détails à régler, par exemple, décider de ce que l'on lors d'un ''merge'' des blocs libres.
+
+
+== B.3. Tester que les piles n'ont pas débordé
+
+
+Vous savez peut-être que dans un processeur disposant d'un mécanisme permettant à chaque application d'avoir son propre espace d'adressage (espace d'adressage virtuel), les accès à la mémoire passe par un composant de traduction d'adresses nommé **MMU** pour traduire les adresses virtuelles de l'application en adresses physiques de l'espace d'adressage physique où se trouvent les segments de mémoire physique (gérés par les bancs de mémoire). 
+
+L'un des rôles de ce composant **MMU** (Memory Management Unit) est de tester la légalité des accès à la mémoire. Si le noyau attribut un segment d'adresses à une application. Si l'application tente d'accéder en dehors de ce segment, la MMU le détecte et prévient le noyau par une exception. C'est l'erreur ''Segmentation Fault'' que vous avez certainement déjà eu.
+
+Le SoC **almo1** n'a pas de MMU, donc pas de gestion de mémoire virtuelle, or nous voulons tester que les segments d'adresses définis pour les deux piles de threads ne débordent pas. Pour ce faire, les deux piles de threads (user et kernel) ont des nombres magiques (`MAGIC_STACK`) dans leur premier et dernier mot. Ces mots ne devraient jamais être écrasés, si cela se produit, c'est que les piles ont été corrompues ou qu'elles ont débordé. 
+
+L'idée est de tester à intervalle régulier que les nombres magiques sont toujours présents, par exemple lors des changements de threads. C'est un bon moment parce qu'on peut tester que les piles du thread sortant n'ont pas débordé pendant son exécution et que les piles du thread entrant sont correctes avant de lui donner un cœur.