Pourquoi ne pas avoir un système d'exploitation basé sur un langage de haut niveau? Les langages de bas niveau sont-ils plus efficaces?


44

Sans être présomptueux, j'aimerais que vous envisagiez cette possibilité. La plupart des systèmes d'exploitation actuels sont basés sur des langages de bas niveau (principalement C / C ++). Même les nouveaux tels qu'Android utilisent JNI et l'implémentation sous-jacente est en C

En fait, (ceci est une observation personnelle) de nombreux programmes écrits en C sont beaucoup plus rapides que leurs homologues de haut niveau (par exemple: Transmission (un client BitTorrent sur Ubuntu) est beaucoup plus rapide que Vuze (Java) ou Deluge (Python) ). Même les compilateurs python sont écrits en C, bien que PyPy soit une exception.

Y a-t-il une raison particulière à cela? Pourquoi est-ce que tous nos prétendus "langages de haut niveau" avec les grands concepts "POO" ne peuvent pas être utilisés pour créer un système d’exploitation solide?

Donc, j'ai essentiellement 2 questions.

  1. Pourquoi les applications écrites dans des langages de bas niveau sont-elles plus efficaces que leurs homologues HLL? Les langages de bas niveau fonctionnent-ils mieux pour la simple raison qu'ils sont de bas niveau et que leur traduction en code machine est facilitée?
  2. Pourquoi n’avons-nous pas un système d’exploitation à part entière entièrement basé sur un langage de haut niveau?

36
Vous sous-entendez que seuls les "langages de haut niveau" sont orientés objet, ce qui n'est pas vrai.
Uooo

2
@rtindru "Joli langage de bas niveau" (principalement C / C ++)? Quelle est votre définition du langage de haut niveau alors? Vous devez clarifier votre définition / interprétation du langage de haut niveau. Python est en fait un langage de script car il est exécuté directement sur son moteur (IDLE ou terminal en ligne de commande), si vous ne vous en êtes pas rendu compte maintenant. Il y a une très bonne raison (philosophique et pratique) pour laquelle le C / C ++ est utilisé comme langage d’implémentation pour de nombreux systèmes d’exploitation, mais je suis sûr que les utilisateurs chevronnés ne se lanceront probablement pas dans cette affaire pour cette question.
hagubear

10
Android n'est pas un tout nouveau système d'exploitation. C'est juste une autre version de Linux.
Den

3
@hagubear Il existe une très bonne raison (philosophique et pratique) pour laquelle le C / C ++ est utilisé comme langage d'implémentation pour de nombreux systèmes d'exploitation . Quelle est cette très bonne raison?
Rtindru

2
Si je comprends bien, les systèmes d'exploitation pour les machines LISP ont été écrits en LISP. On pourrait peut-être prétendre que le dialecte utilisé était un langage de bas niveau?
Robert Fisher

Réponses:


38

Microsoft a effectué des recherches très intéressantes dans ce sens, si vous examinez Singularity:

http://research.microsoft.com/en-us/projects/singularity/

En outre, Mothy Roscoe et al ont travaillé sur Barrelfish, qui utilise le langage de programmation de contraintes Eclipse en tant que service de système d’exploitation pour résoudre tous types de problèmes de gestion de système d’exploitation et d’allocation de ressources:

http://www.barrelfish.org/


Wow, je ne peux pas voter, j'ai besoin de 15 représentants ... je viens de rejoindre aujourd'hui! Merci beaucoup.
Rtindru

9
@rtindru: même avec 1 point de repère, vous pouvez accepter une réponse. Qu'est-ce que cela signifie lorsqu'une réponse est "acceptée"?
Marjan Venema

6
Accepter une réponse a tendance à réduire le nombre de nouvelles réponses / discussions. Personnellement, je recommanderais de ne pas accepter (à cette question précise) au moins un autre jour.
Brian

1
J'ajouterais Cosmos à la liste: open source, tierce partie, moins intéressante que la singularité, mais j'ai de bonnes idées! cosmos.codeplex.com
Lorenzo Dematté

38

