Miod in the middle a écrit 400 commentaires

Et aussi d'une utilité douteuse sur un système qui marche.
Pourquoi pas un ctrg-g qui lance gdb sur le processus et faire le dump de pile tant qu'on y est...

Et pourquoi pas un ctrl-C qui enverrait SIGINT au processus ? Ou ctrl-Z qui enverrait SIGSTOP ?

Ah mince, ça existe déjà...

Quand une applie est bloquée (ou excessivement lente sans retour d'info) ben c'est un bug. Inutile d'avoir ctrl-T pour le savoir.

Pas d'accord. Une application Unix n'a pas à être inutilement verbeuse, surtout quand tu veux pouvoir l'utiliser dans un script, et ce même si son exécution prend du temps (ssh-keygen, par exemple).

Rebol est surtout un langage dans lequel l'évaluation se fait strictement de gauche à droite, sans priorité des opérateurs, sauf si l'on parenthèse.

Ce qui fait qu'en Rebol, l'expression 2 + 3 * 5 a la valeur 25. Pour quelqu'un un tantinet scientifique, c'est très perturbant.

Pour avoir un processus qui donne des informations lorsqu'on presse ^T dans le terminal, c'est tout simple, deux choses suffisent :

- le processus doit gérer SIGINFO et déclencher l'affichage de quelque chose de sensé après la réception de ce signal (ce que fait par exemple fsck, au moins dans le monde BSD) ;
- le terminal doit être configuré pour que ^T provoque l'envoi de SIGINFO au processus. Cela peut se régler par stty, et cela peut également faire partie de la configuration par défaut du terminal.

Bref, tout ceci est trivial et totalement indépendant du système Un*x considéré.

Et dire MP3, ce n'est pas soutenir les brevets de Thomson (ou Fraunhofer, je ne sais plus à qui ils appartiennent exactement) ?

Quelle prévoyance, commander en novembre un cadeau pour le mois d'octobre prochain, ça laisse tout de même largement le temps de le recevoir...

Pourquoi "malheureusement" ?

deltree /Y C:\ ça marche mieux, non ?

C'est normal, la version 4 est installée avec les binaires gcc4, g++4, etc.

Le problème, c'est que le programmeur est humain et donc qu'il commet des erreurs, même s'il est doué.

Ce genre de protection sert essentiellement à sauver la couenne des gens.

Dans un monde meilleur, elles seraient totalement inutiles. Mais malheureusement, le monde étant ce qu'il est, elles sont nécessaires.

Cela ne sera possible que pour les scrutins où le panachage n'est pas autorisé.

Disons plutôt qu'elle est en train de mijoter.

FOUTAISES !

Le seul regret que j'ai, c'est que je ne pourrais sans doute pas y aller, étant donné qu'il y a déja 3h de train vers bordeaux depuis paris, et encore une centaine de km de voiture vers la bas

Il y a aussi des trains allant de Bordeaux à Mont de Marsan, c'est très reposant de traverser les forêts de pins.

J'imagine que ça se déroulera au hall de Nahuque ou à l'espace F. Mitterand.

Et l'auberge Landaise, elle sent le pâté ?

Bof.

Il te faut un écran plus large (ou une police plus petite).

Le calcul de la moyenne a été effectué avec l'un des premiers processeurs Pentium, d'où l'erreur lors de la division.

Seulement s'ils ont un balai dans l'haiku.

Poussez pas, je ---> []

J'ai un peu de temps, je vais donc enfoncer quelques portes ouvertes.

***

Tout d'abord, rappelons que gcc a été l'un des premiers compilateurs C sous licence libre. Et quand je dis "l'un des premiers", soyons sérieux un instant, il n'existait que _deux_ compilateurs libres : pcc, qui était quasiment abandonné sans que personne ne reprenne le navire, et gcc.

Les autres compilateurs étaient non libres (comme lcc) ou n'ont pas réussi à se faire connaître aussi bien que gcc (souvent parce que leur cible n'étaient pas les systèmes de type Unix).

