Les choses sont un peu plus complexes que ça, tout de même. La tendance en Osdev n'est toujours pas au retour à l'assembleur qu'on nous prédit depuis de longues années déjà. L'Osdev, comme l'IA, connaît des modes, et conséquemment des retours de mode qu'il est facile de mal interpréter. Ainsi, la mode a été, pendant une grande partie des années 80, jusqu'au début des années 90 - jusqu'à Chorus, Amoeba, ... - au dépérissement des noyaux (si je puis employer cette analogie) : micro-noyaux bien sûr, mais aussi exo-noyaux, nano-noyaux, OS « structurés verticalement », etc. Et évidemment, comme toute mode, on s'emballe, et on finit par être déçu. Du coup, nos prophètes préférés nous annoncent la mort des micro-noyaux, choix idéologique dépassé. Le travail important qui a été fait par le regretté Jochen Liedtke sur L4, relayé par de nombreux autres, la place qu'il a occupée pour ce travail chez IBM me semble montré qu'on est allé un peu vite en besogne.
Il en va de même pour les langages en Osdev. La deuxième moitié des années 1990 a connu une vague de mode des langages « haut niveau », dont on voit encore les traces aujourd'hui. D'où une prolifération de JavaOS, mais aussi d'OS écrits entièrement en C++, entièrement objets, à base de templates, etc. On finit par se rendre compte que la tentation du « langage unique » n'a pas de sens, et du coup on a tendance à délaisser les langages plus haut niveau en Osdev. D'où une vague de retour aux langages plus bas niveau. Le retour en assembleur est très minime, puisqu'il pose de nombreux problèmes.
Je pense que le choix de C++ comme langage pour L4Ka::Pistachio est un choix équilibré et raisonnable en fonction des objets que l'équipe s'est fixé. Le but de L4Ka est de créer une implémentation de L4 qui combine au mieux performances et portabilité. En ce sens, l'assembleur était à exclure. L4Ka s'est aussi fixé comme but celui de créer des abstractions suffisantes pour modéliser de façon efficace, simple et concise les fonctionnalités que doit implémenter le micro-noyau. Ils ont jugé le C++ les aiderait à clarifier ces abstractions, et à rendre l'API plus simple. Pour éviter la perte de performances en contrepartie, le choix a été fait de se limiter à un sous-ensemble étudié du C++ : pas de « virtual », pas de templates, très peu d'héritage, rien de dynamique (bien évidemment !). Dans les faits, on se rend compte que les performances sont au rendez-vous, et la clarté aussi.
On peut ensuite discuter le choix du langage. Je n'aurais pas fait le même choix. Mais comme répond la FAQ de L4Ka::Pistachio à la question « Pourquoi est-ce codé en C++ ? » : « it just is. »
[^] # Re: a contre courant
Posté par Manuel Menal . En réponse à la dépêche Site de HurdFR de nouveau disponible. Évalué à 8.
Il en va de même pour les langages en Osdev. La deuxième moitié des années 1990 a connu une vague de mode des langages « haut niveau », dont on voit encore les traces aujourd'hui. D'où une prolifération de JavaOS, mais aussi d'OS écrits entièrement en C++, entièrement objets, à base de templates, etc. On finit par se rendre compte que la tentation du « langage unique » n'a pas de sens, et du coup on a tendance à délaisser les langages plus haut niveau en Osdev. D'où une vague de retour aux langages plus bas niveau. Le retour en assembleur est très minime, puisqu'il pose de nombreux problèmes.
Je pense que le choix de C++ comme langage pour L4Ka::Pistachio est un choix équilibré et raisonnable en fonction des objets que l'équipe s'est fixé. Le but de L4Ka est de créer une implémentation de L4 qui combine au mieux performances et portabilité. En ce sens, l'assembleur était à exclure. L4Ka s'est aussi fixé comme but celui de créer des abstractions suffisantes pour modéliser de façon efficace, simple et concise les fonctionnalités que doit implémenter le micro-noyau. Ils ont jugé le C++ les aiderait à clarifier ces abstractions, et à rendre l'API plus simple. Pour éviter la perte de performances en contrepartie, le choix a été fait de se limiter à un sous-ensemble étudié du C++ : pas de « virtual », pas de templates, très peu d'héritage, rien de dynamique (bien évidemment !). Dans les faits, on se rend compte que les performances sont au rendez-vous, et la clarté aussi.
On peut ensuite discuter le choix du langage. Je n'aurais pas fait le même choix. Mais comme répond la FAQ de L4Ka::Pistachio à la question « Pourquoi est-ce codé en C++ ? » : « it just is. »