Beaucoup dépend de l'endroit où vous placez la division entre les langages de bas niveau et de haut niveau. Par exemple, différentes personnes ont tendance à placer un langage comme le C ++ sur différents côtés de cette division.

Concernant vos questions:

  1. Je ne crois pas qu'il y ait une telle différence entre les langages de bas niveau et de haut niveau, mais davantage entre les langages interprétés et les langages compilés en instructions natives.

    Mais il peut également y avoir une différence de culture entre les programmeurs, où les utilisateurs de langages bas niveaux se concentrent davantage sur les aspects de performance des choix (de conception) qu’ils font.

  2. Si vous considérez que C ++ est de haut niveau, il existe au moins un système d'exploitation entièrement écrit dans un langage de haut niveau (Symbian OS est écrit en C ++). Ce qui vous empêche d'écrire un système d'exploitation dans la plupart des langages de haut niveau, ce sont deux choses:

    • Un système d'exploitation a besoin d'un accès de bas niveau à la mémoire et au matériel et effectue des manipulations compliquées. Ce type d'accès est généralement considéré comme dangereux pour les programmes au niveau de l'application. Par conséquent, de nombreux langages de haut niveau ne le permettent pas.
    • Un système d'exploitation doit être exécuté sans logiciel de support, tel que des interprètes. Cela rend extrêmement difficile l’écriture d’un système d’exploitation dans un langage qui ne peut pas être facilement compilé en instructions natives.

35
Il n’existe pas de langage interprété ni de langage compilé en instructions natives. Une langue est un ensemble de règles mathématiques, il est ni interprété ni compilé, juste est . Interp. et comp. sont des traits de l’interprète ou du compilateur, pas le langage. Chaque langue peut être implémentée à l'aide d'un compilateur ou d'un interprète. Aujourd'hui, la plupart des langages ont à la fois des implémentations interprétées et compilées. Il existe des interpréteurs pour C et toutes les principales implémentations JavaScript sont compilées en code natif. Et quel est le code natif de toute façon? Si je compile le bytecode Java vers JVM et que je lance
Jörg W Mittag Le

11
sur un processeur Java, et je compile le code machine C vers ARM et l’exécute sur un interpréteur ARM parce que mon PC n’a pas de processeur ARM, alors qu'est-ce qui rend ARM natif et JVML non?
Jörg W Mittag Le

5
@ JörgWMittag: Si votre processeur peut exécuter directement le bytecode Java (sans utiliser de machine virtuelle supplémentaire), le bytecode Java est un code natif pour ce CPU. En outre, je n'exclue pas la possibilité d'écrire un système d'exploitation dans un langage généralement interprété ou exécuté sur une machine virtuelle, mais cela les rend moins évidentes.
Bart van Ingen Schenau

15
@ JörgWMittag - Je conviens que n'importe quel langage peut être compilé ou interprété (compiler un script bash; utiliser un interpréteur C ++ (CINT / Cling)), mais de nombreuses décisions dans la conception d'un langage sont basées sur l'interprétation, la compilation, ou les deux. Un langage qui vous permet de déclarer / initialiser manuellement des variables de type statique, d'allouer / de libérer de la mémoire, de faire de l'arithmétique de pointeur, de vérifier que les limites d'un tableau est moins pratique dans un interpréteur (par opposition à un langage qui ramasse de la mémoire, en déduit le type dynamique, vérifie les limites du tableau). Cette ligne est-elle 100% claire? Non, mais la différence existe dans la pratique.
dr jimbob

15

Il y a plusieurs bonnes raisons à cela.

La langue de bas niveau d'aujourd'hui était la langue de haut niveau d'hier

Oui, croyez-le ou non, il était une fois, même C était considéré comme un langage de haut niveau. Il y a même environ 20 ans, il était assez courant de le voir décrit comme un langage de "niveau intermédiaire". C'était une époque où OO n'était plus populaire qu'aujourd'hui, Java n'existait pas, C # n'existait pas, même C ++ n'était pas encore correctement normalisé.

Inertie Historique

