Pourquoi les pilotes et les microprogrammes sont-ils presque toujours écrits en C ou ASM et non en C++ ?

Question

Je suis simplement curieux de savoir pourquoi les pilotes et les firmwares sont presque toujours écrits en C ou en Assembleur, et non en C++ ?

J'ai entendu dire qu'il y a une raison technique à cela.

Quelqu'un le sait-il ?

Beaucoup d'amour, Louise

Answer 1

Parce que, la plupart du temps, le système d'exploitation (ou une "bibliothèque d'exécution") fournit la fonctionnalité stdlib requise par C++.

En C et ASM, vous pouvez créer des exécutables nus, qui ne contiennent aucune dépendance externe.

Cependant, comme Windows prend en charge la stdlib C++, la plupart des pilotes Windows sont écrits en (un sous-ensemble limité de) C++.

De même, lorsqu'un microprogramme est écrit en ASM, c'est généralement parce que (A) la plate-forme sur laquelle il s'exécute ne dispose pas d'un compilateur C++ ou (B) qu'il existe des contraintes extrêmes de vitesse ou de taille.

Notez que (B) n'a généralement pas été un problème depuis le début des années 2000.

Answer 2

Le code du noyau s'exécute dans un environnement très différent de celui de l'espace utilisateur. Il n'y a pas de séparation des processus, les erreurs sont donc beaucoup plus difficiles à corriger ; les exceptions sont pratiquement exclues. Les allocateurs de mémoire sont différents, il peut donc être plus difficile d'obtenir des résultats. new y delete pour fonctionner correctement dans un contexte de noyau. La bibliothèque standard est moins disponible, ce qui rend l'utilisation efficace d'un langage comme le C++ beaucoup plus difficile.

Windows permet l'utilisation d'un sous-ensemble très limité de C++ dans les pilotes de noyau ; essentiellement, les choses qui pourraient être trivialement traduites en C, comme les déclarations de variables à des endroits autres que le début des blocs. Ils recommandent de ne pas utiliser new y delete et ne prennent pas en charge RTTI ou la plupart des éléments de la bibliothèque standard C++.

Utilisation de Mac OS X Kit E/S qui est un cadre basé sur un sous-ensemble limité de C++, bien que, pour autant que je sache, plus complet que celui autorisé sous Windows. Il s'agit essentiellement de C++ sans exceptions ni RTTI.

La plupart des systèmes d'exploitation de type Unix (Linux, les BSD) sont écrits en C, et je pense que personne n'a jamais vraiment vu l'avantage d'ajouter le support C++ au noyau, étant donné que le C++ dans le noyau est généralement si limité.

Answer 3

À l'exception d'un support d'outils plus large et de la portabilité du matériel, je ne pense pas qu'il y ait une raison impérieuse de se limiter au C. Je vois souvent des choses compliquées codées à la main faites en C qui peuvent être faites plus naturellement en C++ :

• Le regroupement en "modules" de fonctions (non générales) qui ne travaillent que sur une même structure de données (souvent appelée "objet") -> Utiliser les classes C++.
• Utilisation d'un pointeur "handle" pour que les fonctions du module puissent travailler avec des "instances" de structures de données -> Utilisation de classes C++.
• Fonctions statiques de portée de fichier qui ne font pas partie de l'API d'un module -> fonctions membres privées C++, espaces de noms anonymes ou espaces de noms "détaillés".
• Utilisation de macros de type fonction -> templates C++ et fonctions inline/constexpr
• Comportement différent à l'exécution en fonction de l'identification d'un type avec une vtable faite à la main ("descripteur") ou distribuée avec une instruction switch -> polymorphisme C
• arithmétique de pointeur sujette aux erreurs pour le marshalling/demarshalling de données depuis/vers un port de communication, ou utilisation de structures non portables -> concept de flux C++ (pas nécessairement std::iostream)
• Préfixer tout pour éviter les conflits de noms : Les espaces de noms C++
• Macros comme constantes de compilation -> constantes constexpr C++11
• Oublier de fermer les ressources avant que les poignées ne sortent du champ d'application -> C++ RAII

