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!
Version imprimable
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.Citation:
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.Citation:
Envoyé par randriano
En meme temps, quelqu'un qui a confiance en OCaml,est ce qu'on peut lui faire confiance :P...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)
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.Citation:
Envoyé par Anthony.Desvernois
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...
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
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 :P pour parler à une machine, au début on est obligé de comprendre son langage assembleur, sinon ça ne marchera jamais.
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.
Citation:
Envoyé par kromartien
je crois bien que les Mac ont eu un noyau codé en Pascal a une époque ;)
Le fait qu'ils aient abandonner l'idee signifie peut-etre qqchose ;)Citation:
Envoyé par gorgonite
Citation:
Envoyé par Anthony.Desvernois
ça signifie surtout qu'ils sont passé sur un noyau Unix... :roll:
pascal peut être aussi pas niveau que le C, et les appels asm y sont tout aussi "élégants"
Je m'excuse pour mon inculture :)Citation:
Envoyé par gorgonite
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.....
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.
:salut:
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 ?Citation:
Envoyé par CORBASE
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).Citation:
Envoyé par CORBASE
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.Citation:
Envoyé par CORBASE
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 ?Citation:
Envoyé par CORBASE
A titre informatif : il existe même un OS entièrement écrit en OCaml... étonnant non ?Citation:
Envoyé par CORBASE
Voir note plus haut concernant l'optimisation.Citation:
Envoyé par CORBASE
Citation:
Envoyé par InOCamlWeTrust
la question étant de savoir le nombre de asm dans le code... :roll:
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 ;)Citation:
Envoyé par InOCamlWeTrust
Citation:
Envoyé par InOCamlWeTrust
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 ....
Citation:
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 ....
Citation:
Envoyé par CORBASE
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 :aie:
Pour Linux, quelque part entre nulle et insignifiante ; si tu ne me crois pas, prends les sources de Linux, et regarde un peu dedans.Citation:
Envoyé par gorgonite
Oui, bien-sûr qu'il fonctionne. Il est assez expérimental encore, étant donné qu'une seule personne s'en charge, mais il tourne bien selon ce que j'ai pu entendre. Il s'appelle Desert Spring Time...Citation:
Envoyé par gorgonite
http://dst.purevoid.org/
C'est une chose que je fais très souvent, figure-toi. Avec gcc, par exemple, en compilant avec l'option -O3, tu ne reconnais plus ton code... et avec le compilateur Intel, là, ça devient du délire total. Ce n'est pas parce qu'un sombre crétin a écrit un article dans GNU/Linux Maga$ine montrant Ô combien gcc était mauvais en compilant avec -Os (option servant uniquement à optimiser le code en espace et non en temps d'exécution) que tout le monde doit croire ces conneries !Citation:
Envoyé par CORBASE
Citation:
Envoyé par InOCamlWeTrust
j'ai déjà regardé dedans... tu n'es pas le seul à aller voir les sources d'un programme pour décortiquer son fonctionnement :roll:
et justement, je ne te crois pas :P
regardes le répertoire linux-version/arch, linux-version/drivers, les implémentations de certains fs
mais faut avouer... dès qu'on a à disposition "tout ce qui n'existe pas" en assembleur, on passe vite au c ;)
C'est à la mode en ce moment sur les fora de developpez.net de vouloir développer son propre langage ;-) Tu penses évaluer à combien la probabilité d'obtenir un langage un peu mieux que 100 fois moins bien que ce qui se fait déjà ?Citation:
Envoyé par CORBASE
"Un compilo capable de sortir du code assembleur", c'est pas globalement "un compilo" ? :-\ Bon ok, il y a quelques langages où le compilo produit du code pour une machine virtuelle...Citation:
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 !
Uhuh :-)Citation:
D'où fait carrementton propre compilo
Ouhlala ! T'as un paquet d'année de retard. Ca fait bien longtemps qu'un compilo C++ n'est plus un préprocesseur C. C'était effectivement le cas (ce qui donnait de grand moment de débug quand le compilo C t'envoyais un message d'erreur sur un code que tu n'avais jamais écris :-)) Maintenant un compilo C++ compile évidement le C++ "directement". Après, pour prendre l'exemple de gcc, ils ont un langage intermédiaire sur lequel ils font un paquet d'optimisation, et il est partagé par plusieurs front-end. Dit autrement, il y a un pseudo langage vers lequel les "vrais" langages sont traduits, puis ce pseudo langage est optimisé et traduit en ASM. Mais le C++ ne passe bien sur plus par du C.Citation:
d'où le C++ est en fait "pseudo" traduit en C, puis compilé en C
De même que le C n'est qu'un moyen d'utiliser de l'assembleur, et l'assembleur un moyen d'utiliser le langage machine. Donc en poussant un peu le raisonnement, pour faire un OS, il faut acheter des tambours Nintendo, écrire "1" sur celui de droite, "0" sur celui de gauche, et c'est parti mon kiki :-pCitation:
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 !
Je n'ai jamais entendu parler de génération de langage de programmation. Tu peux développer et nous donner un ou deux liens ?Citation:
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.
En terme de volume, comparé au code C, c'est sûr, il n'y a quasiment rien. En revanche, en terme d'importance, c'est loin d'être "nul" ou "insignifiant". Le coeur du coeur d'un OS de si grande qualité est forcément dépendant de l'architecture. Les instruction pour faire basculer le proc en mode noyaux, pour faire mumuse avec les tables de gestion de mémoire ou j'en passe se doivent d'être en ASM.Citation:
Envoyé par InOCamlWeTrust
Et si je ne m'abuse, il y a aussi du C réoptimisé à la main après compilation.
Citation:
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.
Citation:
Envoyé par alex_pi
Au passage, les langages de troisième génération existent déjà :
http://en.wikipedia.org/wiki/Third-g...mming_language
En bas, tu as un : Programming language generations qui te montre toutes les générations.
au passage, je signale que des langages comme systemC sont capables de générer du code et les drivers associés à l'architecture matérielle sous-jacente... je me demande si un OS ne serait pas codable avec :koi:
Bon, je vois que vous êtes tous là pour faire des petites remarques visant à ce que chacun est plus ou moins raison.
Cependant, mon post n'etait pas là pour dire de faire son propre langage mais juste pour dire qu'avant de faire un OS, je pense qu'il faut avoir d'autre question que plutot savoir dans le langage dans lequel on va le programmer.
A ce niveau de technicité le choix du langage devient futile, et en posant tout les problèmes sur une feuille de papier on arrive à trouver son bonheur !
Sur ce, je vous laisse à vos discutions ...
Le SystemC que je connais, c'est essentiellement une bibliotheque pour du C++.Citation:
Envoyé par gorgonite
Un langage que je n'ai pas vu cite et qui pourtant est celui que j'aurais tendance a employer, c'est Ada.
Citation:
Envoyé par Jean-Marc.Bourguet
certes, mais il n'est pas impossible de "compiler" le système vers ce qu'on souhaite... VHDL, asm & cie :)
Mais dans le cadre de realisation d'un OS, ca revient a ecrire l'OS en C++.Citation:
Envoyé par gorgonite
Les HDL (Hardware Description Languages -- Verilog, VHDL, SystemC etc) sont globalement inadaptes a l'ecriture d'OS (un exercice de ce point de vue: comparer les taches d'Ada et les process de VHDL).
La première question à se poser c'est surtout l'architecture visée (ou les architectures visées), tu ne gereras pas par exemple la mémoire de la même façon sur un processeur de type x86 et un PowerPC. Encore que, même en prenant les procs de types x86 encore faudra t il se poser la question : mode réel ou mode protégé. Les OS utilisent le mode protégé car il permet le task switching, la protection de la mémoire et aussi permet de gérer la mémoire virtuelle (pagination). Le mode réel était utilisé par DOS il me semble.Citation:
Envoyé par CORBASE
Le langage n'est pas le plus gros probleme, le point commun c'est qu'il y aura forcément une partie assembleur afin d'utiliser des instructions trés spécifiques qu'on ne retrouve pas dans les langages plus haut niveau (pour ceux qui ont tripatouillés avec le pmode des x86 je pense notemment au chargement de la GDT, LDT, Hard task switching etc..). En tous cas c'est un projet sacrément passionant que de se lancer la dedans :) Java ou C peu importe ;)
Pascal, python, C, C++, CLI, C# , Java, VB...
Finalement, les programmes ne sont que du texte traduit en asm, puis en 0 et en 1...
Citation:
Envoyé par Pfranco
Et alors ? Un fichier exécutable n'est pas exécutable en tant que tel, il est nécessaire que le système charge le fichier, passe en mode utilisateur et l'exécute (temporairement).... Comment fais-tu pour outrepasser cela en python ?
Et en C ? La question n'est pas là.
Ca dépend de quel partie de l'OS tu parles...Citation:
Envoyé par InOCamlWeTrust
Il y a souvent des options de compilation particulier pour se débarasser des entêtes PE et compagnie. C'est ce que j'avais déjà utilisé pour un ordinateur particulier avec un M68k qui n'avait pas de système d'exploitation dessus.
Cependant, il y a toujours des problèmes pour certaines instructions particulières, comme il a déjà été dit (passage mode noyau/utilisateur...)
Evidemment, si tu as un compilateur particulier python qui permet de faire cela...
Tu demandes à ton linkeur de générer du code éxécutable uniquement (.com 16 bits par exemple), place maintenant ton programme (et le mot magique ...) sur le premier secteur d'une disquette, redémarre ton pc en bootant à partir de la disquette et obseve!Citation:
Envoyé par InOCamlWeTrust
Moi j'ai fait du Shell pour ça
Citation:
Envoyé par capucine1983
Tu pourrais expliquer car quelque chose m'échappe...
Tu ne confondrais pas "faire de la programmation système" ou "intéragir avec le système" et "programmer un système d'exploitation". Parce qu'effectivement, la plupart des appels systèmes peuvent être fait depuis un shell, mais il est clair que tu ne peux pas faire un système d'exploitation en Bash :-)Citation:
Envoyé par capucine1983
shell est l’interpréteur de commandes qui fait office d'interface entre l'utilisateur et le système d’exploitation.c'est pour ça que j'ai parlé du Shell.donc c'est "intéragir avec le systéme".je sais pas si j'ai du mal comprendre la question initiale