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 → [test] [1] [2] [3] [4] [5] [6] [7] [8] [9]

8 - Périphériques initiateurs et API graphique

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()
et le code de commandes des périphériques est dans harch.c
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.
  • Quelle est la durée de chaque étape ?
  • Que pouvez-vous en conclure ?
• Essayez de retirer les invalidations du cache (dans harch.c)
  • Observez et expliquer le comportement.
  • En déplaçant, l'instruction qui prend la valeur de clock(),
    déterminer le nombre de cycles nécessaire à l'invalidation du buffer.
    C'est long, pourquoi ?
• Expliquez l'usage des couples de variables globales utilisées pour la synchronisation des étapes.
  (BDBusy et BDLock) et (DMABusy et DMALock).

02_parallel

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

 - 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).
  Vous devez regarder la durée de chaque étape (chargement/calcul/affichage)

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 sur Linux/PC, vous pouvez allez dans uapp0 et exécuter l'application avec Linux/PC, dans tp3/03_sdl/uapp0

make -f MakeLinux
./aff_noevent

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

make exec

Vous pouvez aussi tester

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.