Les systèmes d'exploitation que vous utilisez aujourd'hui ont des racines profondes dans l'histoire. Windows remonte au début / au milieu des années 80, Unix au début / au milieu des années 70. Il y a BEAUCOUP de code ancien et fonctionnel dans les systèmes d'exploitation, et vous ne souhaitez généralement pas réécrire le code ancien et fonctionnel.

À un moment donné, il faut descendre au matériel

Cela se produit dans le noyau, dans les pilotes, dans les sous-systèmes de gestion de la mémoire, dans le système de fichiers. Bien sûr, vous pouvez superposer un langage de haut niveau, mais vous devez tout de même pouvoir accéder plus directement au matériel offert par un langage de niveau inférieur.

Portabilité

Je ne parle pas de la portabilité vers un matériel différent ou un système d'exploitation différent, comme on le comprend plus couramment aujourd'hui; c'est plus subtil. Il existe un avantage majeur à fournir une interface basée sur le C pour quelque chose, à savoir le fait que pratiquement tous les autres langages existants peuvent être liés au C. Même pour les raisons suivantes, l'API Windows est toujours une API basée sur le C.

Préférence personnelle

Certaines personnes préfèrent simplement programmer de cette façon, et cela peut être un facteur majeur. Par exemple, Linus Torvalds a un discours célèbre contre le C ++, ce qui montre bien que C sera toujours son outil de prédilection pour ce type de travail (le contenu du discours et le fait que vous soyez d’accord ou non avec lui). n'est pas pertinent pour cette discussion, le fait que le coup de gueule existe suffit).

Pris ensemble, ceux-ci devraient établir clairement pourquoi un système d'exploitation était à l'origine écrit avec quelque chose comme le C à l'époque, et pourquoi des morceaux très importants de celui-ci - même aujourd'hui - le restent.


13

L’histoire est l’une des principales raisons de la prédominance de C pour les systèmes d’exploitation: les systèmes d’exploitation traditionnels tels que Windows et toutes les formes Unix (BSD, Solaris, HP-UX, Mac OS X, ... ainsi que des clones tels que Linux) longtemps, avant que OO et d’autres constructions de "haut niveau" ne soient généralisées.

Pour le noyau du système d’exploitation, outre les performances, il est nécessaire de définir très précisément les instructions relatives au matériel et de contrôler parfaitement la mémoire, que les langages comme C utilisent très bien.

Pour les systèmes intégrés, certains systèmes d'exploitation utilisent parfois des langages de niveau supérieur pour de plus grandes parties du système. Un exemple notable est JavaOS de Sun.

Pour les systèmes d'exploitation répandus, un exemple notable n'utilisant pas le C est le MacOS classique avant MacOS X - qui était écrit en grande partie dans un dialecte de Pascal, ce qui permettait une certaine forme d'orientation des objets.


12

Premièrement, il y a des problèmes de bootstrap. La plupart des fonctionnalités qui facilitent les langages de haut niveau sont basées sur des abstractions qu'un noyau doit fournir lui-même. Comment écrivez-vous un gestionnaire de mémoire dans un langage nécessitant un gestionnaire de mémoire? Comment écrivez-vous des pilotes d'E / S sans utiliser les belles bibliothèques standard d'E / S de votre langue? Comment créer des primitives de threading et de synchronisation sans utiliser les bibliothèques du langage?

Deuxièmement, il est extrêmement utile et beaucoup plus lisible lors de l'écriture de systèmes d'exploitation de pouvoir affecter une variable à un emplacement de mémoire spécifique. C'est facile en C, et chaque programmeur en C sait le faire. Si c'est même possible dans les langages de niveau supérieur, il est si rare que seuls les gourous sachent le faire.

En d'autres termes, lorsque vous prenez en compte toutes les limitations et modifications que vous devez accepter, C et C ++ commencent à paraître beaucoup plus faciles.


2
Votre premier paragraphe n'a aucun sens. Un pilote d’E / S en C n’utilise pas non stdio.hplus. Une implémentation mutex personnalisée n'utilise pas pthreads. C'est précisément ce que cela signifie de le mettre en œuvre vous-même! Et cela est indépendant de la langue que vous utilisez. Cela ne veut pas dire que les langages de haut niveau sont un bon choix pour les tâches de bas niveau (ils ne le sont généralement pas selon mon expérience).

