Discussion :

[nschoe]

Bonjour,

Voilà, ça fait un petit boût de temps que ça me trotte dans la tête, et j'avoue avoir vaguement tenté (mais sans une grande motivation ni préparation) l'apprentissage de l'Assembleur. J'ai maintenant pris du recul, et j'aimerais refaire un essai (plus sérieusement cette fois-ci), mais j'ai au préalable une petite question.

Bien sûr, je ne sais pas par où commencer : il y a plusieurs Assembleur, plusieurs architectures de processeur, il y a le 16 bit, le 32 et le 64 ... bref pour un débutant c'est un peu déroutant, ceci dit j'ai lu quelques sujet du forum (mais finallement peu, puisqu'il faut quand même des connaissances pour comprendre ne serait-ce que les problèmes que les gens posent) et il m'a semblé lire que le 16 bit était devenu trop obsolète (en tous cas sur les PCs : je ne veux pas travailler sur des micro-controller, ni des ordinateurs qui sont très anciens et que je n'ai pas connu) et donc qu'il fallait commencer par apprendre en 32 bit (puisque d'après ce que je comprends, 64 bit n'est pas encore assez répandu et est trop complexe pour débuter), mais arrêtez moi si je m'égare.

J'ai donc lu le topic "Important" qui m'a emmené vers ce tuto. Et c'est sur ce point que j'aimerais avoir votre opinion : j'ai commencé à le lire, et il semblerait (en tous cas dans ce que j'ai lu) que l'auteur (que je remercie au passage pour son tuto) parlait de Windows (j'ai vu "fichiers COM et EXE" ; personellement je développe sous MAC OS X et Linux), et les exemples étaient donnés en 16 bit : d'où mon interrogation, est-ce que selon-vous je devrais commencer par lire ce tuto et l'apprendre "comme la Bible" ? Ou est-ce qu'il est maintenant un peu dépassé et le cas échéant, que me conseillerez-vous à la place ?

