Gwenole Beauchesne a écrit 188 commentaires

Le SATA VIA 8237 marche depuis la 9.2 pour AMD64. Si tu es abonné club silver ou supérieur, tu peux télécharger les ISOs. La version 9.2 pour IA-32 originale ne gérait effectivement pas ce chipset.

Je ne pense pas, d'où le "T" supplémentaire dans INSAT. D'ailleurs, je pense qu'il n'y a que Strasbourg comme nouvel établissement de l'INSA.

Les seules applications 32-bit sont OpenOffice.org et les bootloaders. Ca fait un moment que Mozilla tourne sur AMD64 (plus d'un an et demi). Pour OOo, par manque de temps et de place disque, mon dernier patchset ne fait que 8K lignes et les bridges étaient partiellement broken. Mais des gens ont rescucité cela et forward porté dans une branche de la 1.1.

ÀMHA, c'est un faux problème. Les full source code licensees (e.g. SuSE) ont toujours la condition que la version binaire qu'ils distribuent passe encore totalement la TCK (Test Compatibility Kit, IIRC). i.e. les binaires produits doivent être conformes à la version de Sun. L'avantage pour eux, est de compiler la JVM avec un autre compilateur que gcc 3.2.2 utilisé chez Sun, e.g. gcc3.4.

En somme je pense qu'ils pourraient releaser les sources réellement et se concentrer plutôt à renforcer la TCK?

La JVM de Blackdown et de Sun est la même. En fait, Blackdown a initialement réalisé le portage pour Linux. Les modifications de Blackdown sont généralement reconduites dans la version de Sun suivante.

La version Alpha s'en est sortie un peu mieux surtout grâce à Digital/DEC qui a fourni FX!32, offrant ainsi accès à une pagaille d'applications.

Non, demande au support NVIDIA de fournir une couche d'ioctl32 dans leur module kernel propriétaire. Pour certains jeux par contre (e.g. Quake 3), il est possible de s'en sortir un peu avec __GL_FORCE_DIRECT=0.

uintptr_t, intptr_t. cf. ISO C 9899:1999.

La compatibilité assembleur n'est pas directe.

Généralement, sur des systèmes 64-bit, le modèle qui prévaut est LP64, i.e. long/pointer stockés sur 64 bits. Sur des sous-systèmes comme Windows 64, ils ont choisi LLP64.

L'Itanium II, de préférence Madison généreusement pourvue en cache, est une bête de calcul avec les bons outils. cf. par exemple à Solutions Linux sur le stand Unika où l'on pouvait voir de l'IA-64 vs. cluster de P4.

Sur AMD64, tu n'as pas besoin de faire de traduction de code à la volée comme sous IA-64 avec IA-32 EL. C'est au kernel de supporter les syscalls/signaux/etc. 32-bit. Le code du programme ne bouge pas.

<http://www.intel.com/technology/64bitextensions/faq.htm>(...)

Je ne sais pas trop comment benchmarker/paramétrer mais ça tourne à environ 40 fps avec tout un tas de bots en mode "spectacte" sur un amd64 + Quadro FX1000. En d'autres occasions, ça fait du 120 fps. M'enfin bon, je sais pas comment ça marche UT2004.

Il existait bien un line (http://line.sourceforge.net/(...)) avec des bouts de cygwin pour un runtime POSIX mais il semble avoir mourru, i.e. pas de mise à jour depuis quelques années.

Pas tous. En fait, il existe des programmes modulaires dont la base est GPL mais avec des exceptions pour mettre la mise en oeuvre de plugins propriétaires. C'est le cas par exemple pour SID et eCOS, IIRC.

Il ne serait pas étonnant qu'ils aient différentes versions dispo sur x86. À l'époque, il existait une version du System 7 pour x86, aka StarTrek. Mais je pense que cela ait plus affaire à un groupuscule qui le développe sur leur temps libre juste pour le fun plutôt qu'un projet soutenu par leur employeur.

BTW, peut-être le nom de code que tu cherchais est-il "Marklar"? Ma mémoire ne se souvient pas de l'orthographe exacte cependant.

Le gain de l'AMD64 est surtout le nombre de registres étendu et une ABI mieux pensée.

La JVM de Sun (HotSpot) est écrite en C++. Ils compilent maintenant les versions Linux avec GCC 3.2.

Ouais, un jour ils apprendront le langage avant de programmer quelque chose. i.e. Écrire quelque chose de portable en fait. Bon je trolle car de nos jours c'est normalement corrigé. ;-)

Non, prelink pour la 10 peut-être. Y'a d'autres choses à fixer avant.

Bah, il me semble que les académiciens ont cédé pour les deux écritures. J'ai même vu des "professeure" et "défenseure", c'est dire...

Non, le FDIS n'est pas librement redistribuable. Tu peux le télécharger sur le site du groupe de normalisation (WG21 je crois) modulo le login/pass idoine. Sinon, il est disponible en PDF chez l'ANSI pour 18 USD seulement.

Le code morphing est un terme marketing pour désigner de la traduction dynamique de code. i.e. un bloc d'instructions source (genre m68k) est converti en une séquence d'instructions du processeur cible (genre x86).

Dans le cadre d'un interpréteur type "inline threaded", au lieu de générer une séquence de labels gérant une opération donnée ("direct threaded"), on copie tout simplement le code correspondant au traitement de l'opération. Ce code est statique. Par contre, il y a un assemblage dynamique de ces bouts de code.

Au lieu de sortir un exemple pourri à la va-vite, j'ai retrouvé un mini programme de test illustrant ces concepts.
http://www-sor.inria.fr/~piumarta/pldi98/vm.c(...)

Bien sûr, le lecteur consultera son article pour de plus amples informations. Je crois qu'Objective Caml utilise ce mode d'interprétation. Idem pour SableVM.

Sinon, il y a aussi qemu à voir, il reprend ces techniques de manière plus générale pour écrire un JIT compiler simple{,ment} mais très portable.
http://fabrice.bellard.free.fr/qemu/(...)

La traduction française de la news est foireuse. "The bytecode interpreter is now direct threaded and thus faster" new veut pas du tout dire "L'interpréteur java intègre directement les threads et est donc plus rapide." Direct threaded code est une technique de simulation de code visant à stocker des pointeurs directement vers le label débutant un handler d'opcode. Par exemple: #include <stdio.h> #define DISPATCH_NEXT(ip) goto **ip++ int main(void) { void *prog[] = { &&add, &&sub, &&stop }; void **ip = prog; DISPATCH_NEXT(ip); add: printf("add\n"); DISPATCH_NEXT(ip); sub: printf("sub\n"); DISPATCH_NEXT(ip); stop: printf("stop\n"); return 0; } C'est une vieille technique, c.f. un article de Bell73 par exemple. De nos jours, la variante est améliorée en copiant carrément le code. Voir notament "Improving direct threaded code with selective inlining" de Ian Piumarta, 1998 (titre de mémoire, approximatif). Plus récemment, voir qemu de Fabrice Bellard.