C'est la question que je me pose.
 
Les registres actuels de nos procos sont en 32 bits ( %eax, %ebx ... ).
 
Pourtant, la SDram est en 64 bits.
 
Donc si on fait une operation en lecture, on lira 64 bits d'un coup... vu la largeur du bus.
 
Donc de deux choses l'une :
 
-Soit on utilise que 32 bits sur les 64 qui arrivent, auquel cas, comme la memoire ne supporte qu'une operation a la fois, il ne sert a rien d'avoir un bus 64 bits, un 32 bits aurai suffit .
 
-Soit on mets le contenu des 64 bits dans deux registres en meme temps, et ainsi on peux recuperer deux fois 32 bits en une seule lecture.
 
De plus, on bosse sur des variables 64 bits ( les flottants version double). Donc autant je comprends qu;en plusieurs passages dans l'ALU 32 bits on puisse faire des caculs 64 bits, lents, mais on les faits, mais je comprends tjs pas comment ecrire dans deux registres en meme temps...
 
Si une telle instruction existe, vous pouvez me filer son nom ? Juste pour ma culture personelle...
 
Bref, le probleme est interessant
 
Merci
 

le CPU gère 4 octets par cycles (32 bits)
 
or un octet a une addresse 32-bits, donc il faudrait 4*32=128 bits comme largeur de bus
 
pour l'instant on utilise 64, avec la cache du CPU ça marche correctement

 
Heink ?
 
Et si tu dis : " je veux un lecture a partir de l'adresse 10", il te renvoie 8 octets a partir de la ( largeur de bus 64 bits oblige ) donc tu as ton info 64 bits, de laquelle tu n'utilisera que 32 bits au cas ou.
 
Ton coup d'adressage je capte pas jesus...
 
Je vois pas ce que tu veux dire...
 
Tu va pas lire 4 octets differents dans la memoire hein, tu lis 4 octets contigus quoiqu'il arrive...

Les données ne passent pas de la mémoire vers les registres, mais de la mémoire vers le cache L2.
Le cache L2 est organisé en "lignes" d'une longueur définie. Si celle-ci font 128 bits, ca signifie que le processeur aura dans son cache L2 un ensemble de blocs de longueur 128 bits.
Mais ensuite, il peut ne prendre qu'une partie de ces lignes pour les mettre en L1 puis vers les registres.
 
Un article sur le L2 du P4 :
http://www.x86-secret.com/articles/cpu/p4/p4-11.htm
 
La longueur des lignes de cache du L2 est de 128 octets. Donc, le proc lit des blocs de 128 octets depuis la RAM. Chacune de ces lignes correspond à 2 blocs de 64 octets pour le L1.
 
Faut lire ici aussi :
http://www.onversity.com/cgi-bin/p [...] ts&P=a0900

j'aime bien les topcs de ce genre  
Continuer les gars

un transfert ne se fait pas forcement à la largeur du bus, il est sencé y avoir des instructions de transfert 8, 16, 32 ou 64 bits au choix
 
enfin ça c'est qd j'ai appris l'assembleur, maintenant si ça a changé...
 
La taille du bus mémoire et celui du CPU en gestion mémoire est indépendante, sur pentium par exemple il y a eu 16-bits (SIMM 72 broches) 32 (FPM 72 broches) et 64 (EDO 72 broche en paires)

Tetedeiench a écrit a écrit : C'est la question que je me pose.   Les registres actuels de nos procos sont en 32 bits ( %eax, %ebx ... ).   Pourtant, la SDram est en 64 bits.   Donc si on fait une operation en lecture, on lira 64 bits d'un coup... vu la largeur du bus.   Donc de deux choses l'une :   -Soit on utilise que 32 bits sur les 64 qui arrivent, auquel cas, comme la memoire ne supporte qu'une operation a la fois, il ne sert a rien d'avoir un bus 64 bits, un 32 bits aurai suffit .   -Soit on mets le contenu des 64 bits dans deux registres en meme temps, et ainsi on peux recuperer deux fois 32 bits en une seule lecture.   De plus, on bosse sur des variables 64 bits ( les flottants version double). Donc autant je comprends qu;en plusieurs passages dans l'ALU 32 bits on puisse faire des caculs 64 bits, lents, mais on les faits, mais je comprends tjs pas comment ecrire dans deux registres en meme temps...   Si une telle instruction existe, vous pouvez me filer son nom ? Juste pour ma culture personelle...   Bref, le probleme est interessant   Merci

