[gull] Linux sur processeur Core Duo?

[Daniel Cordey]

On Friday 11 August 2006 14:46, Marc SCHAEFER wrote:

> Sont-ce des registres accessibles par le programmeur assembleur (donc il
> faut recompiler tous les programmes en langages plus évolués, et avoir
> le compilateur ad-hoc), 

Oui. tous les compilateurs, dont gcc, ont des flags permettant de preciser 
le "type" de processeur. L'inconvenient de cette pratque est que l'on rend 
alors le code incompatible avec les generations precedentes. C'est donc une 
arme a double tranchant. 


> Et s'il y a trop de registres, il faut ensuite les sauvegarder lors d'un
> changement de contexte, ce qui peut poser des problèmes nouveaux.

Surtout une chute des performances qui varie d'une architecture a l'autre. 
Pour limiter les degats, HP a developpe a develppe son compilateur en 
definissant un Procedure Calling Convention qui determine quels registres 
doivent etre sauves lors d'un appel de fonction. En gros, un certain nombre 
de parametres sont passes dans les registres, de meme que pour la valeur de 
retour (return(x)). Le compilateur optimize l'utilisation des registres dans 
chaque fonction et s'arrange pour ne pas entre en conflit avec les appels 
successifs. C'est un peu complique a respecte lorsque l'on programme en 
assembleur, mais totatelement transparent en passant par le compilateur. 
Naturellement, si l'on optimize sont code pour une architecture determinee, 
il ne sera pas compatible avec les precedentes, car le nombre de registre n'a 
cesse d'augmenter (PA-RISC 1.0, 1.1, 2.0). L'avantage etant un usage tres 
restreint du stack... (ce n'est pas du tout le mode standard de gcc qui ne 
passe aucun argument dans les registres par defaut !)  A contrario, 
l'architecture SPARC a fait le pari du "windowing"; soit des groupes de 
registres commutables. L'avantage etant que le compilateur n'a pas a gerer 
l'utilisation des registres inter-proceduraux, si ce n'est une sorte d'index 
dans la "window". C'est hyper rapide... L'inconvenient est que, comme le 
compilateur ne chrceh pas a optimiser l'utilisation de ses registres, il doit 
tous les transfer aveuglement dans le stack lorsqu'il n'y a plus de "windows" 
a disposition. C'est-a-dire que le nombre de "window" determine 
la "profondeur" des appels de fonctions, avant de devoir passer 
systemqtiquement par le stack. Or, comme les registres "coutent" cher en 
place dans un CPU, cela limite le nombre de "windows" a disposition... 
Quelque soit le nombre, celui-ci n'est pas assez important pour les systemes 
mutli-utilisateurs ou les problemes de recursivite. Raison pour laquelle SUN 
souffre d'un handicap de performance dans les grands serveurs; ce qui 
l'oblige a multiplie les processeurs, etc. pour lutter face a d'autres 
architectures plus efficaces dans ce domaine.

Le compilateur gcc effectue deja un certain nombre d'optimisation de l'usage 
des registres, tout en etant tres attentif a rester compatible avec 
l'architecture employee. Si l'on commence a jouer avec les differentes 
options d'optimisation relatives a l'emploi des registres, il y a plus que de 
tres fortes chances que le code genere ne soit plus compatible avec les 
librairies, le loader, etc. C'est tres dangereux et cela doit etre employe 
uniquement lorsque l'on maitrise bien le confinement de l'execution du code. 
Pour info, il y a 233 fois le mots 'register' dans ma doc de gcc... C'est 
touchy... :-)

dc