Oui je suis d'accord, mais bon même si je vais échouer "et c'est certain", je vais quand même apprendre quelque chose, n'est pas.
Pour les protocoles, je parle de tous, toutes sortes de protocoles!
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Oui je suis d'accord, mais bon même si je vais échouer "et c'est certain", je vais quand même apprendre quelque chose, n'est pas.
Pour les protocoles, je parle de tous, toutes sortes de protocoles!
Moi je me souviendrai toujours des propos que nous avait tenus notre prof d'assembleur à l'époque de mes études (il y a plus de 25 ans quand même !) :
"Avant d'apprendre à écrire, vous avez d'abord appris à lire".
Il nous avait alors donné alors plusieurs programmes très simples mais de complexité croissante avant même de nous donner notre premier programme à écrire.
Pour l'écriture d'un système d'exploitation, je pense que ça doit être pareil. Avant de songer à en écrire un nouveau, il me semble plus judicieux d'en étudier un déjà existant.
LINUX me semble le candidat le mieux adapté pour cela ...
Désolé d'être aussi direct, mais ça ne veut absolument rien dire ! Définit ce que c'est pour toi qu'un protocole, sinon on ne pourra pas t'aider.Envoyé par overon
Encore une fois, si c'est des protocoles réseaux dont tu parles, ne pense même pas à ça tant que tu n'auras pas un système minimal (donc gestion de la mémoire, des I/O, des périphériques...).
Et tu pourrais argumenter là dessus ? InOCmalWeTrust vient précisément de dire le contraire, dis nous pourquoi tu es en désaccord avec lui.
"En essayant continuellement, on finit par réussir. Donc : plus ça rate, plus on a de chances que ça marche" (devise Shadock)
Application :
ainsi qu'à regarder la
avant de poser une question.
La rubrique Perl recrute, contactez-moi.
En meme temps, quelqu'un qui a confiance en OCaml,est ce qu'on peut lui faire confiance...c'est ou deja la sorti ?
Edit : je trouve que ce topic n'a pas de sens : il n'y pas de projets serieux derriere tout cela, on dirait un lycéen qui s'ennuie pendant ces vacances et qui veut devenir Bill Gates, et découvrir l'informatique en meme temps...
Il faudrait peut-etre eviter de pousser la charrue avant les boeufs et apprendre l'informatique avec des projets plus accessibles non ? (et surement moins decourageant)
"Voyager, c'est découvrir que tout le monde a tort", Aldous Huxley
"Less is more" Ludwig Mies Van Der Rohe
Risk & Security Mgmt
Désolé mais je suis pas du meme avis. Je pense qu'il est clair qu'il ne souhaite pas devenir bill gates, il souhaite juste apprendre.
J'ai passé plein de temps a apprendre la structure des OS, à lire des bouquins en anglais, des codes sources de divers OS que tu trouves sur le net... et je peux te dire que c'est tres interressant pour comprendre un petit peu ton PC.
Par ailleurs s'amuser a programmer un petit OS, n'est pas plus irrealiste que ceux qui se lance dans la programmation d'un jeu revolutionnaire.
Enfin pour terminer, je pense qu'une bonne partie des gens qui contribue à des projets comme LINUX, on eu aussi envi de "bidouiller" en faisant des OS maison.
---------
Sinon pour revenir au sujet, j'ai deja vu des petits projets d'OS en C++, et c'etait pas mal du tout.
Oui enfin il faut un minimum de connaissance a la base...la on a l'impression que protocole est un mot magique...
"Voyager, c'est découvrir que tout le monde a tort", Aldous Huxley
"Less is more" Ludwig Mies Van Der Rohe
Risk & Security Mgmt
Mais j'ai l'impression que le premier OS a été codé en ASM quand même. Le dégré d'abstraction a besoin justement de cette solidité du système d'exploitation. Plus le degré d'abstraction est élevé, plus j'ai l'impression que l'on s'éloigne de la programmation noyau.
Pour la suggestion du C++ pour coder un OS, en fait c'est inutile et même, le C++ n'est pas fait pour ça. Car de toutes les manières, c'est un peu un système en couches d'oignons, et plus l'OS est évolué, plus le noyau dispose d'une API évoluée, mais je ne pense pas que l'on puisse commencer avec du C++ au premier abord, ça me paraît difficile à envisager.
Le C++ est trop abstrait pour permettre de gérer "directement" les choses lorsque ça devient trop proche de la machine. Tendre à faire des API évoluées pour utiliser avec le noyau, c'est très bien, mais il faut bien un OS pour le supporter, pas moyen de faire ça directement en C++ à mon avis.
Comme le C est le niveau directement au dessus de l'assembleur, et qu'il permet tout de même une bonne abstraction dans la programmation (ainsi que une forme de programmation orientée objet) , il est inutile d'aller rajouter une couche supplémentaire de C++, sauf à rajouter de la complexité et de la lourdeur à l'ensemble.
Salut à tous !
Je rectifie ce que j'ai dit : c'est C/C++ qui est selon moi le plus approprié mais surtout le plus utilisé pour écrire des OS, surtout le C car ce langage approche surtout la programmation noyau mais C++ a l'avantage d'utiliser la notion d'objet, le développement d'OS fait de nos jours abstraction aux matériels (pas une abstraction totale mais à 90 %) surtout aujourd'hui où les nouveaux OS sont obtenus en bidouillant le code source gratuit de LINUX.
Je ne connais pas vraiment l'histoire des systèmes d'exploitation mais avec quel langage et quel IDE les OS suivants ont été développés pour la 1ère fois et actuellement:
- UNIX
- MAC OS
- Windows
randriano.dvp.com
Développeur. Product Owner [Agile]. Sites web, mobile apps, système d'information (SI).
En fait par OS, il faut différencier noyau et applications.
Pour moi, la charge du noyau, c'est de supporter le code des applications. Le noyau ne peut pas être écrit autrement qu'en assembleur (au début au moins) simplement parce qu'il n'y a pas de noyau pour supporter les applications
Le noyau a besoin, par définition, d'un langage proche de la machine, et par définition l'ASM est fait pour ça. Ensuite, il est certain que de maintenir un noyau en ASM est complétement impossible, on passe alors à un degré d'abstraction supplémentaire en utilisant le C.
Mais le C++ est bien trop abstrait (ne serait-ce justement que par ses mécanismes objet) pour permettre de l'utiliser dans la programmation d'un noyau à mon avis. Ou alors, il ne faut pas utiliser le C, et utiliser directement le C++, mais à mon avis c'est périlleux d'interfacer du C++ avec de l'ASM. Ce sont déjà deux langages trop différents.
Donc je crois que le C, qui a ds liens forts avec l'ASM, est le seul langage évolué qui permet de coder un noyau, donc un OS.
Le fait qu'ils aient abandonner l'idee signifie peut-etre qqchoseje crois bien que les Mac ont eu un noyau codé en Pascal a une époque
"Voyager, c'est découvrir que tout le monde a tort", Aldous Huxley
"Less is more" Ludwig Mies Van Der Rohe
Risk & Security Mgmt
Le fait qu'ils aient abandonner l'idee signifie peut-etre qqchose
ça signifie surtout qu'ils sont passé sur un noyau Unix...
pascal peut être aussi pas niveau que le C, et les appels asm y sont tout aussi "élégants"
Je m'excuse pour mon incultureje crois bien que les Mac ont eu un noyau codé en Pascal a une époque
Ceci dit , il est vrai que je crois que un langage dédié à la programmation d'OS se doit de pouvoir être interfacé avec de l'ASM, sans quoi ce n'est pas facile.
Enfin il faut toujours garder à l'esprit qu'il y a des raisons techniques à utiliser tel ou tel langage, le C a démontré son efficacité dans le domaine. Tout langage compilé peut satisfaire, à condition qu'il possède une méthode d'interfaçage ASM.
C'est un peu aussi le dilemne de la poule et de l'œuf. qui est venu le premier ?
Pour l'utilisation du C , je crois que le fait que ce soit un langage proche du bas-niveau, lui donne une souplesse particulière et permet les optimisations plus que le C++.
je dirais c'est surtout quel serait l'intérêt à part d'être "dans la mode" d'utiliser autre chose que ce qui a fait ses preuves et est selectionné par l'expérience comme étant le langage de développement des OS ??
Le langage objet n'est qu'une facilité pour le programmeur. Dans le cas du développement d'un OS, comme cela a été dit plus haut, on s'en fout pas mal de savoir si c'est facile à coder ou pas. Ce qu'on veut c'est que l'interaction avec la machine se fasse le mieux et le plus rapidement possible.....
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
N'importe quel langage disposant d'un système d'allocation statique sûr peut convenir. Je ne connais pas très bien le C ++ : je croyais que la seule façon de créer un objet, c'était de le faire de façon dynamique en utilisant le mot-clef new, mais si il est possible d'allouer des objets de façon statique, comme en C, puis de les initialiser, alors le C ++ convient aussi, tout comme Pascal.
Du moment que l'on dispose d'un langage dont le mécanisme ne repose sur aucun service du système (typiquement, l'allocation dynamique se fait toujours en passant par le système), alors il est possible d'écrire un OS dans ce langage. C'est l'éternel problème du poisson qui se mord la queue : programmer un OS dans un langage dépendant de l'OS lui-même, ce n'est pas possible, à moins de contourner l'affaire.
Si on utilise aussi souvent le C, c'est surtout parce qu'il s'agit du langage le plus répandu et le mieux adapté à ce genre de choses, le plus simple. En bidouillant un peu le garbage collector de OCaml pour le rendre indépendant du système d'exploitation, on pourrait utiliser OCaml pour construire son noyau.
Pour ce qui est de l'assembleur, il s'agit surtout des routines et des toutes petites parties du code noyau qui doivent exécuter des instructions machine spéciales à la gestion des ressources, jamais produites par aucun compilateur. La commutation des tâches en est un exemple.
When Colt produced the first practical repeating handgun, it gave rise to the saying God created men, but Colt made them equal.
Moi j'ai une approche complètement différente de vous
J4ai envie de dire que le loader et le noyau de départ doit être écrit en ASM (pour commander le CPU). Ensuite le langage j'ai envie de te dire tu prend celui que t uveux, et même plus FORT tu n'as qu'a créer le tiens ...
Le développement d'un OS c'est un des projets les plus compliqué, et de toute façon il te faudra bien un compilateur capable de sortir du code assembleur. En comme tu vas faire ta propre mixture, ni gcc, ni mingw ne marchera donc, il va falloir adapter ça à la mano !
D'où fait carrementton propre compilo, la fameuse question existentielle C ou C++ elle trouve cependant une réponse très simple.
Une couche d'abstraction de haut niveau, s'appuie sur une couche d'abstraction de niveau -1, d'où le C++ est en fait "pseudo" traduit en C, puis compilé en C, donc la question est plutot la suivante : pourquoi utiliser un langage de couche N+1 sachant qu'il est réécrit en en langage de couche N ?
Bien sûr la vous me dirait, oui mais ya la notion objet, etc ... Je suis d'accord avec vous, on arrive à faire des programme plus simples grâce à la notion d'objet, cependant la notion objet est simplement une manière d'utiliser le C !
De plus si on se place dans le contexte de la création d'un OS, donc de la gestion de bas niveau, avec une gestion de chaque périphérique, si on arrive à faire cela on est plus à utiliser du C ou du C++.
Bref, ce long discours pour arriver à la chose suivante, il faut choisir un langage de 3ème génération maxi, reposant sur un modèle C permettant un meilleure gestion du bas niveau.
Pour conclure, l'ASM est un passage obligé pour la conception et surtout l'opitmisation de tout le "bordel", donc je finairais mon discours sur QuelS langageS sont nécessaires.
Oui, bien-sûr, pourquoi ne pas se créer aussi son propre processeur ?
Non, c'est complètement faux. Linux est compilé grâce à gcc, juste à titre informatif, et les optimisations ne sont pas faites en assembleur, étant donné qu'un être humain ne peut pas écrire d'assembleur optimisé, mais elles sont laissées à la discrétion du compilateur. Les seules partis faites en assembleur concernent celles qui contiennent des instructions privilègiées, que les compilateurs ne crachent jamais (et ne peuvent pas cracher).
Encore une grosse bêtise : le C ++ n'est pas compilé en C avant d'être compilé en assembleur, mais directement en assembleur, tout comme tous les langages qui se respectent.
Pas forcément... qu'est-ce qui te permet de dire que le C est mieux armé que les autres pour la gestion des périphériques ?
A titre informatif : il existe même un OS entièrement écrit en OCaml... étonnant non ?
Voir note plus haut concernant l'optimisation.
When Colt produced the first practical repeating handgun, it gave rise to the saying God created men, but Colt made them equal.
la question étant de savoir le nombre de asm dans le code...
pas forcemment, il y a certaines opérations qu'on fait difficilement en C, et qui donc seront traduites en pas d'opérations asm par le compilateur malgré les optimisations, et qui en asm se feraient plus simplement... ces cas sont rares à ma connaissance, mais existent
et il fonctionne au moins ? à une vitesse raisonnable ? sans surcharger inutilement la ram ? est du vrai ocaml, ou seulement un sous-ensemble bien choisi ?
Moi je veux voir le coup du C++ compilé directement sans passer par une sémantique C ....
les optimisations ne sont pas faites en assembleur, étant donné qu'un être humain ne peut pas écrire d'assembleur optimisé, mais elles sont laissées à la discrétion du compilateur. Les seules partis faites en assembleur concernent celles qui contiennent des instructions privilègiées, que les compilateurs ne crachent jamais (et ne peuvent pas cracher).
Puis juste pour la feinte, le compilo est apparu tout seul, personne n'a écrit les routine qui génère l'ASM derrière ....
Prend un bon petit vi, fait vite fait un petit programme en C avec des calcul et sors ton programme en ASM ... Tu vas être surpris de voir le code "optimisé" que le compilo crache ....
perso, je te dirais qu'un compilo C++ est composé de :
+ un parseur (front-end) qui te stocke le programme sous la forme d'un AST
+ un middle-end qui fait des opérations et optimisations sur l'AST
+ un back-end qui crache "l'assembleur" (façon de parler, mais en première approximation ce n'est pas faux)
après il n'est pas impossible que l'AST du compilo C++ ressemble à s'y méprendre à l'AST d'un compilo C... mais de loin, tous les AST se ressemblent
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager