[gull] Linux sur processeur Core Duo?

Daniel Cordey dc at mjt.ch
Tue Aug 15 09:13:04 CEST 2006


On Tuesday 15 August 2006 07:13, Marc Mongenet wrote:

> Le code VLIW n'est pas particulièrement interne.
> C'est simplement le type de code des processeurs VLIW
> (Itanium, Transmeta).

Si, dans le cas du x86 -> Itanium, il y a bien une couche de transaltion. Je 
ne me suis jamais penche sur les details, mais je suspecte HP d'avoir utilise 
la technologie deje eprouvee dans PA-RISC, a savoir "du millicode". Le 
millicode n'est pas du microcode, mais du code execute suite a un 'trap'. Ce 
qui expliquerait la lenteur de l'emulation du jeu d'isntruction des x86 sur 
Itanium...

> Mh, j'aurais tendance à penser qu'il n'y a pas le moindre
> microcode dans un processeur VLIW (comme le Transmeta).
> Le but du VLIW, c'est tout de même que le travail soit encore
> plus prémâché par le compilateur que pour le RISC.
> En l'occurrence, c'est le travail de "super-scalairisation" que
> le compilateur doit faire en plus.

EN effet, il n'y a pas de microcode dans Itanium. Le reste de l'explication 
est tout a fait exact.

> Le code généré est effectivement stocké, en RAM par exemple.
> Il peut y avoir plusieurs passes d'optimisation, s'il est dans une
> boucle souvent réexécutée. Il me semble que ce principe de
> passes d'optimisations multiples existent aussi avec les JIT Java.

Le code pure est optimise par le compilateur. ENsuite, l'execution du code et 
de certaines astuces permettent au processeur d'accelerer l'execution en 
evitant des branchements inutiles. C'est le cas de tous les processeurs 
risques avec leurs "branch cache/register" et d'Itanium avec les predicats.

> Oui, en sortant du décodeur, les µops sont stockées dans un
> tampon de réordonnancement qui peut en contenir jusqu'à
> plusieurs dizaines.

Seulement pour les processeurs possedants plus d'unites fonctionnelles que 
ceux de base. Il faut donc au minmum double de decodeur d'instructions, ALU 
et load/store; c'est vraiment le strict minimum. Tous les processeurs RISCs 
n'ont pas de doublement de leurs unites fonctionnelles. Entre autre, pour 
ceux qui ont fait le choix d'un pipeline avec beaucoup de niveaux... Plus il 
y a de niveaux de pipeline, plus il y a d'unites fonctionnelles a dupliquer 
et plus les problemes de synchronisation sont importants. Par exemple, 
certains PA-RISC 2.0 ont 10 unites fonc. CAD que les unites fonc. sont toutes 
doublees; permettant, en theorie, d'executer 2 instructions par cycles (3 
dans certaines situations). Dans le cas d'Itanium, la division d'unites fonc. 
est aidee par le jeu d'instructuion qui simplifie la gestion du sequencement 
et de l'ordonancement. Il y est donc possible de paralleliser des boucles a 
quatre niveaux pour l'instant. Des versions futures d'Itanium pouraient 
monter jusqu'a 32 instructions en //. Je n'ai pas connaissance de ces 
technologies dans les x86/AMD actuels; quelqu'un en sait-il plus sur ces 
processeurs ? Vu les frequences d'horloges des Intels, je doute qu'il aient 
pu se lancer dans cette voie. Il se peut qu'AMD ait integre ces techniques en 
partie.

dc



More information about the gull mailing list