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