écrire dans plusieurs registres en même temps je sais pas si c'est possible.
par contre le 'data prefetch' stocke plusieurs mots d'avance dans le cache L2 à chaque fois qu'on lit une donnée en RAM.
d'ailleurs la RAM, après un long temps d'accès, peut transférer plusieurs mots à la suite (8 je crois) et c'est grâce au cache qu'on peut exploiter ce débit. sinon ça serait catastrophique comme débit de mémoire.
en gros quand on lit un octet ou un mot, il faut attendre longtemps mais quand on lit le suivant il est souvent déjà dans le cache.
 
sinon avec MMX et 3dnow on peut stocker 2 nombre 32 bits dans un registre 64 bits. 4 avec SSE (registres 128 bits).
sinon pour la fpu x87 on n'écrit pas dans 2 registres en même temps puisque les registres font 80 bits.
d'ailleurs de bus des cpu actuels est 64 bits même si certains registres sont 32 bits.

 
Ouai, mais tu les fait pas en meme temps.
 
Quand tu fait un movb, tu recuperes le resultat de suite.
 
Donc en gros, la memoire te fournit l'info que tu veux + de l'inutile et tu ne ranges que celle qui t'interesse.
 
Tu ne peux pas, par exemple, prendre un word de la memoire et un byte, sauf si ils sont dans la meme case memoire.
 
Tu va devoir les faire les uns apres les autres.
 
En assembleur c;est visible :
 
movb (%ebx),%al
movl (%ecx), %eax
 
