INDEX

DOCS → [Config] [MIPS U] [MIPS K] [​markdown] [CR.md]
COURS → [1 (+code) (+outils)] [2] [3] [4] [5] [6] [7] [8] [9]
TME → [1] [2] [3] [4] [5] [6] [7] [8] [9]
CODE → [gcc + soc] [1] [2] [3] [4] [5] [6] [7] [8] [9]

8 - Périphériques initiateurs

Pas de question de cours cette fois. Je vais vous demander d'expérimenter le code et je pose quelques questions

01_sequentiel

Dans cette version, il n'y a pas d'OS, tout est fait dans la fonction kinit() Les trois étapes (lecture disque, traitement, affichage) sont faites séquentiellement

Questions

• Ouvrez le code pour voir la boucle de traitement.
• Faites tourner la simulation, la durée de chaque étape s'affichent. Que pouvez-vous en conclure ?
• Essayez de retirer les invalidations du cache (dans harch.c), observez et expliquer le comportement.
• Expliquez l'usage des couples de variables globales (BDBusy et BDLock) et (DMABusy et DMALock) utilisées pour la synchronisation des étapes.

02_parallel

Dans cette version, les trois étapes sont faites en parallèle sous la forme d'un pipeline avec deux couples de buffer utilisés en altenance.

 - Disk->BD->BUFIN[0] 
 - Disk->BD->BUFIN[1] & BUFIN[0]->CPU->BUFOUT[O]  
 - Disk->BD->BUFIN[0] & BUFIN[1]->CPU->BUFOUT[1] & BUFOUT[0]->DMA->FBF 
 - Disk->BD->BUFIN[1] & BUFIN[0]->CPU->BUFOUT[0] & BUFOUT[1]->DMA->FBF 
 - Disk->BD->BUFIN[0] & BUFIN[1]->CPU->BUFOUT[1] & BUFOUT[0]->DMA->FBF 
 - Disk->BD->BUFIN[1] & BUFIN[0]->CPU->BUFOUT[0] & BUFOUT[1]->DMA->FBF 
 - Disk->BD->BUFIN[0] & BUFIN[1]->CPU->BUFOUT[1] & BUFOUT[0]->DMA->FBF 
 - Disk->BD->BUFIN[1] & BUFIN[0]->CPU->BUFOUT[0] & BUFOUT[1]->DMA->FBF 
 - etc.

Questions

• Qu'est ce qu'on gagne à procéder ainsi ?
• Est-ce qu'on peut gagner plus et si oui comment faire (en supposant qu'on a plusieurs processeurs dans le SoC).

Pour ceux qui veulent, on peut aussi paralléliser le traitement CPU en mettant plusieurs processeurs dans la plateforme (htdocs:files/04_multicore.tgz)

03_sdl

Le code ici utilise la version de ko6 vue dans les TP précédents. Il y a un service permettant de lire le clavier sans être bloquant qui a été ajouté, mais c'est tout. Tout le code de la sdl se trouve dans le programme utilisateur. A terme, il faut que ce soit dans une librairie, comme la libc, mais ce n'est pas fait.

Il y a deux applications sdl presque identiques.

1. dans uapp0 : il y a un affichage mais sans gestion d'événements.
2. dans uapp1 : il y a la gestion d'événements.

03_sdl
├── Makefile
├── common
│   ├── debug_off.h
│   ├── debug_on.h
│   ├── errno.h
│   ├── esc_code.h
│   ├── list.h
│   ├── syscalls.h
│   └── usermem.h
├── kernel
│   ├── Makefile
│   ├── harch.c
│   ├── harch.h
│   ├── hcpu.h
│   ├── hcpua.S
│   ├── hcpuc.c
│   ├── kernel.ld
│   ├── kinit.c
│   ├── klibc.c
│   ├── klibc.h
│   ├── kmemory.c
│   ├── kmemory.h
│   ├── ksynchro.c
│   ├── ksynchro.h
│   ├── ksyscalls.c
│   ├── kthread.c
│   └── kthread.h
├── tags
├── uapp0
│   ├── MakeLinux
│   ├── Makefile
│   ├── aff_noevent.c
│   ├── ksdl.h
│   └── main.c
├── uapp1
│   ├── MakeLinux
│   ├── Makefile
│   ├── aff_event.c
│   ├── ksdl.h
│   └── main.c
└── ulib
    ├── Makefile
    ├── crt0.c
    ├── libc.c
    ├── libc.h
    ├── memory.c
    ├── memory.h
    ├── thread.c
    ├── thread.h
    └── user.ld

Pour tester, vous pouvez allez dans uapp0 et exécuter l'application avec Linux/PC, dans tp3/03_sdl/uapp0`

make -f MakeLinux
./aff_event

Vous pouvez alors tester ce même code sur ko6/almo1 dans tp8/03_sdl

make exec

Je ne pose pas de questions... Je me suis mal organisé. Par conséquent, je vais faire une petite revue de code en TP... et après ceux qui le veulent pourraient tenter de faire un jeu, par exemple le jeu de la vie.