Bonjour,
est il possible de programmer un OS uniquement en c et uniquement avec ses bibliothèques standards ? Autre petite questions, existe t il dans ses bibliothèques standards une "commande" pour contrôler un pixel précisément ?
Version imprimable
Bonjour,
est il possible de programmer un OS uniquement en c et uniquement avec ses bibliothèques standards ? Autre petite questions, existe t il dans ses bibliothèques standards une "commande" pour contrôler un pixel précisément ?
Non, il te faudra un minimum d'assembleur, ne serais ce qu'en inline.
Dans le cas de Linux, pas de fonction dans le noyau, tu as des fonctions dans les couches graphiques telles que X11. (pour ne citer que lui).Citation:
existe t il dans ses bibliothèques standards une "commande" pour contrôler un pixel précisément ?
Sur Windows, tu pourras avec la couche DirectX.
Je me permets de modérer ce propos car il est possible d'utiliser le framebuffer directement indépendamment d'un serveur X. La meilleure source de documentation pour ce faire étant je pense les sources d'un programme qui exploite cela (mplayer peut-être ?).
Certe, je n'ai pas parlé du Framebuffer, mais celui-ci permet d'accéder si je ne me trompe à la RAM video depuis l'espace d'adressage. (et aussi de bénéficier d'accélération matérielle).
Il y a une bibliothèque directFB qui contient peut-être des fonctions de modification de pixels, mais c'est une bibliothèque, ce n'est donc pas intégré "bibliothèque standard".
La question étant :
La libc également appelée bibliothèque standard C ne contient pas de fonctions dédiées à la manipulation de pixels. Il faut compter sur des bibliothèques additionnellesCitation:
existe t il dans ses bibliothèques standards une "commande" pour contrôler un pixel précisément ?
Merci pour vos réponses rapides, avez-vous un livre à me conseiller pour apprendre le langage assembleur d'un maximum de processeurs ? Windows par exemple fonctionne sur pas mal de processeur, il contient des codes sources différents pour chaque processeur ou son code source est unique pour tous les processeurs et s'adapte à eux ?
Windows ne fonctionne que sur x86 et ARM pour les versions Windows RT. Mais je pense pas que se soit le même code, les applis win32 ne fonctionnant pas avec Windows RT. Les applis Modern UI utilisant une API différente, présntes dans les deux versions.Citation:
Windows par exemple fonctionne sur pas mal de processeur
Si tu prends le cas de Linux qui lui gère beaucoup plus de processeurs différents, l'essentiel du code est commun, et des parties spécifiques aux CPU sont présentes. Exemple, Linux gère la pagination à trois niveaux que ne gèrent pas les CPU Intel (seulement 2 niveaux) mais que gèrent les CPU Alpha. Le code est conçu pour sauter le troisième niveau pour les CPU Intel.
Ensuite le code d'amorce est différent.
Les appels systèmes sont les même, mais la convention d'appel est adaptée au CPU, et bien que tu trouve les mêmes softs sur le différents noyaux, les versions sont adaptés au CPU, les applis sont compilés vers le CPU de destination.
Ceci n'est qu'un exemple. Je ne suis pas spécialiste du sujet non plus.
Si le sujet t’intéresses, tu peux regarder ceci :Citation:
Merci pour vos réponses rapides, avez-vous un livre à me conseiller pour apprendre le langage assembleur d'un maximum de processeurs ?
http://chrtophe.developpez.com/tutoriels/minisysteme/
http://systeme.developpez.com/tutori...eloppement-OS/
Pour l'assembleur proprement dit :
http://asm.developpez.com/cours/
http://asm.developpez.com/livres/
Commences déjà par un CPU, se sera déjà pas mal.
Bonjour,
Apprendre l'assembleur n'est plus vraiment obligatoire sauf dans des cas précis. Suivant ce que vous voulez faire, vous devriez peut être vous intéresser à d'autres langages.
Pour l'histoire de jouer avec les pixels, ce que je fais c'est faire un rendu, dans une mémoire qui est gérée par moi même à la même. Une sorte de simulation de l'écran. Ainsi, je peux faire ma taille d'écran que je veux, je peux écrire/lire les pixels comme je le souhaite et le tour est joué.
Si je veux voir le résultat, je sauvegarde en BMP ou un autre format simple et je l'ouvre avec un visualiseur approprié.
En fait ce que je veux faire c'est pouvoir contrôler mon pc intégralement, et ne plus dépendre d'un quelconque logiciel, peut être même par cette volonté créer mon propre langage. Lâché dans ce monde sans logiciel, lire une clé USb ou une souris sera t il possible ?
Oui, c'est possible, tout est possible, mais cela vous prendre du temps, beaucoup de temps.
Je pense qu'au lieu de partir dans une telle direction, il faut mieux regarder les logiciels libres, tel le noyau Linux et les logiciels gravitant autour.
Bonjour,
Nous proposons ici le forum assembleur et son sous-forum programmation d'OS pour les questions relatives à ce sujet. Il est toujours très enrichissant de se prêter à ce genre d'exercice mais sache que c'est extrêmement long, beaucoup plus qu'on l'estime au départ.
Oui, mais il te faudra par définition tout réécrire depuis zéro (sauf à utiliser les fonctions BIOS, EFI, ou ACPI quand elles sont disponibles) et ré-implémenter toute la pile des pilotes des différentes couches avant d'arriver à lire ta souris ou ta clé USB. Cela va essentiellement dépendre de la machine que tu utilises, mais on considère quand même que c'est un PC.Citation:
Lâché dans ce monde sans logiciel, lire une clé USb ou une souris sera t il possible ?
Un bon compromis consiste à se donner un objectif précis, par exemple « lire la clé USB » et implémenter depuis la base tout ce qui est nécessaire pour y parvenir mais rien d'autre : uniquement la lignée nécessaire à cette tâche en particulier (en s'accordant quand même le droit de mettre en place quelques facilités, comme une console digne de ce nom). Ça implique quand même un bootloader, un système de passage en mode protégé, une initialisation des segments, une prise en charge des principales interruptions, une gestion du clavier (via l'historique 8042, pas directement par l'USB), une initialisation éventuelle des modes vidéo jusqu'à VGA ou SVGA (sauf à rester en mode texte), puis de là, une énumération des bus PCI, l'identification et le mappage en mémoire de l'hôte HCI, une prise en charge partielle du complexe protocole USB en lui-même, une énumération des périphériques USB, l'identification d'un périphérique type « mass storage » et la prise en charge du protocole associé pour pouvoir, enfin, lire un secteur sur ta clé.
Il est tout-à-fait possible d'écrire tout cela en C. Enfin, plus précisément, il est possible d'écrire 99,9 % de tout cela en C. Tu ne pourras jamais échapper à un minimum d'assembleur pour initialiser le mode protégé ou pour lire les ports I/O initiaux. Et c'est très bien comme cela : l'assembleur a été passionnant et nombreuses étaient, dans les années 1980 et début des 90's, les applications 100 % assembleur. Ensuite, les micro-processeurs sont devenus trop sophistiqués pour gérer humainement du code assembleur efficace et les compilateurs C, eux, sont devenus parallèlement très performants à cette tâche.
Tu ne pourras pas non plus t'appuyer directement sur la bibliothèque standard, d'abord parce que celle-ci n'est pas directement engendrée par le compilateur C, mais est mise à disposition du programmeur avec le compilateur, parce que la norme l'exige. Ensuite, parce que cette bibliothèque est faite, par définition, pour s'appuyer sur le système d'exploitation. À dire vrai, c'est là la définition même d'un système d'exploitation : mettre en place les infrastructures minimum requises permettant d'écrire et d'exécuter un programme dans des conditions standardisées.
Par contre, le C est fait pour pouvoir générer du code machine même en l'absence de toute infrastructure préalable (puisqu'il est, entre autres, censé être justement une alternative à l'assembleur). Il te faudra donc réécrire également les fonctions les plus importantes de la bibliothèque standard, par exemple un printf minimaliste.
Enfin, pour répondre à ta question, contrairement au Basic ou à d'autres langages, il n'existe pas en C de commande « standard » pour allumer ou éteindre un pixel donné à l'écran, pour la simple raison que cela dépend totalement de la machine : rien ne dit que ta machine soit dotée d'un écran, rien n'indique que celui-ci soit capable de fonctionner en mode graphique, ni même que tu aies le droit d'y écrire. C'est vrai spécialement dans l'embarqué où tes programmes sont destinés à fonctionner sur micro-contrôleur, dans une machine a priori totalement dépourvue d'interface homme-machine, hormis une connexion série ou réseau.
Par ailleurs, si tu refais ton OS, ce serait à toi de réécrire cette fonction si elle existait. Ce qui nous amène à la partie la plus intéressante : l'architecture des ordinateurs (en général). Pour allumer ou éteindre un pixel, il faut écrire dans la mémoire vidéo. Il s'agit en fait de RAM plus ou moins ordinaire mais qui a la particularité d'être lue automatiquement par la carte vidéo qui, elle, module la tension de sa sortie en fonction de ce qu'elle y trouve. Déposer un octet en mémoire à cet endroit provoque donc automatiquement la modification de l'aspect du ou des pixels correspondants.
Merci beaucoup pour cette riche réponse, où trouver les commandes utilisées notamment pour programmer le printf du langage c ?
Tout d'abordCar avant de refaire printf, il faut savoir comment ça marche, et rien que printf avec les options c'est dense.Code:man printf
Tu peux aussi consulter le code source (mais pas sûr que tu y comprennes grand-chose)
Simplifions : on va dire que tu veux afficher une séries de caractères depuis une chaine.
C'est pas si simple que ça, printf va en fait écrire dans un fichier stdin, donc on rajoute une couche gestion de fichiers. Le noyau va afficher le contenu de stdin à l'écran. Tout cela est un long cheminement qui peut faire un livre (voir plusieurs), car en mode graphique par exemple, tu dois dessiner caractère par caractère (ce que fait l'OS) , selon la police de caractères utilisée.
Pour en revenir à la question originelle, pour modifier un pixel à l'écran, on utilise une fonction d'une bibliothèque. Sans système, cela consiste à modifier 3 à 4 octets en mémoire. Encore faut-il savoir y accéder, car il faut initialiser le mode vidéo dans la résolution souhaitée, puis calculer la position des octets correspondant au pixel à modifier (3 octets pour les valeurs RVB et éventuellement un octet pour le canal alpha par exemple).
Puis-je vous demander une dernière chose, comment appelle t on le rassemblement de processeur ayant le même langage assembleur ?
Je pense que l'on parlera d'architecture (x86,x64, ARM)...
Attention, toutes les fonctions de la bibliothèque standard ne n'appuient pas sur le noyau: celui-ci est évidemment nécessaire pour l'accès aux fichiers et l'allocation mémoire, mais les fonctions de manipulation de chaînes, de mathématiques ou de tri sont indépendantes (à supposer qu'elles n'aient pas besoin d'allocation mémoire).
Je trouve le projet un peu trop ambitieux pour quelqu'un qui ne sait pas grand chose ^^'
Pour connaître l'assembleur en général si tu en connais un , il est facile d'en connaître un autre , mais c'est pareil pour les autres langages de programmation.
La question suppose que tout les printf sont codé de la même manière , mais en faite cela dépend énormément de la machine (quand la dite machine possède un écran evidamment).Citation:
Merci beaucoup pour cette riche réponse, où trouver les commandes utilisées notamment pour programmer le printf du langage c ?
Par exemple sur les vielles consoles ,ils ne possèdent pas de mode console(ou mode texte comme tu veux) , il est obligatoire d'envoyer en VRAM un bitmap font pour afficher du texte.
Pour une image je comprend pour le RVBA , mais pour un framebuffer un RVBA c'est pas un peu étrange ?Citation:
(3 octets pour les valeurs RVB et éventuellement un octet pour le canal alpha par exemple)
Je dis ça mais je n'en sais rien si de nos jours on va sur du Framebuffer en RVBA rien ne m’étonne maintenant :P
C'est surtout utile à l'alignement 32 bits.Citation:
Pour une image je comprend pour le RVBA , mais pour un framebuffer un RVBA c'est pas un peu étrange ?
exemple mode VESA 32 bits 1024x768 : 0x138
Bonjour,
Désolé de ressortir un sujet de 1 mois, bien que je n'ai pas la prétention d'écrire un OS, je me demande bien pourquoi on ne peut pas échapper à de l'assembleur pour certaine chose ?
Moi qui travaille sur microcontroleur, le C permet de faire vraiment tout. Il suffit simplement de connaître l'adresse des registres et avec un pointeur c'est réglé.
Pourquoi c'est différent sur un PC ? Je pense au mode protégé par exemple car si j'ai compris, c'est un bit à passer à 1 dans un registre et si l'adresse du registre est connu alors on peut le faire en C ? Non ?
D'avance merci.
C'est un peu plus compliqué que ça.Citation:
Pourquoi c'est différent sur un PC ? Je pense au mode protégé par exemple car si j'ai compris, c'est un bit à passer à 1 dans un registre et si l'adresse du registre est connu alors on peut le faire en C ? Non ?
Pour activer le mode protégé, il faut activer le bit de poids faible du registre cr0 à 1 après avoir généré la GDT.
en asm x86 notation Intel :
Je ne sais pas si l'assembleur inline des compilateurs donnent l'accès aux registres de commande cr0 à cr3 (ou jusqu'à cr4 je sais plus)Code:
1
2
3
4 mov eax,cr0 or al,1 mov cr0,eax
Par ailleurs, ce simple code ne suffira pas, il faudra créer la GDT, puis l'activer via l'opcode lgdt, qui n'est peut-être pas non plus géré par le code inline des compilateurs.
Dans le cas de Linux, par exemple, tu as un code amorce en assembleur.
Un, microcontrôleur, c'est plus simple à programmer qu'un PC par exemple. Un micro-contrôleur est plus simpliste, tu ne gères pas de segmentation ou pagination, ni x cartes graphiques de x constructeurs. L'utilisation d'un afficheur 7 segments par exemple est beaucoup plus simple que d'afficher du texte avec une police bine précise. Et encore une fois, le C ne fait pas tout, ce sont les biothèques annexes qui permettent d’arriver à quelque chose. Tu dois utiliser probablement ulibc qui est une micro libc adaptée aux micro-controleurs.
Le problème, c'est que les registres du microprocesseur n'ont pas d'adresse mémoire, il n'y a aucun moyen d'y accéder explicitement en C standard.
Et sur x86, les registres de contrôle des périphériques n'ont pas d'adresse mémoire non plus: Ils ont leur propre espace d'adressage, et il n'y a pas de moyen en C standard pour y accéder.
Et les moyens non-standard doivent eux-mêmes être programmés en assembleur (ou du moins, dans un autre langage que le C).
À mentionner également, la gestion d'interruptions, où l'on ne peut pas se contenter de mettre un pointeur de fonction normal parce que le retour d'interruption se fait par une instruction différente du retour de fonction, l'accès au contexte pour du multithreading, la gestion de la MMU quand elle fait partie du proc (car elle est alors contrôlée directement par des registres du proc, donc sans adresse) etc.
En fait, le seul moyen de faire un OS entièrement en C est de disposer d'extensions au langage (une plate-forme non-standard, donc), extensions qui pourraient être matérielles (il est théoriquement possible de créer un processeur qui expose ses registres en tant qu'adresses mémoire, et qui exécute des instructions spéciales quand on écrit à certaines adresses).
Je comprends mieux et ce n'est pas si différent des micro-contrôleurs finalement
Le langage C ne permet pas, non plus, d'accéder aux registres de travail du CPU, qui se trouve dans le micro-contrôleur.
Merci pour cet éclairage.
Il parlait des registres en mémoire c'est assez courant sur micro-contrôleur (mais pas qu'eux) d'avoir toutes les entrée/sortis sur une adresse mémoire.
@Vincent PETIT
Difficile de comparer aussi les micro-controleur moderne , les instructions sont sur 1 cycle et ils ont entre 16 et 32 registres ,ils sont donc fait spécialement pour être coder en C du coup toute l'architecture derrière est penser ainsi.
Loin est l'époque ou certain instruction (pour gérer les différentes interruption IRQ par exemple) , ce faisait obligatoirement en assembleur ;)
De plus un compilo fera sûrement mieux (par contre pour du z80 ou du 6502 il n'y a pas de compilateur digne de ce nom).
Sur X86 il y'a pas mal instruction spécifique je suppose que le compilateur n'utilisera pas.