Je suis au courant de ça. Je souligne simplement que ce qui différencie le plus haut niveau d'un langage de bas niveau se situe dans les parties du langage qui ne sont pas disponibles dans le développement du noyau. Lorsque vous comparez les langages noyau à noyau, C n’a plus l’air si spartiate.
Karl Bielefeldt

Pas tout à fait vrai. Bien que vous ayez besoin d' un code qui n'utilise pas X pour implémenter X, tout le code restant peut dépendre de ce code et utiliser X.

C'est un bon point.
Karl Bielefeldt

6

Tout d’abord, l’amorçage nécessite au moins une petite partie écrite en Assembly ou équivalent.

Deuxièmement, il y avait un système d'exploitation écrit dans une machine Lisp indiscutablement HLL . (Le fait qu’il ait échoué sur le plan commercial tient davantage au fait que d’autres matériels deviennent moins chers et plus rapidement et au triomphe de Worse is Better qu’à des défauts de conception ou de conception).

Troisièmement, C ++ est plutôt orienté objet et de haut niveau. Par conséquent, comme d'autres l'ont souligné, Symbian OS est un autre exemple.

Quatrièmement, les nouveaux systèmes d'exploitation sont peu nécessaires à l'heure actuelle. Nous avons déjà pas mal de variantes linux et bsd qui fonctionnent sur à peu près n'importe quel matériel, et créer un tout nouveau système d'exploitation coûte assez cher.


Vous avez manqué les ordinateurs centraux Burroughs B5000. Leur système d'exploitation a été écrit en Burroughs Extended ALGOL.
John R. Strohm

1
there is little need for new OSes at this timeJe n'ai toujours pas décidé moi-même si cela est vrai ou non. Oui, les systèmes d'exploitation modernes (fenêtres modernes (NT) / Unix moderne) sont tout ce dont nous avons besoin, en termes de fonctionnalités et de performances. Mais à peine: ils sont nés dans un autre domaine où "le réseau" était une entreprise / université et les utilisateurs étaient dignes de confiance, et multiproc était constitué de 2/4 processeurs. Ils sont "en proie", dans une certaine mesure, à l’excès de confiance (rootkits, malwares, virus, etc.). Je commence à penser qu'il y a de la place pour un système d'exploitation moderne, sûr et isolé ... avec un meilleur support pour le parallélisme (mieux que threads)
Lorenzo Dematté

Lisp est de bas niveau CARet CDRconstituent des macros assembleur IBM 704 ! Même C sépare l'assemblage en ligne , plutôt que de le traiter comme une autre fonction. Considérant le travail de Lisp CARet son CDRtravail sur x86, ARM et une foule d’ISA, il s’agit d’un assemblage extrêmement portable. (Note latérale pour toute personne que j'ai peut-être confondue: oui, Lisp est un langage de haut niveau. CAREt CDRêtre macros d'assembleur n'était qu'un détail d'implémentation, pas une fonctionnalité clé.;))
8bittree

4

Pour mieux mettre en phase ce que j'ai écrit précédemment.

Les machines Burroughs 5xxx - 6xxx n'avaient pas de langage d'assemblage. La langue la plus basse disponible était une extension de Algol. L'Algol a été mis en œuvre dans le matériel. L'OS et toutes les langues ont été écrites en algol. Il a surperformé toutes les machines concurrentes de l'époque. Cela nécessitait également beaucoup moins de code, ce qui facilitait grandement sa maintenance. Il y avait du matériel de pile qui supportait un langage récursif tel Algol.

Le système d'exploitation Burroughs a évolué vers une version appelée MCP. MCP fonctionne actuellement sur les systèmes Unisys.


3

La plupart des langages de niveau supérieur que vous avez mentionnés ont une fonctionnalité qui ne correspond pas aux systèmes d'exploitation: Gestion automatique de la mémoire. Vous ne pouvez pas compter sur un ramasse-miettes lors de l'écriture d'un système en temps réel, que ce soit logiciel (ce qui est un système d'exploitation) ou même pire. Pour citer Tanenbaum [i]:

