Gwenole Beauchesne a écrit 188 commentaires

Par défaut, oui.

Le PowerPC étant RISC, on ne peut pas vraiment dire que son jeu d'instruction soit réduit. Je pense plutôt que nos jours RISC vs. CISC concerne notamment si l'architecture est de type load/store ou non. i.e. le ppc n'a que des load/store et le x86 (obsolète) a une foison de modes d'adressage pour ses instructions.

OOo crée dynamiquement des objets et les vtables associées. De plus, il faut naturellement respecter l'ABI pour les conventions d'appel de fonctions notament. En gros, dans OOo, un objet peut être converti en une forme intermédiaire (UNO) et il faut donc gérer les appels de méthodes de C++ -> UNO -> C++ (il peut y avoir du UNO -> Java, mais ce dernier étant stack oriented...). Comme du CORBA par exemple.

En pratique c'est un plus tricky à gerer que les bridges Mozilla (xptcall), ou Kaffe (sysdepCallMethod), etc. Pour un autre exemple concret, il faut faire ce que fait libffi (foreign function invocation).

En pratique encore, il y a déjà des patches pour le faire pour OOo mais certains tests segfaultent pour l'instant, mais je n'ai pas plus regardé cela récemment non plus, et les versions dispos dans IssueZilla ou le CVS MDK ne sont probablement pas à jour.

Comment ça pas assez génériques? Tous les 16 registres peuvent être adressés indiféremment en 8, 16, 32 ou 64-bit de valeur. e.g. t'es plus limité à %al, %bl et al. pour du 8-bit.

Par ailleurs, l'ABI spécifie que toutes les opérations en virgule flottante passent par l'unité SSE2 pour une précision single et double. Pour une précision de 80-bit, la vieille et pourrie stack FPU x87 est toujours dispo.

Le bénéfice est réel notament car l'ABI est mieux fouttue, et le nombre accru de registres disponibles.

Non, le nouvel allocateur de registres n'est inclu que dans gcc3.3 comme test. Il se trouve juste que SuSE dispose d'une version avec le backport nécessaire pour gcc3.2.

IBM et l'université de RICE (enfin l'université qui hébergeait Briggs) ont concédé une exemption de royalties sur les technologies utilisées. En pratique, la variante implémentée diffère de ce qui était initialement prévu. Note aussi que l'actuel allocateur n'est pas si mauvais sur des merdes comme les x86. Perso, j'avais été surpris par le très faible gain actuel du nouvel allocateur de registres sur x86. Mais cela est amené à changer, la version dans gcc3.3 n'est qu'une expérimentation.

Exact Serge, les drivers Nvidia existent vraiment pour x86-64. Il est logique qu'ils n'apparaissent pas encore sur le site de Nvidia. Encore heureux qu'ils ne commencent pas à développer que quand le processeur sort. Enfin, j'espère pour eux. ;-)

Ils oublient COCA et son langage de requêtes en Prolog. C'est cool et puissant. Pas vrai Pascal? ;-)

dont la partie qui concerne les ajustements dans l'ABI C++ est décrite par les "(c++) ICE".

Non, ICE = "Internal Compiler Error". Les fixes majeurs d'ABI C++ sont pour le 3.2

Ben non, tous les principaux distributeurs Linux (MDK, RedHat, SuSE, XXX?) avaient demandé à avoir une release de gcc3.2 qui contiendrait les fixes ABI du CVS courant. De fait, il y aurait cette fois-ci un espoir non nul d'avoir quelque chose de compatible quand gcc3.3 sortira. Cela motivé par le fait que ces distributions sortiront toutes vers septembre en gcc3.x based, d'où les délais courts.

BTW, FreeBSD avait également demandé une telle release pour leur version 5.0.

Non, il parlait de Gcj. Le bug que tu décris était du à une mis-optimization de __builtin_memset apparue avec gcc3.1 et corrigée dans la branche pas longtemps après.

Aucun distributeur sérieux n'a shippé de package gcc3.1 sans ce patch, de toutes façons. Donc c'est passé quasi inaperçu. ;-)

Tsssk, tu te mets au troll Pascal? ;-)

