ds un proc evidement      
 
 
c un genre de buffer. un file d'attente?

c un gros tuyau ds lequel on fe passer du pétrole
Ok c po ce que tu voulais savoir  
ok je sors

nolimites a écrit a écrit : c un gros tuyau ds lequel on fe passer du pétrole Ok c po ce que tu voulais savoir   ok je sors

c presque ça, en remplacant le pérole par des bits à la queue - leu - leu

nolimites a écrit a écrit : c un gros tuyau ds lequel on fe passer du pétrole Ok c po ce que tu voulais savoir   ok je sors

 
pourtant j'me disais en precisant ds un proc ça va viter cette reponce... mais non  

||||||||||||||||||||||||||||||||  

burgergold a écrit a écrit : ||||||||||||||||||||||||||||||||

 
ha oui je comprends mieux merci    

Tu vois le travail à la chaine dans une usine ? Ben c'est pareil.
Au lieu qu'une équipe fabrique une voiture de A à Z, il y a plusieurs postes, chacun spécialisé dans une tache. Et un poste commence à travailler sur la voiture suivante alors que la voiture précédente n'est pas encore arrivée en bout de chaîne.
 
Il se passe exactement la même chose pour un proc. Il commence à décoder une instruction (traduite en micro-instructions), puis commence à décoder la suivante alors que les niveaux suivants du pipe-line exécutent les micro-instructions, puis enregistrent le résultat.
 
Ca pose pas mal de problème, par exemple :
- s'il y a un saut qui n'avait pas été anticipé, le proc à commencer à décoder et exécuter des instructions qui en fait ne servent à rien. Et il doit recommencer au bon endroit. La perte est d'autant plus importante que le pipe-line est long (cas du P4)
- problème lorsque le proc commence à exécuter une instruction qui utilise le résultat de la précédente alors que celle ci n'est pas encore terminée

 
k merci ...

 
bien dit ! t'es prof toi ?  

randoom a écrit a écrit :     bien dit ! t'es prof toi ?

Nan.
 
Mais c'est vrai que y a pas mal d'enseignants dans ma famille