Ajout de l'exo 5 sur le README
This commit is contained in:
parent
7c9425c9d7
commit
598495d9f0
@ -51,5 +51,18 @@ int main()
|
||||
ex5.x=62;ex5.y=63;ex5.z=64;ex5.w=65;
|
||||
|
||||
// appelez hexdump pour chaque variable
|
||||
hexdump(a, sizeof(a));
|
||||
hexdump(c, sizeof(c));
|
||||
hexdump(&ex1, sizeof(ex1));
|
||||
hexdump(&ex2, sizeof(ex2));
|
||||
hexdump(&ex3, sizeof(ex3));
|
||||
hexdump(&ex4, sizeof(ex4));
|
||||
hexdump(&ex5, sizeof(ex5));
|
||||
hexdump(&x, sizeof(x));
|
||||
hexdump(&y, sizeof(y));
|
||||
hexdump(&z, sizeof(z));
|
||||
hexdump(&w, sizeof(w));
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
|
37
Exo5/exo5.c
Normal file
37
Exo5/exo5.c
Normal file
@ -0,0 +1,37 @@
|
||||
#include<stdio.h>
|
||||
#include<time.h>
|
||||
#include<stdlib.h>
|
||||
#include<string.h>
|
||||
#include<assert.h>
|
||||
|
||||
void hexdump(void *ptr, size_t size) {
|
||||
unsigned char *p = ptr;
|
||||
unsigned char *end = p + size;
|
||||
char ascii[17];
|
||||
size_t i;
|
||||
for (i = 0; i < 16; ++i) {
|
||||
ascii[i] = '\0';
|
||||
}
|
||||
i = 0;
|
||||
while (p != end) {
|
||||
if (i % 16 == 0) {
|
||||
if (i != 0) {
|
||||
printf(" |%s|\n", ascii);
|
||||
}
|
||||
printf("%p ", p);
|
||||
}
|
||||
printf("%02X ", *p);
|
||||
if (*p >= ' ' && *p <= '~') {
|
||||
ascii[i % 16] = *p;
|
||||
} else {
|
||||
ascii[i % 16] = '.';
|
||||
}
|
||||
++p;
|
||||
++i;
|
||||
}
|
||||
while (i % 16 != 0) {
|
||||
printf(" ");
|
||||
++i;
|
||||
}
|
||||
printf(" |%s|\n", ascii);
|
||||
}
|
22
README.md
22
README.md
@ -261,3 +261,25 @@ total kB 2828 1612 324
|
||||
Testez en faisant varier la taille du tableau. Expliquez.
|
||||
|
||||
>La raison de pourquoi la manière aléatoire est plus lente que la manière croissante ou décroissante (qui sont aussi rapide l'une que l'autre), est que la manière aléatoire fait plus de cache miss que les deux autres, car elle accède aux éléments du tableau de manière aléatoire, donc il y a plus de chance que l'élément ne soit pas dans le cache, alors que dans les deux autres, les éléments sont accédés de manière séquentielle, donc il y a plus de chance que l'élément soit dans le cache. Ce qui force la lecture de la RAM.
|
||||
|
||||
## Exercice 5
|
||||
>Ecrire une fonction
|
||||
```c
|
||||
void hexdump(void * ptr,size_t size);
|
||||
```
|
||||
|
||||
>qui affiche sur la sortie standard le contenu de la mémoire `[ptr,ptr+size[` au format :
|
||||
|
||||
```
|
||||
XXXXXXXX BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB |CCCCCCCCCCCCCCCC|
|
||||
```
|
||||
|
||||
>(comme la commande shell)
|
||||
|
||||
- `XXXXXXXXX` représente l'adresse du premier octet de la ligne
|
||||
- `BB` la valeur hexadécimale de chaque octet
|
||||
- `|CCCCCCCCCCCCCCCC|` la correspondance ascii de chaque octet (. si non affichable)
|
||||
|
||||
>Est-ce conforme à ce que l'on a vu en cours concernant l'alignement en mémoire ?
|
||||
|
||||
>L'alignement en mémoire est conforme à ce que l'on a vu en cours car les adresses sont alignées sur 16 octets.
|
Loading…
Reference in New Issue
Block a user