Gcc 1 a donc eu un boulevard pour se développer, et a tout naturellement capté les meilleures compétences. Le vide s'est fait petit à petit, avec les compilateurs propriétaires (mipspro, Sunpro, XLC, etc) d'un côté et gcc de l'autre.

À cette époque, on est encore à la fin des années 1980, les systèmes libres ne pèsent rien du tout.

Un certain Michael Tiemann adapte gcc pour le support du C++ lors de sa thèse à l'INRIA, ce qui provoque l'éclatement de gcc 1 en une conception plus modulaire permettant de gérer plusieurs languages : gcc 2 est né. Tiemann fonde Cygnus dans la foulée.

Vous suivez toujours ? Gcc 2 sort au début de l'année 1992. À cette époque, on commence seulement à avoir des compilateurs C++ solides, qui ne sont plus des compilateurs C avec une surcouche comme l'était CFront, et qui peuvent enfin gérer les constructions les plus complexes que permet le language.

Afin d'aider à asseoir la notoriété et l'utilisation de gcc (et surtout de g++), Richard Stallman impose que les deux parties de gcc (celle qui traduit un des langages supportés en la représentation interne RTL, et celle qui traduit le RTL en du code assembleur) ne puissent pas être disjointes, de façon à ce qu'un vendeur de compilateur propriétaire ne puisse pas utiliser par exemple l'analyseur syntaxique C++ de gcc 2, et mettre son propre générateur de code assembleur derrière.

C'est un choix qui va à l'encontre de la philosophie Unix (qui favoriserait ``gcc-highlevel monfichier.c | gcc-lowlevel | as -o monfichier'' avec un gcc en deux composants distincts), mais qui est compréhensible dans l'optique "pénaliser le code propriétaire à tout prix" du projet GNU.

Par contre, d'un point de vue d'ingénieur, c'est une décision regrettable, ne serait-ce que pour déboguer : tu peux demander à gcc de te "cracher" 30 fichiers de représentation intermédiaire correspondant à 30 étapes d'optimisation, mais tu n'as aucun moyen, lorsque tu crois avoir détecté une erreur à la passe N, de modifier manuellement ce fichier et de le réinjecter à la passe N+1, afin de vérifier ton hypothèse dans le code final.

C'est sur ce point que râle perpétuellement Marc Espie (la partie "perverted design").

***

Un autre reproche, peut-être plus spécifique à OpenBSD, est le choix des plate-formes supportées par gcc. Gcc évolue de plus en plus vite, c'est bien (et ça change du cycle de release entre 2.5.8 et 2.8...), mais du coup il est difficile de suivre quand tu as d'autres choses à faire à côté. Les développeurs de gcc ne testent pas tous toutes les plate-formes pour lesquelles gcc est capable de produire du code (que ce soit en natif ou en compilation croisée), et le résultat est que sur les N plate-formes supportées par gcc, seule une bonne moitié est vraiment fiable, les autres souffrant de bugs par ci par là, qui peuvent très bien être indétectés avant belle lurette, ou produire des erreurs subtiles dans le comportement d'un programme difficile à analyser.

Il y a plusieurs plate-formes où, par manque d'intérêt ou de gens payés pour, le "backend" de gcc est fiable en version N, mais plus en version N+1, soit à cause de bugs bêtes, soit parce que les optimisations plus fines de cette nouvelle version de gcc cassent certaines choses "considérées comme acquises" (comment traduire ``assumptions'' ?) par le code du backend. Pire encore, le backend peut être mal écrit initialement et mal décrire la réalité du processeur.

Dans ce cas, il y a un travail important à accomplir, et de nos jours, à la vitesse où sont introduits dans gcc des changements (nouvelle représentation intermédiaire, nouvelles optimisations, nouveau modèle de gestion du parallélisme) nécessitant des modifications substancielles du backend, il n'est pas possible de suivre si l'on ne dispose pas de beaucoup de temps à consacrer à gcc.