Je me permets de donner une petite information : je souhaiterais apprendre l'Assembleur dans le but de "toucher" un petit peu à la programmation d' "OS" (je mets "OS" entre guillemets parce que je pense qu'avant de pouvoir appelé "OS" le boût de code que je produirai, il peut se passer longtemps.

Voilà, d'avance merci pour vos réponses & conseils !

[Obsidian]

Eh bien, étant donné que tu as déjà parfaitement analysé la situation, tu devrais pouvoir démarrer par le 32 bits.

Seul hic : on trouve énormément de références au 16 bits, beaucoup moins au 32 bits, parce que l'assembleur a perdu un peu la cote avec les systèmes d'exploitation multitâches en mode protégé et l'accélération des processeurs, qui rendaient le développement en langage machine respectivement plus compliqué et moins utile.

D'autre part, ce que l'on appelle « 16 bits » et « 32 bits » se réfèrent souvent à l'architecture des x86. De fait, si tu travailles un peu sur PC, c'est toujours utile de savoir comment fonctionne le mode réel, si tu fonctionnes exclusivement sur Mac, c'est moins utile.

[nschoe]

Bonjour !

Merci bien pour votre réponse, si rapide qui plus est. Mais si vous me le permettez, j'aurais encore quelques questions à soulever.

Après avoir posté, je ne suis pas resté inactif, et j'ai cherché quelques réponses, et je suis face à un petit désagrément : j'avais supposé que vous répondriez ce que vous avez répondu, alors j'ai cherché des tutos/cours sur le 32 bit et comme vous le dîtes ils sont plus rares.
J'ai d'abord visité le lien de Pépin (qui est dans le forum "Programmation d'OS"), mais j'ai remarqué qu'il fallait déjà un certain niveau, en effet (dans le début du tuto au moins) les registres ne sont pas expliqués en détails, ni comment est-ce que la mémoire fonctionne (notion d'offset ...) Donc j'ai mis en favoris et j'ai cherché un autre cours qui m'expliquerait les bases. Je suis tombé sur le site de Paul Carter (depuis le temps que j'en entends parler !). Je n'ai pas lu beaucoup, peut-être les 3-4 premières pages.

Maintenant, je me rends compte qu'avec ce que j'ai pour le moment, ça reste quand même le tuto que je mentionne dans mon premier post qui reste le plus informatif au niveau des pré-requis : le tuto explique un petit peu l'adresse de la mémoire en mode réel, la notion de complément à 2 etc. Tout ce que je qualifierais "de base".

À force de "fouiner" et traîner sur des forum qui parlent de programmation d'OS, j'ai retenu quelques phrases, quelques expressions, quelques conseils parfois, mais n'y connaissant pour le moment rien, j'ai une autre question : dans ma tête (et corrigez moi absolument si je dis une énormité), un OS c'est en gros : le "bootloader" (="secteur de boot" ou pas ?) écrit en ASM est chargé de ... charger le "noyau" (="kernel" ou pas ?) en mémoire et de l'exécuter, ce "noyau" est codé en C (le plus souvent). Pour moi c'est ça (donc je suis certain d'oublier une myriade de choses, et de dire une énormité, mais bon) et donc j'aurais voulu savoir s'il était utile d'apprendre le mode réel en Assembleur ou si on pouvait se contenter du mode protégé.

Parce qu'en ignorant que je suis, je ne sais pas où est utilisé vraiment l'Assembleur : est-ce que le "bootloader" doit être programmé en mode réel obligatoirement ? Ou est-ce qu'il peut être programmé en mode protégé ? Ou est-ce que je demande n'a pas de sens ?

Bien à vous, merci d'avance !

[Obsidian]

J'ai d'abord visité le lien de Pépin (qui est dans le forum "Programmation d'OS"), mais j'ai remarqué qu'il fallait déjà un certain niveau, en effet (dans le début du tuto au moins) les registres ne sont pas expliqués en détails, ni comment est-ce que la mémoire fonctionne (notion d'offset ...) Donc j'ai mis en favoris et j'ai cherché un autre cours qui m'expliquerait les bases. Je suis tombé sur le site de Paul Carter (depuis le temps que j'en entends parler !). Je n'ai pas lu beaucoup, peut-être les 3-4 premières pages.

Si vous avez l'intention de descendre à ce niveau, écrire un proto-système d'exploitation, comprendre comment ça marche, etc. alors oui : commencez par le 16 bits et embrayez sur le 32. Avec de la motivation (et de bonnes explications), vous pourrez acquérir le premier relativement vite et cela vous servira même si vous ne l'utilisez plus par la suite.

Si vous avez des questions sur les registres en particulier, n'hésitez pas à les poser ici.

Grosso-modo, en ce qui concerne les segments et les offsets, en soulignant bien que tout cela n'est vrai que sur x86 (les autres architectures utilisent des systèmes similaires mais qui leur sont propres) : il faut savoir que les segments et offsets du mode réel et ceux du mode protégé ne fonctionnent pas de la même façon.

« offset », ça veut dire décalage. C'est donc une adresse relative par rapport à un point de départ donné. Mais bien souvent, c'est synonyme d'adresse mémoire, tout court. Au départ, on n'utilisait que cela pour repérer un endroit en mémoire, car le bus d'adresse du microprocesseur était large de 16 bits (on pouvait compter physiquement seize broches dédiées au bus d'adresse sur le boîtier du microprocesseur). Les registres d'index faisaient la même largeur, et ça fonctionnait très bien.

Ensuite, avec 16 bits, on peut adresser 64 Kio. C'est-à-dire qu'on ne peut voir que 65536 octets différents à la fois. Pour gagner en mémoire, on faisait de la pagination, c'est-à-dire que l'on choisissait la page de mémoire que l'on souhaitait rendre visible par le processeur à un moment donné, toutes les pages occupant virtuellement le même espace.

Au bout d'un moment, c'est devenu franchement trop limité, même pour une application seule. Le bus des Intel a alors gagné quatre bits, passant de 16 à 20, ce qui permettait donc d'adresser en une fois 1 Mio, ce qui était énorme pour l'époque. Le problème, c'est qu'il fallait des registres de 20 bits, et ça, c'était très compliqué à concevoir. Par contre, il était très simple d'intégrer dans l'architecture courante deux registres de 16 bits.

Ainsi sont nés les segments en mode réel. Les registres de segment et d'offset sont électroniquement additionnés pour donner l'adresse physique réelle sur 20 bits, mais le registre de segment est décalé de 4 bits par rapport au registre d'offset. Il vaut donc 16 fois plus. Donc, écrire en 0001:0000 revient exactement à écrire en 0000:0010, par exemple.

On charge donc manuellement les registres de segment et le processeur se comporte ensuite normalement à l'endroit où on lui a dit de travailler. Ceci permet donc de placer une fenêtre de 64 Kio n'importe où en mémoire avec une granularité de 16 octets. C'est pratique parce que le micro-processeur ainsi formé reste parfaitement compatible avec les précédents et on peut facilement charger plusieurs programmes en mémoire (faciles à reloger), même ceux prévus encore une fois pour les anciennes architectures.

Maintenant, en mode protégé et surtout depuis l'architecture 32 bits (à partir du 386, le 286 était doté d'un mode protégé mais restait 16 bits), les registres de segment et les registres d'offset font tous 32 bits, ce qui est la largeur du bus
physique et permet d'adresser jusqu'à 4 Gio d'un coup.

En mode protégé, donc, on définit un certain nombre de segments d'une longueur arbitraire en mémoire, et on les « numérote » en les déclarant à places fixes au sein d'une table. Les registres de segment contiendront alors le numéro de ce segment. Les différents processus auront alors le droit ou non d'accéder à tel ou tel segment. S'ils lisent ou écrivent en dehors, ou accèdent à un segment sans en avoir l'autorisation, le micro-processeur cesse de lui-même l'exécution du programme en cours et déclenche une « exception » (forme d'interruption logicielle) derrière laquelle on trouvera une routine chargée d'y mettre fin. Ceci se traduit par « segmentation fault » sous Unix ou par une belle boîte de dialogue sous Windows disant « l'adresse 0x-------- ne peut pas être read/write ... ».

À force de "fouiner" et traîner sur des forum qui parlent de programmation d'OS, j'ai retenu quelques phrases, quelques expressions, quelques conseils parfois, mais n'y connaissant pour le moment rien, j'ai une autre question : dans ma tête (et corrigez moi absolument si je dis une énormité), un OS c'est en gros : le "bootloader" (="secteur de boot" ou pas ?) écrit en ASM est chargé de ... charger le "noyau" (="kernel" ou pas ?) en mémoire et de l'exécuter, ce "noyau" est codé en C (le plus souvent). Pour moi c'est ça (donc je suis certain d'oublier une myriade de choses, et de dire une énormité, mais bon) et donc j'aurais voulu savoir s'il était utile d'apprendre le mode réel en Assembleur ou si on pouvait se contenter du mode protégé.

Un O.S. est un « Operating System », soit un système d'exploitation, en français. Donc, quelque chose comme Windows ou Linux. Il est illusoire, aujourd'hui, de vouloir rebâtir un système d'exploitation entier soi-même. Cela demande des décenies à des centaines de personnes travaillant de concert.

Le bootloader, qu'on appelle aussi parfois « amorce », est le morceau de programme qui va servir à charger le reste ou, à tout le moins, une partie conséquente depuis laquelle on pourra de manière beaucoup plus confortable charger tout le reste.

Sur PC, à l'allumage, il n'y a rien en mémoire. Que de la RAM vierge. La seule exception est ce qui est contenu dans le BIOS, en mémoire Flash ou ROM. Ça permet à la machine elle-même de démarrer, de faire ses contrôles à l'allumage, puis, ne sachant rien faire d'autre, de charger le premier secteur de la disquette ou du disque dur quand il est présent (ce qui est toujours le cas depuis 1990). À charge au développeur d'y mettre quelque chose qui permettent d'embrayer sur la suite.

Le « noyau » d'un système d'exploitation, c'est le minimum requis pour pouvoir faire fonctionner des applications. On y trouve au moins la gestion de la mémoire, l'ordonnancement des processus, les systèmes de communication inter-processus, la gestion des disques et au moins un système de fichier. Le tout est chargé en une fois et est démarré à partir d'un point fixe. À ce stade, on peut lire des fichiers (donc des exécutables et des bilbliothèques) et lancer des processus. Tout ce qui va derrière peut donc être lancé en tant que programme ordinaire, être soumis au mode protégé comme le reste, et n'a donc pas besoin de faire partie du noyau.

Viennent ensuite les pilotes de périphériques (depuis la mémoire vidéo, le chipset, jusqu'à l'imprimante en passant par les périphériques de communication tels que réseau, port série, USB, etc ...). Il y a débat permanent pour savoir s'ils doivent faire ou non partie du noyau. Certes, le pilote d'une carte vidéo 3D a besoin d'avoir une vue assez proche du matériel. Un pilote d'impression, en revanche, peut très bien fonctionner en tant qu'application utilisateur.

Certains sont adeptes des micro-noyaux (en mettre le moins possible dans le noyau), d'autres, comme Linus Torvalds, aiment les gros noyaux monolithiques. Cela a donné lieu à un troll historique entre lui et Andrew Tanenbaum. Même si l'approche à micro-noyaux semble être la plus sûre de prime abord, le temps a montré avec le noyau Linux que l'approche monolithique donnait de très bons résultats également.

Parce qu'en ignorant que je suis, je ne sais pas où est utilisé vraiment l'Assembleur : est-ce que le "bootloader" doit être programmé en mode réel obligatoirement ? Ou est-ce qu'il peut être programmé en mode protégé ?

C'est une bonne question car, historiquement, les P.C. démarraient normalement en mode réel et c'est le système d'exploitation - ou l'application autonome, ça arrivait dans le temps - qui passait en mode protégé et continuait. Aujourd'hui, je ne sais plus comment démarrent les BIOS récents. Mais en tout état de cause, rien ne vous empêche, bien sûr, de passer vous-même en mode protégé dès le boot. La seule chose qui pourrait vous en empêcher est la taille du secteur : 512 octets. C'est peut-être un peu limite pour tout mettre en place.

[nschoe]

Bonsoir et tout d'abord un grand grand merci pour cette réponse ô combien riche en explications et éclaircissements pour moi !

Si vous avez l'intention de descendre à ce niveau, écrire un proto-système d'exploitation, comprendre comment ça marche, etc. alors oui : commencez par le 16 bits et embrayez sur le 32. Avec de la motivation (et de bonnes explications), vous pourrez acquérir le premier relativement vite et cela vous servira même si vous ne l'utilisez plus par la suite.

C'est noté, donc je poursuis ma lecture du tuto de Benoît-M et je redouble d'attention. Par contre, deux petites questions, cependant : vous parlez de "proto-système d'exploitation", qu'entendez-vous par là ? Ensuite, vous me conseillez de "commencer par le 16 bit" et je m'interroge : est-ce que je dois "simplement" (façon de parler) "apprendre le 16 bit" (idem) ou est-ce que par "commencez par le 16 bit" vous entendez que je devrais commencer à faire des tests (mini bootloader etc) en 16 bit et ensuite une fois les principes acquis, recommencer en 32 ?

En ce qui concerne la segmentation de la mémoire, je pense que j'ai compris le principe sous-jacent, le tuto de Benoît-M est relativement bien illustré, de plus vos explications corroborent ce que j'avais en tête.

Il est illusoire, aujourd'hui, de vouloir rebâtir un système d'exploitation entier soi-même. Cela demande des décenies à des centaines de personnes travaillant de concert.

Je conçois totalement que c'est une tâche énorme que de concevoir un système d'exploitation performant, entier, qui fonctionnent sur plusieurs architectures, optimisé etc et que ça prend un temps extrêmement important à une équipe organisée de développeurs, cependant mon but n'est pas de produire un système d'exploitation qui soit utilisé par d'autres, ni de produire un OS totalement optimisé, ni de faire un OS adaptable à plusieurs architectures, je ne compte pas non plus avoir l'impétuosité de prévoir une possible compatibilité avec un système actuel (Windows, Mac OS, Linux ...) ; je ne compte en aucun cas penser pouvoir produire une quelconque alternative à un OS commercialisé et équipant les PC actuels.
Je vois plus la conception d'OS comme un exercice, au même titre qu'à nos débuts en POO on essayait de reproduire la Class "String" (je pense au C++) : nous n'avions pas l'ambition de proposer une alternative à la STL, mais bien de s'entraîner pour comprendre comment fonctionne la véritable class "String". De manière similaire, je vois la conception d'OS comme une possibilité de découvrir et d'apprendre quelques principes (parce que je n'ai pas non plus la prétention de penser survoler la totalité des principes participant au fonctionnement d'un OS) du fonctionnement d'un OS.
Je veux "juste" comprendre, apprendre, je ne suis donc pas pressé par le temps (je n'ai pas l'impératif de sortir telle version pour telle date), ni par des contraintes de compatibilité (si j'arrive à faire fonctionner un "OS" sur mon PC ce sera déjà la plus belle des victoires).

charger le premier secteur de la disquette ou du disque dur quand il est présent (ce qui est toujours le cas depuis 1990)

Est-ce qu'il est nécessaire d'apprendre l'architecture d'un disque dur ou d'une disquette ? J'adore apprendre, cependant, le volume de connaissance concernant l'OS dev est déjà conséquent, inutile de m'encombrer l'esprit avec des choses qui ne sont pas utiles pour ce que je veux faire.
Je profite également que le sujet soit mentionné : le PC sur lequel je compte faire mes tests ne dispose pas de lecteur de disquette en état de fonctionner, est-ce qu'il est possible (aisé) de stocker le "noyau" sur une clef USB ou bien directement sur le disque dûr ?

Le « noyau » d'un système d'exploitation, c'est le minimum requis pour pouvoir faire fonctionner des applications. On y trouve au moins la gestion de la mémoire, l'ordonnancement des processus, les systèmes de communication inter-processus, la gestion des disques et au moins un système de fichier. Le tout est chargé en une fois et est démarré à partir d'un point fixe. À ce stade, on peut lire des fichiers (donc des exécutables et des bilbliothèques) et lancer des processus. Tout ce qui va derrière peut donc être lancé en tant que programme ordinaire, être soumis au mode protégé comme le reste, et n'a donc pas besoin de faire partie du noyau.

C'est probablement ce que j'ai le plus de mal à saisir, la différence entre noyau et système d'exploitation. Déjà est-ce que le noyau est obligatoirement écrit en Assembleur ? Je pense que oui, parce que pour parler de gestion de mémoire etc, mais je préfère être certain. Ensuite vous mentionnez "le reste", et "Tout ce qui va derrière", vous dîtes qu'il peut être lancé en tant que programme ordinaire. Ça veut dire qu'une fois le noyau codé, on implémente les autres fonctions du système d'exploitation sous forme de programmes "simples", en C par exemple ? Ensuite, j'aimerais comprendre, comment relie-t-on le noyau au "reste" ? Par des vulgaires "include" ? Comment est-ce que ça se passe lorsqu'on veut ajouter une fonctionnalité dans l'OS (qui ne fait pas partie du noyau j'entends), est-ce qu'on peut ne retoucher qu'au sources en C ? Ou bien faut-il modifier le noyau obligatoirement ?

Certains sont adeptes des micro-noyaux (en mettre le moins possible dans le noyau), d'autres, comme Linus Torvalds, aiment les gros noyaux monolithiques. Cela a donné lieu à un troll historique entre lui et Andrew Tanenbaum. Même si l'approche à micro-noyaux semble être la plus sûre de prime abord, le temps a montré avec le noyau Linux que l'approche monolithique donnait de très bons résultats également.

Est-ce que vous pourriez me donner les avantages/inconvénient de chaque méthode ? (Oui, je pense que j'exagère un peu !). Dans le cas de micro-noyaux, si on en met le moins possible, où va ce dont on a besoin et qui n'est pas inclu dans le micro-noyau ?
Dans le cas d'un débutant comme moi, quel cas serait-il mieux d'envisager ?

C'est une bonne question car, historiquement, les P.C. démarraient normalement en mode réel et c'est le système d'exploitation - ou l'application autonome, ça arrivait dans le temps - qui passait en mode protégé et continuait. Aujourd'hui, je ne sais plus comment démarrent les BIOS récents. Mais en tout état de cause, rien ne vous empêche, bien sûr, de passer vous-même en mode protégé dès le boot. La seule chose qui pourrait vous en empêcher est la taille du secteur : 512 octets. C'est peut-être un peu limite pour tout mettre en place.

Apparemment, il est plus aisé de travailelr en mode protégé, on est plus libre. Alors est-ce qu'il ne serait pas une bonne idée de faire le minimum de choses en mode réel, et de passer le plus tôt possible en mode protégé ? Finallement les 512 octets ne serviraient qu'à mettre en place ce dont on a besoin pour passer en mode protégé, non ? Est-ce que c'est utopique ? Ou tout simplement une mauvaise idée ?

___________

C'est avec un grand plaisir que j'ai lu votre réponse (et vos réponses en général, d'ailleurs !). Je sais que j'en demande peut-être un peu trop, mais si vous connaissez un livre, un tuto, une autre personne, un lien ou quoi que ce soit d'autre qui puisse répondre à mes questions, je prends !
Je remercie énormément pour le temps que vous passez à me lire et à me répondre, votre aide m'est d'un grand soutien !

[Obsidian]

C'est noté, donc je poursuis ma lecture du tuto de Benoît-M et je redouble d'attention. Par contre, deux petites questions, cependant : vous parlez de "proto-système d'exploitation", qu'entendez-vous par là ?

La même chose que vous, visiblement : je voulais dire un tout petit système qui ne sert à rien d'autre en lui-même que d'être didactique.

Ensuite, vous me conseillez de "commencer par le 16 bit" et je m'interroge : est-ce que je dois "simplement" (façon de parler) "apprendre le 16 bit" (idem) ou est-ce que par "commencez par le 16 bit" vous entendez que je devrais commencer à faire des tests (mini bootloader etc) en 16 bit et ensuite une fois les principes acquis, recommencer en 32 ?

Très franchement, à ce stade, j'ai envie de répondre « comme vous le sentez ». Ça ne sert à rien d'apprendre quelque chose sans faire un peu de travaux pratiques derrière, de toutes façons. Si vous voulez une ligne directrice, disons que vous pouvez vous faire la main avec la miriade d'exercices en 16 bits que l'on trouve partout. Ça évitera de perdre trop de temps à creuser soi-même. Lorsque vous êtes à l'aise avec (comprendre : lorsque les résultats obtenus sont exactement ceux auxquels vous vous attendiez), embrayez dès que possible sur le 32 bits, et faites-en un maximum.

je vois la conception d'OS comme une possibilité de découvrir et d'apprendre quelques principes (parce que je n'ai pas non plus la prétention de penser survoler la totalité des principes participant au fonctionnement d'un OS) du fonctionnement d'un OS.

Un « système d'exploitation », c'est un logiciel qui va permettre à l'utilisateur d'exploiter sa machine. À partir de là, cela peut prendre n'importe quelle forme.

Mais pour tenter de généraliser, on peut dire que ce logiciel doit être capable de démarrer par lui-même (au boot), de permettre à l'utilisateur de lancer des programmes, ce qui implique la gestion d'un système de fichiers, la définition d'un format de fichier exécutable (formant ensuite les programmes proprements dits), la fourniture d'une interface pour communiquer avec l'utilisateur - cela peut être une simple ligne de commande, ou une interface graphique évoluée - et de piloter tous les périphériques de la machine, d'une façon ou d'une autre.

Évidemment, la définition reste floue est n'est pas gravée dans le marbre.

De plus, si votre machine est une machine dédiée à une tâche précise (piloter une machine-outil, par exemple). Elle n'a pas forcément besoin de système d'exploitation : le programmeur peut écrire un logiciel autonome qui se lance directement et qui la prenne en charge. Évidemment, on ne pourra rien faire d'autre à côté, et le moindre service à remplir (comme communiquer par la carte réseau, par exemple) peut demander des semaines entières de développement si c'est un tant soi peu ardu.

Est-ce qu'il est nécessaire d'apprendre l'architecture d'un disque dur ou d'une disquette ? J'adore apprendre, cependant, le volume de connaissance concernant l'OS dev est déjà conséquent, inutile de m'encombrer l'esprit avec des choses qui ne sont pas utiles pour ce que je veux faire.

Le principe général de fonctionnement, certainement. Les détails techniques de tous les drives, non, et heureusement. Un disque dur fonctionne à peu de choses près comme une disquette. Une disquette est un disque magnétique emprisonné dans une carcasse en plastique, qui est survolé par une tête de lecture comparable à celle d'un magnétophone. Cette tête de lecture avance et recule par « pas », ce qui fait que ladite tête survole des cercles concentriques et ne suit pas un sillon, comme sur un vinyl ou un CD. Ça veut dire aussi que la tête resurvole la même zone à chaque tour de disque.

Chacun de ces cercles est appelé « piste ». Il y en a 80 sur une disquette 3,5" de PC, beaucoup plus sur un disque dur. Cette piste a une longueur donnée, que l'on découpe en tronçons numérotés contenant chacun un nombre fixe d'octets, généralement 512, surtout sur PC, mais cela peut être 128 ou 256 sur de vieux ordinateurs. Ces tronçons alignés sur chaque piste forment des espèces de « part de gâteau » vus d'au-dessus, c'est pourquoi on les a appelés « secteurs ».

Toujours sur PC, il y a 18 secteurs par piste. Comme il y a deux faces sur une disquette, cela fait donc un espace total de 18 * 80 * 512 * 2 / 1024 = 1,44 Mio sur une disquette HD ordinaire. Et exactement 1440 secteurs par face, tous de capacités identiques.

Au boot, le PC ira lire le premier secteur de la première face du premier périphérique qu'il trouvera (disquette ou disque dur, enfin surtout en fonction de la configuration du BIOS), en chargera le contenu, vérifiera qu'il est cohérent - il y a une petite signature de deux octets pour indiquer qu'il s'agit bien d'un programme exécutable et pas d'un secteur vide - et exécutera ce contenu. On ne peut pas faire plus simple.

Par la suite, les autres périphériques de stockage ont adopté ce système de secteurs eux-aussi.

Je profite également que le sujet soit mentionné : le PC sur lequel je compte faire mes tests ne dispose pas de lecteur de disquette en état de fonctionner, est-ce qu'il est possible (aisé) de stocker le "noyau" sur une clef USB ou bien directement sur le disque dûr ?

Sur le disque dur, oui. Assurez-vous toutefois qu'il ne contienne rien d'important.
Sur une clé USB, ça dépend du BIOS. S'il est trop vieux, il ne sera peut-être pas conçu pour démarrer sur une clé USB.

C'est probablement ce que j'ai le plus de mal à saisir, la différence entre noyau et système d'exploitation.

C'est une question de point de vue. Pour exploiter sa machine, il faut un maximum d'outils et de services. Le noyau contient donc toutes les infrastructures nécessaires à l'exécution d'un programme et/ou à l'utilisation de bibliothèques. Une fois que ça marche, on s'appuie sur cette base pour écrire tous les outils dont l'utilisateur peut avoir besoin et on livre le tout dans une même boîte.

Certains, cependant, affirment que le système d'exploitation, c'est justement le noyau seul. Encore un débat dont tous les points de vue se défendent.

Déjà est-ce que le noyau est obligatoirement écrit en Assembleur ? Je pense que oui, parce que pour parler de gestion de mémoire etc, mais je préfère être certain.

Non. Il peut être majoritairement codé en C, par exemple. C'est d'ailleurs le cas de pratiquement tous les systèmes d'exploitation actuels, à commencer par Linux.

Simplement, quand on code un système d'exploitation, on arrive forcément à un stade où le langage choisi ne permet plus d'exprimer ce que l'on veut faire. C'est pour ainsi dire toujours le cas quand on en arrive à gérer le microprocesseur lui-même par exemple. Il n'y a pas d'instruction en C pour passer en mode protégé : il faut utiliser les instructions dédiées du micro-processeur, et donc faire un peu d'assembleur.

Ensuite vous mentionnez "le reste", et "Tout ce qui va derrière", vous dîtes qu'il peut être lancé en tant que programme ordinaire. Ça veut dire qu'une fois le noyau codé, on implémente les autres fonctions du système d'exploitation sous forme de programmes "simples", en C par exemple ?

Tout-à-fait.

Ensuite, j'aimerais comprendre, comment relie-t-on le noyau au "reste" ? Par des vulgaires "include" ?

Attention : « #include <...> », en C, ne fait qu'inclure dans votre code un fichier de prototypes de fonctions pour lui dire comment on s'en sert. La véritable liaison a lieu à l'édition des liens, juste après la compilation. Mais ça, c'est vrai pour tous les programmes.

Pour relier les applications au noyau, celui-ci propose un ensemble de primitives que l'on exploite comme des fonctions ordinaires. Sous Unix, ce sont les fameux « appels système » que l'on trouve dans la section 2 du manuel (« man 2 .... ») là où les fonctions ordinaires sont décrites dans la section 3.

Au niveau assembleur, si vous travaillez en mode réel, l'application ne verra pas de différence entre le noyau et une vulgaire bibliothèque partagée. En mode protégé, par contre, le noyau est plus privilégié que les applications. Retourner du noyau vers les applications ne demande rien de particulier (qui peut le plus peut le moins). En revanche, pour faire l'inverse, il faut d'abord gagner les privilèges nécessaires. Pour cela, on va utiliser des call gates. Il s'agit de points d'entrée strictement définis dans un segment de privilège supérieur. C'est par ceux-là exclusivement que l'on pourra appeler une fonction du noyau.

Comment est-ce que ça se passe lorsqu'on veut ajouter une fonctionnalité dans l'OS (qui ne fait pas partie du noyau j'entends), est-ce qu'on peut ne retoucher qu'au sources en C ? Ou bien faut-il modifier le noyau obligatoirement ?

Ça, ça dépend de l'O.S, et de ce que vous voulez faire. Il y a des choses qui n'auront absolument pas besoin de faire partie du noyau, et il y en a d'autres qui, au contraire, devront vraiment s'y trouver au cœur. Dans tous les cas, la documentation de ton O.S. vous fournira une liste d'A.P.I. - les interfaces - qui prendront la forme d'une liste de fonctions pour chaque contexte.

Téléchargez le noyau Linux sur kernel.org si ce n'est pas déjà fait. Vous en aurez les sources entières et vous verrez comment il est architecturé.

Est-ce que vous pourriez me donner les avantages/inconvénient de chaque méthode ? (Oui, je pense que j'exagère un peu !). Dans le cas de micro-noyaux, si on en met le moins possible, où va ce dont on a besoin et qui n'est pas inclu dans le micro-noyau ?

Dans des bibliothèques partagées. « .DLL » sous Windows ou « .so » sous Unix, ainsi que par l'intermédiaire de services (daemons) fonctionnant en tâche de fond.

Dans le cas d'un débutant comme moi, quel cas serait-il mieux d'envisager ?

...

Apparemment, il est plus aisé de travailelr en mode protégé, on est plus libre. Alors est-ce qu'il ne serait pas une bonne idée de faire le minimum de choses en mode réel, et de passer le plus tôt possible en mode protégé ? Finallement les 512 octets ne serviraient qu'à mettre en place ce dont on a besoin pour passer en mode protégé, non ? Est-ce que c'est utopique ? Ou tout simplement une mauvaise idée ?

Chaque chose en son temps.

Commencez par un programme 16 bits depuis votre système d'exploitation préféré. Vous pouvez utiliser NASM, par exemple. Ensuite, faites la même chose en 32 bits.

Puis, écrivez un secteur de boot en assembleur et en mode réel. Voyez les interruptions du BIOS pour cela. Si vous parvenez à écrire « HELLO WORLD » et stopper sur une boucle infinie dès la mise sous tension de votre ordinateur, sans avoir chargé un O.S. au préalable, ce sera déjà beaucoup.

Ensuite, vous pourrez essayer de faire la même chose en mode protégé.

Seulement alors, vous pourrez envisager un petit noyau. Mais ça risque de vous prendre beaucoup de temps.

C'est avec un grand plaisir que j'ai lu votre réponse (et vos réponses en général, d'ailleurs !). Je sais que j'en demande peut-être un peu trop, mais si vous connaissez un livre, un tuto, une autre personne, un lien ou quoi que ce soit d'autre qui puisse répondre à mes questions, je prends !

Commencez par les liens en haut de la page :

F.A.Q. assembleur ;
Tutoriels assembleur.

Dans la F.A.Q., lisez particulièrement l'entrée sur les rings 0,1,2,3.

[nschoe]

Bonsoir !

Encore une fois, merci de votre réponse !

La même chose que vous, visiblement : je voulais dire un tout petit système qui ne sert à rien d'autre en lui-même que d'être didactique.

C'est noté, je pensais que se cachait une notion plus abstraite ^^.

Très franchement, à ce stade, j'ai envie de répondre « comme vous le sentez ». Ça ne sert à rien d'apprendre quelque chose sans faire un peu de travaux pratiques derrière, de toutes façons. Si vous voulez une ligne directrice, disons que vous pouvez vous faire la main avec la miriade d'exercices en 16 bits que l'on trouve partout. Ça évitera de perdre trop de temps à creuser soi-même. Lorsque vous êtes à l'aise avec (comprendre : lorsque les résultats obtenus sont exactement ceux auxquels vous vous attendiez), embrayez dès que possible sur le 32 bits, et faites-en un maximum.

Oui je comprends, par contre une question : j'ai fini de lire et de comprendre le tuto de Benoît-M, cependant j'aimerais faire les exemples de code, mais je ne développe pas du tout sous Windows, alors je me demandais s'il y avait de nombreuses modifications à faire. Si le fait de développer sous Mac OS (en plus de Linux) complique un peu, je préfère me restreindre à développer sous Linux. J'ai lu quelques sujet sur le forum et je pense utiliser NASM (je code essentiellement avec emacs), par contre, quel choix de linker serait judicieux ?
Ensuite, dans le tuto, il y a une partie (celle où est donné l'exemple du "crypyeur" de fichier) sur les interruptions du DOS : je suppose que sous Linux on ne peut pas les utiliser, alors comment est-ce qu'on remplace les instruction ? ENsuite, (c'est pour un petit peu plus tard), quels sont les exercices recommandés pour débuter ?

Chacun de ces cercles est appelé « piste ». Il y en a 80 sur une disquette 3,5" de PC, beaucoup plus sur un disque dur. Cette piste a une longueur donnée, que l'on découpe en tronçons numérotés contenant chacun un nombre fixe d'octets, généralement 512, surtout sur PC, mais cela peut être 128 ou 256 sur de vieux ordinateurs. Ces tronçons alignés sur chaque piste forment des espèces de « part de gâteau » vus d'au-dessus, c'est pourquoi on les a appelés « secteurs ».

Toujours sur PC, il y a 18 secteurs par piste. Comme il y a deux faces sur une disquette, cela fait donc un espace total de 18 * 80 * 512 * 2 / 1024 = 1,44 Mio sur une disquette HD ordinaire. Et exactement 1440 secteurs par face, tous de capacités identiques.

C'est noté, donc suivant cette logique, plus on se rapproche du centre de la disquette, moins on peut stocker de donnée sur la piste ?

u boot, le PC ira lire le premier secteur de la première face du premier périphérique qu'il trouvera (disquette ou disque dur, enfin surtout en fonction de la configuration du BIOS), en chargera le contenu, vérifiera qu'il est cohérent - il y a une petite signature de deux octets pour indiquer qu'il s'agit bien d'un programme exécutable et pas d'un secteur vide - et exécutera ce contenu. On ne peut pas faire plus simple.

Ce premier secteur de la première piste de la première face, est-ce que c'est le fameux MBR ? Et est-ce que GRUB (pour ne citer que lui) est justement à cette emplacement ? (GRUB est-il un bootloader ?)

Par la suite, les autres périphériques de stockage ont adopté ce système de secteurs eux-aussi.

Pourtant comment former des secteurs sur un CD puiqu'il est constitué d'un sillon ? Est-ce que c'est le même principe de secteurs, mais qu'il n'y a qu'une seule "grosse" piste ?
Et dans le cas d'une clef USB, c'est encore différent : est-ce qu'il y a aussi un "premier secteur" dans lequel mettre notre bootloader ? (Le BIOS de l'ordinateur que je souhaite utiliser accepte de démarrer sur une clef USB).

Non. Il peut être majoritairement codé en C, par exemple. C'est d'ailleurs le cas de pratiquement tous les systèmes d'exploitation actuels, à commencer par Linux.

Simplement, quand on code un système d'exploitation, on arrive forcément à un stade où le langage choisi ne permet plus d'exprimer ce que l'on veut faire. C'est pour ainsi dire toujours le cas quand on en arrive à gérer le microprocesseur lui-même par exemple. Il n'y a pas d'instruction en C pour passer en mode protégé : il faut utiliser les instructions dédiées du micro-processeur, et donc faire un peu d'assembleur.

Et quelle serait la manière "propre" de faire ? Est-ce qu'il faut "prévoir" tout ce dont on va avoir besoin de faire en Assembleur, et l'intégrer en premier, de façon à pouvoir développer le reste essentiellement en C ou C++ ? Ou bien est-ce qu'on est forcé d'utiliser de l'Assembleur inline ?

Pour relier les applications au noyau, celui-ci propose un ensemble de primitives que l'on exploite comme des fonctions ordinaires.

Ces primitives qui permettent de relier "le reste" au noyau, nous devons les définir et les créer nous même je suppose ?

Je vais essayer de lire les sources du kernel Linux, par contre, je suppose que c'est un morceau énorme, est-ce qu'il y a un moyen "favorisé" pour lire et comprendre le code ? (Je suppose qu'une bête lecture linéaire n'apportera pas ou peu de résultats).

Commencez par un programme 16 bits depuis votre système d'exploitation préféré. Vous pouvez utiliser NASM, par exemple. Ensuite, faites la même chose en 32 bits.

Puis, écrivez un secteur de boot en assembleur et en mode réel. Voyez les interruptions du BIOS pour cela. Si vous parvenez à écrire « HELLO WORLD » et stopper sur une boucle infinie dès la mise sous tension de votre ordinateur, sans avoir chargé un O.S. au préalable, ce sera déjà beaucoup.

Ensuite, vous pourrez essayer de faire la même chose en mode protégé.

Seulement alors, vous pourrez envisager un petit noyau. Mais ça risque de vous prendre beaucoup de temps.

Oui, je vais essayer de faire quelques programmes en Assembleur (16 bit pour le moment) depuis Linux. Par contre, comme je n'ai lu que le tuto de Benoît-M pour le moment, je ne sais à priori que faire des .COM et des .EXE qui sont réservés à Windows. Est-ce qu'il y a beaucoup de choses à modifier pour adapter le code à Linux ?

En ce qui concerne la rubrique sur les rings de la FAQ, elle n'est pas très complète, mais j'ai lu, je suppose que ça doit avoir un lien avec le niveaux d'autorisation que vous avez mentionnés.

Je vais de suite commencer à lire le tuto de Haypo sur l'Assembleur (il est dans la catégorie initiation). Par contre, j'ai une interrogation, il est dit "Programmation Assembleur (Intel)" : ça veut donc dire que je ne peux pas appliquer ceci sur mon processeur ADM Athlon 64 3700 + ? Je suis obligé de coder sur un processeur Intel ?
J'ai également vu une rubrique sur l'ASM sous GNU/Linux dans la page des tutos, je vais également la lire.

________

Encore un grand grand merci pour toutes vos réponsesje vous suis extrêmement reconnaissant, et sachez que vous faites un heureux !

[dapounet]

Bonjour,

Oui je comprends, par contre une question : j'ai fini de lire et de comprendre le tuto de Benoît-M, cependant j'aimerais faire les exemples de code, mais je ne développe pas du tout sous Windows, alors je me demandais s'il y avait de nombreuses modifications à faire. Si le fait de développer sous Mac OS (en plus de Linux) complique un peu, je préfère me restreindre à développer sous Linux. J'ai lu quelques sujet sur le forum et je pense utiliser NASM (je code essentiellement avec emacs), par contre, quel choix de linker serait judicieux ?
Ensuite, dans le tuto, il y a une partie (celle où est donné l'exemple du "crypyeur" de fichier) sur les interruptions du DOS : je suppose que sous Linux on ne peut pas les utiliser, alors comment est-ce qu'on remplace les instruction ? ENsuite, (c'est pour un petit peu plus tard), quels sont les exercices recommandés pour débuter ?

DOSbox fait tourner les programmes DOS sans problème. L'idéal serait que tu fasses des programmes qui se lancent au démarrage de la machine, avec un émulateur comme Bochs ou Qemu.
Il y a des explications ici : http://a.michelizza.free.fr/pmwiki.php?n=TutoOS.TutoOS.
Avec ce genre de programme tu pourras juste utiliser les interruptions du BIOS.
Ensuite tu peux t'exercer à passer en mode protégé et à accéder au hardware directement (mais tu peux le faire en 16 bits aussi).

C'est noté, donc suivant cette logique, plus on se rapproche du centre de la disquette, moins on peut stocker de donnée sur la piste ?

Il ne faut pas trop chercher à comprendre. À mon avis le matériel n'utilise plus vraiment un adressage comme ça, il doit y avoir une conversion qui est faite entre l'adressage "natif" et le "traditionnel".

Ce premier secteur de la première piste de la première face, est-ce que c'est le fameux MBR ? Et est-ce que GRUB (pour ne citer que lui) est justement à cette emplacement ? (GRUB est-il un bootloader ?)

C'est juste 512 octets qui sont exécutés si le BIOS les trouve. Le MBR d'un disque dur contient en plus une table des partitions.

Et dans le cas d'une clef USB, c'est encore différent : est-ce qu'il y a aussi un "premier secteur" dans lequel mettre notre bootloader ? (Le BIOS de l'ordinateur que je souhaite utiliser accepte de démarrer sur une clef USB).

Quand je démarre un OS sur une clé USB, je choisis dans le BIOS "USB-HDD". Je suppose qu'il se débrouille pour convertir les accès disque vers des accès sur la clé USB.
Si je bootais mon propre OS prévu pour un clé USB, j'essaierais "USB-FDD".
Pour écrire sur la clé USB je suppose (encore) que ça se fait de la même façon que pour une disquette, par exemple en écrivant 512 octets sur /dev/sdb avec dd ça devrait faire un secteur de boot.

Et quelle serait la manière "propre" de faire ? Est-ce qu'il faut "prévoir" tout ce dont on va avoir besoin de faire en Assembleur, et l'intégrer en premier, de façon à pouvoir développer le reste essentiellement en C ou C++ ? Ou bien est-ce qu'on est forcé d'utiliser de l'Assembleur inline ?

Je pense qu'il vaut mieux chipoter en assembleur d'abord, au départ ça paraît compliqué d'utiliser le C.
Après tu vas sans doute écrire en assembleur des fonctions bas niveau que tu appelleras en C.
L'ASM inline peut toujours être utilisé pour des petites choses, mais personnellement je l'évite parce que ça rend le code dépendant du compilateur (mais je n'ai jamais écrit de noyau).
Quand le code est un peu compliqué je préfère largement écrire une fonction entière en ASM.
Si ton projet avance tu n'auras sans doute quasiment pas d'assembleur, juste ce qu'il faut pour installer des interruptions, faire un changement de contexte en compagnie.


Il faut que j'y aille, c'est la fin du cours.

[Tomaka17]

Bonjour

Par contre, j'ai une interrogation, il est dit "Programmation Assembleur (Intel)" : ça veut donc dire que je ne peux pas appliquer ceci sur mon processeur ADM Athlon 64 3700 + ? Je suis obligé de coder sur un processeur Intel ?

Les premiers processeurs pour PC étaient fabriqués par Intel. AMD s'est ensuite incrusté dans le marché et a fabriqué des processeurs équivalents à ceux d'Intel mais pour moins cher.
Tout ça pour dire que les processeurs Intel et AMD sont quasiment identiques (à part peut-être à l'intérieur, mais ça je n'en sais rien ) et il n'y a aucun problème de compatibilité entre les deux.


Le problème avec le PC c'est que c'est une machine très complexe.
La plupart des autres ordinateurs sont beaucoup plus simples, sauf qu'on y trouve aussi beaucoup moins de documentation, de tutoriels, etc.

Si vous voulez simplement comprendre le fonctionnement interne d'un ordinateur, il vaut mieux peut être se tourner vers un tutoriel pas forcément destiné au PC (si ça existe :-/) au lieu de casser la tête à écrire un bootloader en assembleur, utiliser des fonctions du BIOS pour charger un fichier dont il faut également déterminer l'emplacement (d'où la connaissance de base de la structure d'une disquette), ensuite initialiser GDT, IDT, pagination, j'en passe et des meilleures.


A contrario, la Game Boy Advance par exemple est très facile à programmer.
On compile son programme qu'on charge ensuite dans un émulateur (un programme qui simule une GBA) comme si c'était le contenu d'une cartouche de jeu.
On peut alors directement y aller en C, afficher des graphismes à l'écran en deux lignes de code, etc. tout en restant assez proche du système
Seul inconvénient : comme dit plus haut, moins d'aide que pour PC


EDIT : sur la programmation GBA :
http://gfx.developpez.com/prog-gba/