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 _______________________________________________ gull mailing list [email protected] http://lists.alphanet.ch/mailman/listinfo/gull