Aucune des fonctionnalités C++ décrites ci-dessus ne coûte plus cher que les implémentations C écrites à la main. J'en oublie probablement d'autres. Je pense que l'inertie du C dans ce domaine a plus à voir avec le fait que le C est le plus utilisé.

Bien sûr, il se peut que vous ne puissiez pas utiliser la STL librement (ou pas du tout) dans un environnement contraint, mais cela ne signifie pas que vous ne pouvez pas utiliser le C++ comme un "meilleur C".

Answer 4

1) "Parce que ça a toujours été comme ça" - cela explique en fait plus de choses que vous ne le pensez - étant donné que les API de presque tous les systèmes actuels ont été écrites à l'origine selon un modèle basé sur C ou ASM, et étant donné que beaucoup de code antérieur existe en C et ASM, il est souvent plus facile de "suivre le courant" que de trouver comment tirer parti du C++.

2) Environnement - Pour utiliser toutes les fonctionnalités du C++, vous avez besoin d'un environnement d'exécution assez complexe, dont certains sont difficiles à fournir à un pilote. C'est plus facile à faire si vous limitez votre ensemble de fonctionnalités, mais entre autres choses, la gestion de la mémoire peut devenir très intéressante en C++, si vous n'avez pas beaucoup de tas. Les exceptions sont également très intéressantes à considérer dans cet environnement, tout comme le RTTI.

3) "Je ne vois pas ce qu'il fait". Il est possible pour tout programmeur raisonnablement compétent de regarder une ligne de C et d'avoir une bonne idée de ce qui se passe au niveau du code machine pour implémenter cette ligne. Évidemment, l'optimisation change quelque peu la donne, mais dans la plupart des cas, vous pouvez savoir ce qui se passe. En C++, compte tenu de la surcharge des opérateurs, des constructeurs, des destructeurs, des exceptions, etc., il devient vraiment difficile d'avoir une idée de ce qui va se passer sur une ligne de code donnée. Lors de l'écriture de pilotes de périphériques, cela peut être mortel, car vous DEVEZ souvent savoir si vous allez interagir avec le gestionnaire de mémoire, ou si la ligne de code affecte (ou dépend de) les niveaux ou le masquage des interruptions.

Il est tout à fait possible d'écrire des pilotes de périphériques sous Windows en utilisant C++ - je l'ai fait moi-même. L'inconvénient est que vous devez faire attention aux fonctionnalités C++ que vous utilisez et à l'endroit où vous les utilisez.

Answer 5

La principale raison pour laquelle C est utilisé au lieu de dire extrêmement surveillé Java est qu'il est très facile de perdre de vue ce que la mémoire est utilisée pour une opération donnée. C est très aborder orienté. De préoccupation essentielle à l'écriture de code du noyau est d'éviter de référencement de mémoire qui peuvent causer une défaillance de page à un moment gênant.

C++ peuvent être utilisés, mais uniquement si la durée d'exécution est spécialement adaptée à une référence interne uniquement les tables en mémoire fixe (pas paginable) lors de l'exécution de la machinerie est appelée implicitement par exemple, en utilisant une vtable lors de l'appel de fonctions virtuelles. Cette adaptation particulière ne vient pas "out of the box", la plupart du temps.

L'intégration de C avec une plate-forme est beaucoup plus facile à faire car il est facile à bande C de sa bibliothèque standard, et gardez la maîtrise de l'accès à la mémoire totalement explicite. De sorte qu'avec elle aussi bien connue de la langue, il est souvent le choix de noyau d'outils de designers.

Edit: suppression de la référence à nouveau et supprimer des appels (c'était erronée ou trompeuse); remplacé par un plus générale de "run-time machines" de la phrase.