Par contre, entre gcc 3.0 et icc 5.0, force était de constater que gcc était à la traine :-(

2x sur certains tests que j'ai faits. 40% sur une appli réelle, genre povray mpi. Ou bien était-ce avec orc 1.0, je sais plus. Ah si je crois que c'était ORC 1.0 (basé sur un snapshot gcc 2.96). Mais en -O2 donc sans IPO. ORC segfaultait en -O3 et icc 5.0 faisait une boucle infine, IIRC.

Il parait que l'on peut compiler le kernel avec icc 6.0 T'as eu l'occasion de vérifier?

Non, pas encore. Le kernel ne va pas builder out-of-the-box car l'assembleur inline avec syntaxe GCC n'est supporté que sur x86. Pour ia64, il faut convertir les templates asm en utilisant les "intrinsics" d'Intel.

Peut-être pour le transformer en serveur d'Office :))

StarOffice sert effectivement de test de l'émulation ia32 pour David Mosberger (développeurs kernel/ia64 chez HP).

Autrement je pense à d'autres applications commerciales dont l'éditeur ne trouve pas intérêt à porter. e.g. Acrobat Reader, Netscape et plugins.

Plus sérieusement, ils ont sûrement prévu d'ajouter une compatibilité x86-64, au cas où... Alors autant ne pas gicler tout de suite l'émulation "x86-32".

Non, tout simplement pour faciliter la migration. De plus la compatibilité ia32 n'est pas extra-ordinairement récente. e.g. pas de SSE2.

Peut-être que des personnes ayant eu accès à la première version des alphas peuvent se manifester?
Il parait qu'aujourd'hui ce sont de bonnes machines.

Les alphas comme tu dis, je comprends comme les protos de stepping serie A (e.g. A2). Ben ceux-là étaient plantagènes paraît-il.

De toutes manières, les distributeurs Linux ne supportent qu'au pire les stepping B3, C0 et les releases effectives.

L'évolution des compilos font que sur la même machine, entre l'année dernière et maintenant, y a eu une nette augmentation de la rapidité d'exécution.

Oui, as-tu pu comparer ORC 1.0 vs. ORC 1.1 et icc 5.0 vs. icc 6.0 ? Pour gcc 3.0.X vs. gcc 2.96 y'a un facteur 20% facile.

Faux. La gamme Itanium HP était composée de deux serveurs (rx4610 et 9610) et d'une workstation(i2000).

Il parlait sans doute de la gamme d'Itanium 2 basée sur le chipset zx1, du côté de HP. SGI développe sa propre gamme aussi je crois (SN1). Idem pour Bull mais bon c'est pas important.

Travaillant sur ce dernier depuis 3 mois

D'ailleurs il est pratiquement silencieux, par rapport aux premiers prototypes BigSur qui avaient à peu près la même gueule mais en plus moche.

Et sincérement, porter la GLib sur un nouveau système c'est _beaucoup_ plus simple que de porter un compilo C++ ou la STL, alors bon...

Ah. Je manque à voir la logique dans ce pseudo-argumentaire. Notament l'incohérente comparaison entre la portabilité de la glib (une bibliothèque) et, diable, un compilateur.

La glib utilise le C, la STL le C++, où est donc le problème?

Pour reprendre tes propos. Euh... Tu sais sur combien de systèmes est porté GCC? Généralement, il y a un compilateur C++ qui vient avec...

on ne peut pas compiler le kernel avec icc

Si, avec la version 6.0.

Aujourd'hui l'architecture x86-32 bits arrive en fin de vie

Ah, content de voir que des gens commencent à ouvrir les yeux à ce sujet. Eût-il été trop osé de dire archi périmée voire pourrie et vieillote? Ahem, faut que j'apprenne à troller. ;-)

celle d'AMD qui décide de garder la compatibilité en étendant les architectures x86-32 bits

C'est un point non négligeable. Marketingment c'est bon. En pratique, x86-64 bénéficie aussi de registres supplémentaires. Ca commence à être décent.

Intel qui parie sur un changement complet et l'utilisation d'une architecture PA-RISC

EPIC qu'elle s'appelle en fait: Explicit Parallel Instruction Computing.

EFI n'est pas spécifique 64 bits. Le problème est juste que je ne le vois effectivement que sur les IA-64. ;-)

tite question, pour profiter pleinement du 64 bits faudra recompile je presume?

Oui, pour profiter pleinement comme tu dis. Autrement, les binaires x86 bâtards habituels marchent très bien. C'est pas comme sur l'Itanium où c'est un tout autre jeu d'instructions et où il faut donc émuler le miséreux x86.

GCC est pret pour le 64 bits?

GCC 3.1 supporte le x86-64 (les gens de SuSE y sont très impliqués). Il y a encore quelques bugs qui ne seront pas inclus dans le tarball officiel du 3.1.0 cependant. Autrement, il y a la mainline (futur 3.2) et même une branche mais je crois qu'elle n'est plus trop utilisée (?).

Sinon avec une distro du genre gentoo et consort ca devrait etre le pied non ? :)

Bof, je ne vois pas pourquoi.

x86-64, comme son nom l'indique, est du x86 "extensé" 64-bit. Il n'y pas de core spécifique à l'exécution 32-bit. Les instructions faisant appel à des opérandes 64-bits ou bien aux nouveaux registres comportent les préfixes dits REX. Dans le x86 bâtard normal, y'avait effectivement des préfixes pour avoir des opérandes 16 bits.

Comme d'hab, voir les docs sur http://www.x86-64.org/(...)

Ce genres d'optimisations sont en expérimentations dans des branches annexes, c'est d'ailleurs à ça que sert les branches. Tester d'autres concepts. Je pense notament au nouvel allocateur de registres, les optimisations au niveau TREEs (AST) au lieu du niveau RTL.

Si, tu peux avoir gcc3.0 et gcc3.1 en même temps, il suffit d'utiliser la libgcc3.1 pour gcc3.0.

Moi j'aurais vu légèrement satanique. cf. les numéros de version-release de XFree86-4.2 par exemple. i.e.

* Fri Apr 12 2002 Mike A. Harris <mharris@redhat.com> 4.2.0-6.666
[...]

;-)

gcc 2.91.66 pour compiler le noyau et pour la compatibilité avec les RedHat 6.x Cela fait longtemps que egcs 1.1.2 n'est plus utilisé pour builder les kernels quand même. De nos jours, c'est plus parti pour gcc >= 2.96-RH. Sur Itanium notamment, le compilo recommendé est bien gcc-3.0.X. Par contre, gcc-3.1.X pour le kernel, ben faut voir, modulo fixes au kernel. ;-) Quoique les kernels x86-64 sont buildés avec gcc-3.1. cf. http://www.x86-64.org/