Certains éléments que C n'a pas incluent sont les chaînes, les threads, les packages, les classes, les objets, la sécurité de type et le garbage collection intégrés. Le dernier est un show stopper pour les systèmes d'exploitation. Tout le stockage en C est soit statique, soit explicitement alloué et libéré par le programmeur, généralement avec la fonction de bibliothèque malloc et free . C'est cette dernière propriété - le contrôle total de la mémoire par le programmeur - avec des pointeurs explicites qui rend le C attrayant pour l'écriture de systèmes d'exploitation. Les systèmes d'exploitation sont, dans une certaine mesure, essentiellement des systèmes temps réel, même généraux. Lorsqu'une interruption se produit, le système d'exploitation peut ne disposer que de quelques microsecondes pour effectuer une action ou perdre des informations critiques. Il est intolérable que la collecte des ordures débute à un moment arbitraire.

Vous pouvez maintenant dire que C ++ est également un bon candidat car il offre une gestion manuelle de la mémoire. Le C ++ a déjà été utilisé dans certains systèmes d'exploitation tels que Symbian (mentionné par Bart ) et BeOS. Mais IMHO C reste le langage le plus rapide pouvant être porté dans de nombreuses architectures sans effort considérable (contrairement à l’assemblage d’une architecture spécifique).

[i]: Systèmes d'exploitation modernes, 3e édition, page 73


3
Les machines Symbolics avaient une gestion automatique de la mémoire. Smalltalk a fait sur un Alto. C'était dans les années 80. Un système de type linéaire supprime complètement la nécessité de GC. Ce sont des problèmes résolus, si seulement nous pouvions nous en souvenir!
Frank Shearar

Un langage pourrait inclure la gestion automatique de la mémoire, mais inclure un type spécial de référence "profondément épinglée" et permettre aux méthodes de déclarer explicitement qu'elles n'accéderont à aucune référence non épinglée ni n'invoqueront de méthodes susceptibles de le faire. Un récupérateur de place Stop-the-World n'aurait pas besoin d'interférer avec le code exécuté dans une méthode qui n'allait accéder à aucun objet susceptible d'être modifié par le GC.
Supercat

2

Comme d'autres l'ont souligné, plusieurs systèmes d'exploitation ont été écrits dans des langages de haut niveau. Peut-être que ce que vous voulez dire, c'est que tous les systèmes d’exploitation à succès, destinés au grand public et destinés au grand public, ont été écrits en une combinaison d’assemblage, de C et de C ++?

La plupart des langages de haut niveau ont des tonnes de fonctionnalités utiles qui entraînent un coût de performance associé. La gestion automatisée de la mémoire est un exemple évident, la vérification des limites de tableaux en est un autre. Si vous écrivez un système d’exploitation à usage général, vous risquez de vous trouver dans des situations où la pénalité de performance de ces fonctionnalités utiles dépasse le montant que vous êtes prêt à payer. À ce stade, vous souhaitez pouvoir les désactiver. Des langages tels que Python, C # et Java varient selon les fonctionnalités que vous pouvez désactiver, mais aucune d'entre elles n'est aussi polyvalente que C ou C ++ à cet égard.

Dans cet aspect, C et C ++ sont presque aussi polyvalents que l’assemblage pur. Si vous décidez que vous avez besoin de dix gestionnaires de mémoire différents couvrant dix scénarios d'allocation de mémoire différents, vous pouvez les implémenter tous en C et C ++, puis les charger et les décharger à votre guise. Heck, vous n'avez même pas besoin de vous lier aux bibliothèques standard d'exécution C ou au code de démarrage si vous ne le souhaitez pas.


0

La vraie réponse est l' argent . Il n’ya pas assez d’avantage perçu d’un système d’exploitation linguistique de haut niveau pour justifier l’utilisation des ressources nécessaires à la construction d’un tel système , puis son intégration dans le processus général. La construction d'un nouveau pilote pour chaque élément de matériel à prendre en charge, par exemple, représente un coût énorme.

Il existe différents systèmes d'exploitation écrits dans des langages de haut niveau, dans le but principal de la recherche, tels que Oberon et Singularity .

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.