Par exemple ( je suis pas sur de ma typo, mais l'idee est la, sur Pentium 1).

 
BINGO !
 
Merci
 
ca correspond a ce que j'ai lu sur le pentium pro.
 
mais, ca ne correspond pas a ce que mon bouquin dit, vu qu'on etudie le pentium I ...

 
       
 
le fait que la ram soit standard, fpm, edo ou même sdram n'a rien à voir avec la largeur du bus mémoire  
 
et le pentium, c'est un bus mémoire 64bits, c'est tout

 
précision : sur les K7, contrairement aux autres procs, les données du L1 ne proviennent pas du L2. c'est ainsi que les duron ont deux fois moins de L2 que de L1

 
tetedeiench parle du bus dépendant de la technologie, ici la SDRAM, et elle est en 64-bits
 
maintenant le CPU lui-même accède à la mémoire en 32 ou 16 bits celon le CPU, et c'est 64 pour le pentium, même sur FPM, je suis d'accord

Tetedeiench a écrit a écrit :     BINGO !   Merci   ca correspond a ce que j'ai lu sur le pentium pro.   mais, ca ne correspond pas a ce que mon bouquin dit, vu qu'on etudie le pentium I ...

ben en fait tout ça évolue lentement mais surement à chaque nouveau cpu. C'est ce qui permet de supporter les coefs monstrueux qu'on a actuellement entre le cpu et le FSB.

ouaip mais bon : Y a t'il des registres 64 bits pour la FPU en dehors des architectures x87 et autres
 
C'est la question qui me tracasse

le fpu des x87 est configurable jusqu'en 80 bits....
 
en fait le fpu est plus subtile...
 
quand tu stockes tes données en float en mémoire, suivant comment le fpu est configuré, ta précision va être étendu sur 64 bits (double) ou 80 bits (extended ?).
 
ce qui veux dire qu'un code qui utilise au maximum les regsitres du cpu en passant au minimum par la ram, maximizera la précision de calcul.
 
par contre il y a une petite subtilité au niveau du codage des flottans dans un fpu x87, en effet dans la norme ieee, les flottants sont codés avec signe+exposant+mantisse, et la mantisse consiste en juste la partie fractionnaire, le 1. est sous entendu.
 
par exemple 1.01111 sera 01111 dans la mantisse...
 
au niveau registre du fpu x87, un J contenant le 0 ou 1 de la partie entière est présent afin de pouvoir calculer avec des valeurs dénormalisées (valeurs ou le 1. est hors d'atteinte de l'exposant).
 
 
 

il me semble que les processeurs alpha possèdent la posssibilité d'encoder les flottans sur 128 bits...

tiens pour l'alpha:
http://www.tru64unix.compaq.com/do [...] CU0006.HTM
 
Tetedeiench >> c'est ce que tu voulais comme style d'info ou pas ?

 
Yaaaaaaaaaaa parfait, surtout l'explication au dessus.
 
Maintenant j'aimerai que tu me dises si j'ai bon.
 
J'ai besoin de lire deux variable 32 bits contigues dans la memoire, le bus proco fait que 32 bits, le bus memoire 64 bits, ok ?
 
Je lance mon instruction de lecture, il va lire 64 bits, les rapatrier quelque part.
 
Ensuite je veux les traiter dans les registres.
 
Va falloir que je face deux instructions CPU pour les rapatrier dans les registres, style %eax et %ebx.
 
J'ai bon ?
 
maintenant, le quelque part ou se trouve les 64 bits, comment ca s'apelle
 
Et est-ce rellement comme ca qu'est utilise le bus 64 bits ? ( je suis en pleine cogitation, c'est pas dans mon quinbou et j'ai pas trouve sur google) est-ce ainsi qu'on lui file une utilite autre que pour les flottants sur 64 bits ?

alors comme il a été expliqué plus haut, la mémoire cache est entre le core et la mémoire (et entre les caches du cpu et la mémoire y'a le chipset qui rajoute des couches..)
 
donc tu fait:
 
mov eax,[esi] ; [esi] pointes sur la mémoire....
 
le cache 1 est ballayé pour savoir si une ligne de cache contiens l'adresse...
si c'est pas trouvé on ballaye le L2 qui est -beaucoup- plus lent (idem on cherche une ligne du L2), si c'est pas trouvé on charge une ligne du L2 depuis la ram....
 
donc en fait le bus de donnée "externe" du cpu (le bus 64 bits), passe par "plusieurs" contrôleurs...
 
donc le bloc de 64 bits que tu cherches est au tout début de l'interface cpu<->chipset<->ram (coté cpu).
 
après le cache L1 est capable d'être accédé par plusieurs pipelines de manière concurrente....
 
donc en gros dès le pentium 1:
 
si tu fais un :
 
mov eax,[esi]
mov ebx,[esi+4]
 
les instructions sont éxécutées en parallèle dans le "MEME cycle d'horloge" car les deux pipelines accèdent en parrallèle au cache L1.
 
ça c'était pour le pentium 1...
 
évidemment depuis le temps, les optimisations internes des cpu font que c'est 3000x plus subtile...
 
mais en fait ce qui "voit" les 64 bits du bus externe, pour moi, c'est la logique de contrôle des caches L1/L2....

pour expliquer un peu mieux la cache...
 
tu fais un mov ou autre à l'adresse 68 (décimal on va pas se faire chier)...
 
mov esi,68
 
mov eax,DWORD PTR[esi]
.....
.....
 
si tes lignes de cache L1 (on va dire que y'a pas de L2) font 32 octets.
 
pour le cache ta mémoire est donc découpée en ligne de 32 octets, ce qui veut dire qu'en accèdant à la mémoire, le cache va charger les données de l'adresse 64 à 96 (octet à 64 inclus octet à @96 exclus pour avoir 32 octets)...
 
et l'instruction ne pourra être éxécutée que QUAND le DWORD de l'adresse 68 aura été chargé dans le cache (et pas avant).
 
ce qui veut dire que le pipeline est bloqué en attente que la ligne de cache soit chargé (suffisamment pour accédé au DWORD concerné)...
 
------------------------
 
Par contre tout l'espace mémoire n'est pas -cacheable-
comme la ram vidéo des cartes graphiques et les registres de configuration des périphériques qui peuvent être "mappés" en mémoire, et là tu passe par un système de buffers...

mais disons que tu as:
un contrôlleur au niveau bus de donnée qui accède au reste via le FSB de 64 bits...
un contrôlleur pour le cache L2 entre le L2 et le contrôlleur bus FSB...
un contrôlleur pour le cache L1 entre le L1 et le L2...
 
et une logique entre le "core" d'éxécution du cpu et le L1...
 
pour les accès non cacheables, le "core" s'adresse directement au contrôlleur FSB....
 
et y'a les cas particuliers.....
 
mais le BUS 64 bits du FSB est ........... "loin" du core et des pipelines, et le FSB du CPU est ........ "loin" de la ram, car le chipset peut cacher plein de choses (sdr,ddr,rambus(16bits à haute fréquence),double ddr, double rambus)...
 
----------------
 
après tu as le MMU et la pagination qui s'immice dans tout le bordel...
 
puisque les "applications" sont codées en adresses linéaires/virtuelles, et le MMU remets ça en adresse physique, et ensuite les caches L1/L2 & le bus externe sont consultés....

ensuite pour subtiliser encore plus le bordel.....
 
tes instructions:
 
mov eax,...
mov ebx,...
 
elles-mêmes sont des accès mémoires    
 
ce qui veut dire que phylosiphiquement, quand tu fais:
 
mov eax,DWORD PTR[68]
 
le cpu "doit" charge les instrucions, puis charge les données...
 
les vieux CPU sans caches (6809...), se tapaient les accès mémoires pour le code et les données demandés par le code...
 
 
en prenant ton code à l'adresse 10000
et le données à l'adresse 20000
 
sur les systèmes actuels à cache L1/L2...
 
le L2 est unifié: en gros quand le cpu demande le code ou les données y s'en fout y stoque.
 
le L1 est généralement à architecture HARVARD, ou on sépare le code et les données....
 
--------
 
le cache donnée:
 
est du point du vue "core" d'éxécution en lecture/écriture....
 
logique, sinon il sert à rien...  
 
Mais l'écriture ne se fait que si la ligne contenant la destination est contenue dans le cache (sinon ça part voir dans le cache inférieur =>L2).
 
Sauf à partir du pentium pro (donc valables pour le p2/p3/p4 & athlon) qui lors d'une écriture en ram, et que la ligne n'est pas chargé, charge automatiquement la ligne en cache pour les écritures ultérieures profitent de la bande-passante du cache.
 
------------
 
pour le cache code:
 
lecture uniquement !!!
 
en fait comme le core d'éxécution du cpu peut en général exécuter plusieures instructions en même temps, il faut pouvoir accéder de manière très "concurrente" au cache code...
 
on a donc "sacrifié" la possibilité d'écrire dans le cache code...
 
donc les "octets" du code peuvent monter du L2 au L1...
 
mais si le cpu écrit dans une zone mémoire correspondant à une ligne du cache code, la ligne est invalidée, l'écriture par dans le L2 ou la ram, puis le L1 re-lit la ligne depuis le L2 ou la ram...
 
 
expliquation:
 
si tu fait un (pour rigoler on sait jamais):
 
inc [@code polymorphique]
....
...
...
code polymorphique: cmp eax,ecx
 
la ligne de cache contenant la zone de code ou y'a l'écriture sera purement & simplement giclée pour être rechargée depuis le L2 ou la ram...

subtilité à connaitre si on programme sur un machine bi ou multi-processeur:
 
dans le cas ou tu veuilles pour accélérer le calcul d'un appli, faire ton calcul avec deux ou plusieurs threads qui tourneront donc sur deux ou plusieurs cpu qui accèdent à la même mémoire:
 
code en C:
/////////////////////
 
int état_thread1;
char bidul;
float frags_per_seconds;
int état_thread2;
 
 
// routine du thread1
start1(long param)
{
 for(.....) // boucle de traitement
 {
  utilisation de "état_thread1"
 }
}
 
// routine du thread2
start2(long param)
{
 for(....) // boucle de traitement
 {
  utilisation de "état_thread2"  
 }
}
 
////
donc si les variables (ici globales)
 
état_thread1, bidul, frags_per_seconds, état_thread2
 
sont déclarées avec une proximitée telle qu'elles sont dans la même ligne de cache....
 
et que start1 est éxécuté par le CPU0, et start2 est exécuté par le CPU1...
 
si les routines utilisent les variables en lecture =>
ok pas de problème il y a une copie de la ligne dans chaque CACHE de chaque CPU.
 
si les routines utilisent les variables en lecture/écriture =>
, les caches du CPU se jettent à la figure la ligne mémoire contenant les varibles, et les performances que l'on attendait à progresser s'écroulent misérablement....
 
parceque les cpu passent leur temps à:
 
cpu0 charge la ligne en cache depuis la ram
cpu1 idem
 
cpu0 la modifie et la garde  
 
cpu1 veut modifier la ligne
     beuh elle est plus à jour
 
cpu0 écrit la ligne en ram
 
cpu1 la lit
     la modifie
 
cpu0 à son tour refaire des trucs avec...
 
et blam t'explose les FSB de transferts....
 
resultat saturation & performances en multi-cpu inférieures à du mono-cpu....
 
///////
 
donc attention danger, en multi-thread répartis sur plusieurs cpu, à ne pas accéder des données se trouvant dans la même ligne de cache.... sinon caca les perfs...
 
//////////
//////////
 
ça va j'ai pas trop dérivé ?
 
désolé si je suis out ou que j'ai dit des conneries....

interessant ...
 
bjone, si un jour t'as envie d'écrire un truc sur onversity, fais moi signe

là tout en bas l'histoire du cache code en lecture seule:
http://inp.cie.rpi.edu/~cmaier/phdthesis/Chapter1.html
(tiré de là: http://inp.cie.rpi.edu/~cmaier/phd [...] tion.html)

barbarella a écrit a écrit : interessant ...   bjone, si un jour t'as envie d'écrire un truc sur onversity, fais moi signe

 
merci  

/mode je_me_fais_plaisir on
 
alors par contre détail drôle:
 
le:
 

 
 
donc si la modification du code, entraine le giclage de la ligne conservée hors du cache code du L1...
la modification est donc prise en compte et le nouveau code sera éxécuté.
 
Mais, le pipelines & co, ont des buffers de partout etc,etc et pour le chargement des instructions, il y'a un système de prefetch qui faire des truc très drôle....
 
par exemple:
 
inc BYTE PTR[@yopla+6]
yopla: mov eax,[4654564564]
 
alors là on a un cas où une instruction modife sa suivante immédiate.
 
la ligne de cache va être trashée, et le code mis à jour.
 
MAIS l'instruction suivante, le "mov eax..." qui sera éxécuté sera l'ancienne et non la nouvelle...
 
pourquoi ? parce dans la queue de prefetch des instructions c'est toujours les octets de l'ancienne instruction qui reste... (malgré que la ligne de cache aye été invalidé).
 
je ne sais pas si c'est toujours valable pour les cpu actuels (en tant cas ça marchait pour les 286,386,486 c'était une technique de detection cpu, vu que chaque cpu avait une taille de queue de prefetch plus grande).
 
par exemple ça peut servir de technique anti-debugage...
 
faire un:
 
add [yopla+4],789 ; modification de l'adresse 00542354h
@yopla: call 00542354h
 
en effet dans la foulée le CPU exécute le "call 00542354h" non modifié, mais si avec un debugger logiciel on exécute le programme pas à pas, la queue de prefetch est "vidé" par le debugger logiciel, et c'est le call modifié que le cpu éxécutera
 
et on peu deviner ce que le call à l'autre adresse pourrait faire
 
/mode je_me_fais_plaisir off

autre lien sur un "vieux" document (pentium 1, pentium pro, pentium 2):
 
http://www.agner.org/assem/pentopt.zip
 
y'a des explications sur les contraintes des caches, des unitées de prédilection de branchement, etc,etc...
 
mais attention retournement de cerveau assuré...

bjone, merci, j'ai tout capte
 
J'ai eu ma reponse

excellent comme méthode!

tetedeiench>> tu veux des informations précises sur le Pentium 1 ?

 
Ben je pense pas que ce soit la peine en fait
 
Car bon c'est un peu ce que je vais apprendre pendant ce semestre... mais bon si tu en as sous la main pourquoi pas, mais te casses pas trop le cul non plus
 
Disons que dans ma representation mentale dun truc j;ai legerement omis le cache, et surtout je pensais pas que le CPU ne faisait appel QU'AU cache.
 
Je pensais qu;au cas ou l'info etait pas dans le cache ce bon vieux CPU se tapait encore l'acces memoire...
 

 

je m'étais bien marré en désactivant le cache de mon P166 : duke3D qui ramait en 320x200
 
tout de même... on lit partout que le cache contient les informations les plus fréquemment utilisées. ce serait inexact?
 
ou alors le fait que le CPU n'accède qu'au cache, est-ce vrai pour les deux types de cache (instructions et données) ou seulement pour le cache d'instructions?
(peut-être que la réponse est dans les écrits caballistiques de cette page mais bon... même Kant ou le bouquin de physique quantique que j'ai lu dernièrement sont plus compréhensibles )

Blazkowicz a écrit a écrit : je m'étais bien marré en désactivant le cache de mon P166 : duke3D qui ramait en 320x200   tout de même... on lit partout que le cache contient les informations les plus fréquemment utilisées. ce serait inexact?   ou alors le fait que le CPU n'accède qu'au cache, est-ce vrai pour les deux types de cache (instructions et données) ou seulement pour le cache d'instructions? (peut-être que la réponse est dans les écrits caballistiques de cette page mais bon... même Kant ou le bouquin de physique quantique que j'ai lu dernièrement sont plus compréhensibles )

Je dirais plutôt : les dernières données utilisées. Et même un bloc contenant ces dernières données,avec celles qui sont à côté.
En règle générale, je pense que tout ce qui est traité par le CPU passe (et y est stocké) par le L2 puis le L1 (sauf AMD qui utilise les 2 de manière exclusive). Y a peut être des exceptions (les données pour les unités vectorielles ?).

alors attention:
 
le cpu peut tourner sans le cache....
 
mais quand le cache est activé, dès que tu fais un accès mémoire sur un espace cacheable, le cache L2 et L1 sont automatiquement mis à jours, et les accès ram générés sont donc dépendants de la taille des lignes de mémoire cache (et ça influe aussi sur l'adresse de départ de "lecture" dans la ram, vu qu'il faut que ce soit aligné sur une ligne de cache).
 
et généralement tout est conçu pour coincider:
 
si tu prends un cpu qui des lignes de cache de 32 octets, ça fait 256 bits, le bus 64 bits du FSB et la ram feront donc en général une rafale de 4 accès 64 bits....
 
donc le donc cache influe sur l'ensemble dès que c'est un espace cacheable.... (mémoire)

et la cache a deux fonctionnalitées:
 
1) ok il sert à redonner des informations déjà utilisées avant, ça c'est connu.
 
2) le moins connu mais souvant PLUS IMPORTANT:  
 
quand tu fais un accès mémoire avec un traitement "long" indépendant de la ram, comme le cache fontionne par ligne, pendant que les pipelines bossent, la ligne de cache du cpu continue à être pompée de la ram, et tu as donc un recouvrement de temps...
 
donc si tu prends un exemple ou tu fais un traitement sur tous les éléments d'un tableau, pendant que les pipelines bossent sur un élément, la ligne de cache continue a se charger indépendamment, et quand le traitement sur le premier élément sera terminé, l'accès mémoire sur le suivant sera ptet déjà terminé.
 
 

et si tu fais un accès mémoire qui est à cheval sur deux lignes de cache, par exemple:
 
cpu avec ligne de cache de 32 octets..
 
tu fais un accès DWORD (32bits) à l'adresse 30 décimal...
(donc 30 à 33 inclus)
 
donc l'accès en mémoire se fera à "cheval" sur les lignes qui serait de 0000 à 0031 inclus et de 0032 à 0063 inclus...
 
(et les 2 lignes ne sont pas en mémoire cache)
 
le cpu (dumoins le pipeline) devra donc attendra que la ligne de cache 0000-0031 se soit complètement chargé de la ram, et la ligne de cache 0032-0063 commençe....
 
là on a un cas défavorable le cpu est bloqué (pour 4 octects à lire, il faudra attendre que 32(1ère ligne)+2(2ième ligne) soit lus de la ram pour que l'éxécution continue)....

tetedeiench >> si tu veux des infos sur le Pentium 1, tu va chez intel > developer > literature > dans les manuals tu cherches un "Intel Architecture Optimization Manual" référence 242816-003.
 
beaucoup de choses sont décrites sur le Pentium 1 et le Pentium Pro.