- Configurer son portable pour gagner en autonomie (3ème partie)
- Intel : FSB 1333, quad-core abordable, nouveaux hauts de gamme
- Tout savoir sur le Computex 2007
- Computex 2007 : premières impressions
- Core 2 Duo 4 Mo pour tous : E6420 et E6320
- CeBIT 2007 : que faut-il en retenir ?
- Supreme Commander : quelles performances ?
- Le point sur la virtualisation
- Intel E4300 : le Core 2 Duo pour tous ?
- 2006/2007 vu par la rédaction
-
amd k10
-
amd griffin k10
-
microsoft amd k10
-
amd hester architecture
-
Phenom AMD
-
amd phenom
-
phenom amd x4
-
phenom logo amd
-
AMD Phenom processeur
-
AMD Phenom 9500
-
AMD Phenom barcelona
-
amd phenom fusion
-
AMD Phenom 9850
-
phenom rd790 amd
-
asus amd phenom
-
k8l architecture
-
intel architecture
-
architecture r520
-
phenom x2
-
Phenom FX
Source: Presence PC – Mots-clés : architecture, K10, AMD, Phenom
Catégories: Processeur
- 1 – Introduction
- 2 – Barcelona, une vue d’ensemble
- 3 – Une vue d’ensemble (suite) : réellement nouveau ?
- 4 – Lecture & décodage des instructions
- 5 – Suite : Analogie, prédiction de branchement
- 6 – Amélioration de la gestion de la pile
Amélioration de la gestion de la pile
AMD a également apporté deux autres modifications au front-end de son CPU mais pour bien les comprendre il faut d’abord expliquer le mécanisme d’appel de fonction sur un processeur et plus précisément la pile d’appel. Tout d’abord qu’est ce qu’une pile ? Tout le monde connaît la définition dans le langage courant mais dans le monde de l’informatique cela désigne une structure de données qui permet de stocker des éléments. Lorsqu’on souhaite ajouter un élément à une pile, celui-ci se retrouve à son sommet : on dit qu’on empile (push). Lorsqu’on souhaite retirer un élément, on enlève celui situé au sommet : on dit qu’on dépile (pop). Vous l’aurez remarqué : le dernier élément ajouté est aussi le premier retiré, la pile est une structure LIFO (Last In First Out) par opposition à une file qui est une structure FIFO (First In First Out).
La pile d’appel est donc une pile particulière qui permet, lors de l’appel d’une fonction, de sauvegarder les paramètres de cette fonction, les variables locales mais également l’adresse de retour. A la fin de la fonction un branchement est donc effectué pour redonner le contrôle à l’adresse de retour. Par exemple considérons le pseudo code suivant :
{
f () ;
}
void f ( )
{
g ( ) ;
}
void g ( )
{
print "Vive PresencePC" ;
}
Voilà comment évoluerait la pile d’appel :
Puis :
Puis :
Pour "prédire" la prochaine adresse de retour, les ingénieurs ont donc doté leur processeur d’une pile d’adresses, à chaque appel de fonction elle stocke l’adresse de retour dans un tampon à l’intérieur du processeur. La taille de cette pile d’adresses de retour a été doublée avec cette génération, elle est désormais de 24 entrées contre 12 sur le K8. Lors des longues suites d’appels de fonction le processeur se révèlera donc plus performant en évitant de saturer sa pile interne.
La deuxième amélioration portant sur la gestion de la pile concerne l’inclusion du Sideband Stack Optimizer. Derrière ce nom barbare se cache en fait une unité dédiée à la gestion des opérations concernant la pile (push, pop, call, ret). Là où sur le K8 ces opération devaient passer par le front-end puis par le back-end du pipeline, monopolisant des précieuses ressources, sur le K10 elles sont effectuées par le Sideband Stack Manager.
- Page précédente Suite : Analogie, prédiction de...
- Page suivante Des unités d’exécution remaniées




