[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