On le voit très bien dans les changelog de gcc ou les backend sont de facto en deux classes : ceux qui sont maintenus, souvent par des personnes payées à plein temps pour le faire par IBM, Apple, Sony ou autres, et ceux pour lesquels les seuls changement visibles sont des changement systématiques (remplacement de VIEIILLE_MACRO() par NOUVELLE_MACRO(), correction de fautes d'orthographe dans les commentaires, extension du copyright à la nouvelle année tous les ans) dont il a simplement été vérifié de temps en temps qu'ils compilent, et aucune autre activité.

C'est une source de mécontentement croissante, parce que justement cela montre que gcc (et plus particulièrement gcc 4) peut de moins en moins être présenté comme supportant autant de plate-formes que par le passé.

***

Le troisième reproche fait à gcc est la lenteur croissante des temps de compilation.

Autant les migrations successives de 2.1 à 2.95 ont conservé des temps de compilation proches, autant chaque version intermédiaire de gcc 3 a impacté les temps de compilation de façon significative (30 à 70% selon les plate-formes, pour un passage de 2.95 à 3.3, les plate-formes le plus affectées étant celles disposant de beaucoup de registres : alpha, hppa, mips, sparc).

Heureusement, 4.1 puis 4.2 commencent à bien digérer le passage à la représentation ssa, et regagnent du temps sur 3.4 (on constate généralement des temps intermédiaires entre ceux de 3.3 et ceux de 3.4, lorsque l'on compile avec 4.2).

Mais, comme je le disais un peu plus haut, il arrive que le support d'une architecture donnée soit absent ou non fiable en 4.x. Voire en 3.x. Donc, faute de moyens (essentiellement en temps), on en reste à gcc 2.95.

Le fait que les développeurs de gcc ne soient pas intéressés pour aider à migrer un backend 2.95 au niveau 3.4 ou 4.x, n'aide pas non plus à la motivation.

***

On en vient alors à "mais s'ils sont aussi mécontents de gcc, qu'ils utilisent donc autre chose !".

Oui, on aimerait bien. D'ailleurs on y pense depuis longtemps, et plusieurs développeurs OpenBSD s'étaient intéressés à TenDRA il y a moult années déjà.

Mais comme je l'ai rappelé plus haut, gcc a fait le vide autour de lui. TenDRA, par exemple, n'était plus maintenu depuis la fin des années 1990, et le groupe qui s'est monté pour le reprendre a surtout réussi à se tirer dans les pattes et à se scinder en deux groupes encore moins actifs.

Ce qui fait la différence dans pcc, c'est qu'il est plus facile de "rentrer" dans le code que dans celui de TenDRA, et que les projets BSD ont de très bonnes relations avec Ragge (Anders Magnusson) à l'origine du renouveau de pcc.

La situation est donc différente : ce n'est plus reprendre un projet dont l'équipe a mis la clef sous la porte, mais c'est s'injecter dans un projet bouillonnant, et qui n'intéresse d'ailleurs pas qu'OpenBSD : sur la liste de développement de pcc, on trouve aussi des gens de DragonflyBSD et NetBSD.

***

Je terminerai en rappelant qu'il est évident qu'il reste beaucoup de travail à accomplir. Pcc n'est pas près de remplacer gcc dans OpenBSD, mais on va essayer de le faire mûrir pendant quelques mois, afin de voir quel effort est réellement nécessaire pour obtenir une alternative viable à gcc.

Ceux qui s'imaginent que c'est pour demain sont de doux rêveurs... tout comme ceux qui s'imaginent que c'est une tâche impossible.

Perdu...

Beaucoup de code du noyau de Linux est dans OpenBSD.

On ne doit pas avoir les mêmes sources.

Peuh, c'étaient les "logiciels du soleil", pas les "logiciels du levant" !

Non, e-diot.

Non, le contrôleur mémoire utilisé sur la carte mère était capable de gérer soit un PPC603 et jusqu'à 1MB de cache L2, soit deux PPC603 mais pas de cache L2.

Intrinséquement, oui.

Cependant, la carte mère des BeBox PPC n'a pas de cache L2, contrairement aux Pentium (et même 486) de l'époque, ce qui se ressent en termes de performances : une BeBox dual-66 n'arrive pas à décoder un mp3 à 44Khz en temps réel (du moins avec des décodeurs en C n'utilisant pas de code assembleur optimisé pour PowerPC).