On voit les efforts de l'equipe d'AMD et cela semble encourageant pour les futures perf' des Barcelona
La question que je me pose est au niveau des jeux d'instructions. Outre les optimisations purement hardware qui sont transparentes du point de vue software, à quel moment le nouveau jeu d'instructions est pris en compte?
Est-ce lors de la compilation avec un linker dépendant de chaque architecture?
Est-ce lors de l'installation du programme sur la machine cible?
Ou est-ce totalement transparent du point de vue du programme tiers et c'est alors l'os qui s'occupe d'optimiser le code pour prendre en compte les nouvelles instructions disponible?
Peut-être est-ce le processeur lors du décodage des instructions x86 qui détecte qu'une émulation possible peut-être faite avec les nouvelles instructions?
Je dois avouer que je ne comprends pas vraiment comment cela ce passe, dans le monde des microcontrôleurs c'est beaucoup plus simple
Ca me rappelle mes cours ou notre prof nous disait, vous voyez vous avez tout en main pour faire un processeur (tout ca parcqu'on arrivait à faire des additionneurs 8bits en vhdl^^)
Alors que la gestion des horloges est indépendantes... maikilsoncon... Il perde une occasion de bien faire descendre la consomation. J'imagine que seul la version portable pourra le faire...
ca dépend des programmes.
Globalement, en général on propose les optimisations à part sur certains calculs, avec le choix dans le programme (soit à la main, rare, soit en détectant si le CPU le fait). C'est surtout sur des programmes qui n'utilisent pas intensivement les instructions en question. On a donc au moins deux versions différentes du code : une SSE (par exemple) et une autre.
L'autre possibilité, c'est de limiter le programme à un jeu d'instruction minimum. C'est rare, parce que du coup ça limite le nombre de CPU utilisables : faut un parc installé important. On a de plus en plus de programme qui nécessitent le SSE(2) actuellement parce que la majorité des CPU actuels le sont.
Sinon, y a les programmes qui proposent plusieurs exécutables : un par type d'instruction, mais c'est chiant pour l'utilisateur.
l'OS n'est pas capable de définir les instructions à utiliser (et n'est en général pas optimisé pour des jeux en particulier) et le processeur n'est normalement pas capable de détecter les instructions.
Pour ce qui est du délai et du saut d'appellation, n'y a-t-il pas eu une architecture K9, abandonnée il y a environ 18 mois pour une cause inconnue ? (manque de performance, problèmes de fabrications, de brevet ?)
l'OS n'est pas capable de définir les instructions à utiliser (et n'est en général pas optimisé pour des jeux en particulier) et le processeur n'est normalement pas capable de détecter les instructions.
i386, i586, i686 ce n'est pas adapter le l'OS à un jeu en particulier ? (bien sur il y a plus de jeux d'instructionsque ca).
Les instructions à utiliser sont également choisit par le compilateur lors de la compilation non ? (bien sur il faut dire au compilateur qu'elles instructions notre proc supporte).
même si je ne comprends pas tout
bravo a l'équipe de PPC.
Ca me rappelle mes cours ou notre prof nous disait, vous voyez vous avez tout en main pour faire un processeur (tout ca parcqu'on arrivait à faire des additionneurs 8bits en vhdl^^)
Ha ben on a eu le même.
i386, i586, i686 ce n'est pas adapter le l'OS à un jeu en particulier ? (bien sur il y a plus de jeux d'instructionsque ca).
Les instructions à utiliser sont également choisit par le compilateur lors de la compilation non ? (bien sur il faut dire au compilateur qu'elles instructions notre proc supporte).
oui, pour Linux, tu peux limiter au CPU minimum, mais c'est pas nécessairement le cas.
les instructions sont choisies par le compilateur en fonction de ce qu'on lui demande, mais tu peux lui mettre plusieurs versions dans le programme (avec un choix, manuel ou automatique)
en général, on a quand même tendance a faire du code le "moins" optimisé possible pour garder une compatibilité correcte : on se limite par exemple au i686 avec MMX (ce qui doit représenter une bonne partie des machines actuelles)
Maintenant, si t'as du code qui va tourner sur une machine que tu connais bien, tu peux optimiser avec ce que le CPU supporte (ex. Gentoo qui peut être compilé en fonction de la machine).
Fraye > Quels passages ne comprends tu pas ?
l'article est trés bien fait et tout et tout..
bonnes explications.. ça se voit
ca vient plus de moi qui même quand il y a toutes les explications possibles
n'arrive plus a suivre techniquement.