Salut tout le monde :
Voilà tout est dit dans le titre de ce message
merci de votre réponse
Salut tout le monde :
Voilà tout est dit dans le titre de ce message
merci de votre réponse
Bonjour,
Contrairement à une idée répandue, le logiciel qui traite un langage donné n'a pas besoin d'être lui-même écrit dans un langage plus ancien ou de plus bas niveau. Par exemple, un compilateur C tel que GCC est lui-même écrit en C et peut être recompilé. Cela se fera donc d'abord avec les versions précédentes du compilateur, générant donc un nouveau compilateur dont la qualité du code est « l'ancienne » mais qui lui-même pourra produire du code optimisé. Ensuite, on peut recompiler une deuxième fois le même code avec le compilateur fraîchement produit pour que celui-ci bénéficie de la même qualité de code que ce qu'il va produire.
Plus généralement, un compilateur reste un logiciel ordinaire, et il sera donc écrit dans le langage le plus adapté « à la réalisation d'exécutables » sur la machine sur laquelle il doit fonctionner, donc il y a de fortes chances qu'il soit, aujourd'hui, écrit en C. Mais tu peux tout-à-fait l'écrire en assembleur, en C++, ou dans un langage de script (Perl, Python, Shell, PHP…), très adaptés à la rédaction de « moulinettes » si la grammaire du langage ciblé n'est pas trop sophistiquée (ce qui est tout-à-fait le cas avec l'assembleur).
Et sur ce point en particulier, les langages choisis aujourd'hui pour la rédaction de compilateurs vont être ceux qui vont proposer une manière propre de décrire une grammaire, donc Lex & Yacc par exemple (même si ceux-ci produisent en fait du C, commencent à être un peu vieux, et ne sont pas forcément faciles d'accès) et de faire facilement du traitement de chaîne de caractères, combiné à l'exploitation des structures de données usuelles (piles, file, tas, etc.).
Enfin, tout cela va être vrai pour les petits compilateurs mais dès lors que le langage va se sophistiquer et/ou être destiné aux gros projets (par exemple un compilateur C), un accent va être porté sur la rapidité de compilation et sur l'économie des ressources utilisées : un compilateur est typiquement quelque chose qui fait tourner intensivement un micro-processeur. In fine, sur la durée et sur les projets d'envergure, cela se traduit à la fois par une consommation élevée et par du temps-homme perdu.
Je trouve la question 'stupide' dans le sens ou si tu aurait cherché un peu le code source des assembleurs , tu aurait eu ta réponses
La plupart sont fait en C , mais rien ne l’empêche de le faire en php , java , C# , Basic etc...
D'abord, selon ce que je sais, le compilateur est un programme qui joue le rôle de l'inetrmidiare entre mon programme et l'ordinateur, il explique à la machine ce que je veux faire.
On est d'accord que l'ordinateur ne peut traiter que des signals électriques (low and high), ma question cherche à comprednre comment on est implanté ce programme (le compilateur, le traducteur (logique humaine -->logique machine)) pour la première fois dans la machine.
je parle spécifiquement de compilateurs des langages bas niveau.
je ne pense pas que c'est une question stupide
merci beaucoup pour vos réponses![]()
Un ordinateur ne comprend que les 0 et les 1. On lui envoie des commandes pouvant être suivi de paramètres (valeurs, adresses) tout ça dans un ordre bien précis. Électroniquement parlant on fait passer ou non du courant sur les broches du CPU (1 quarantaine de broches pour le 8086, beaucoup plus sur les derniers CPU). On lit ensuite les valeurs de certaines de ces broches en retour.
Tout cela étant très difficile et aucunement souple (voire impossible de nos jours), les scientifiques de l’époque ont inventé le langage assembleur, plus facile à lire et modifier. Ils ont crée ensuite un traducteur pour transformer se code en binaire (suite de 0 et 1 compréhensible par le CPU).
Cela étant encore compliqué, des langages de plus haut niveau ont été crée tels que le FORTRAN et le COBOL (les premiers langages ayant percés, dans les années 50, avant même le C). Il faut noter qu'à l'époque, il n'y avait pas encore de système d'exploitation.
Les langages haut niveaux ont permis également de porter du code d'une machine vers une autre, les assembleurs étant spécifiques à un processeur, il fallait tout reprogrammer si on changeait de machine. Les compilateurs demandaient par contre beaucoup de ressources pour le matériel de l'époque.
Le tout premier compilateur ayant existé a été écrit en assembleur. Les règles ont maintenant bien changé, il est maintenant tout à fait possible d’écrire un compilateur avec des langages de script tels que Perl, Python. En règle général, un compilateur de langage X est écrit en langage X. Cf réponse d'Obsidian.
Les compilateurs modernes sont capables de faire de la cross-compilation càd créer un exécutable pour une autre plateforme que celle servant à la compilation. Ils sont également capables de compiler ensemble un fichier source en C, un fichier source en autre langage vers un exécutable Il va aussi optimiser le code.
voir : https://fr.wikipedia.org/wiki/Compilateur
Donc il n' y a aucun méthode pour contacter le processeur directement ?
Comment font ils les informaticiens pour instaurer le premier programme dans l'ordinateur alors ?
Bon, quand nous achetons un nouvel ordinateur, nous installons le système d'exploitation à l'aide d'un CD, ce CD contient sûrement des instructions pour le microprocesseur, ces instructions sont des instructions machines ?
j'arrive pas à comprendre tout ça![]()
Je comprend pas ?
Tu parle sur un PC ? , ben un PC peut booter sur un Disque Dur , USB , lecteur disque ect , donc il peut lire un programme sur ces supports la.
Sur autre qu'un PC il existe dans le marché des programmateurs eprom/flash.
Ben que veut tu que cela soit d'autre que des instructions machines ?
C'est pas compliqué a comprendre pourtant un opcode = une instruction , si le support fournit ces opcodes(par courant electrique) je vois pas le probleme...
Si tu parle d'un point de vue historique , ben il existait le ruban/carte perforé mais t'imagine bien que cette méthode est assez obsolète de nos jours ( un programme digne de ce nom peut faire deja quelque mo) , je vois mal un particulier utilisait un tel engin qui lit l'octet a la seconde , et que par erreur il utilise scotch et autre accessoire pour réparer les erreurs...
je n'ai pas compris ta dernière question.
Moi je te parlais d'un CD , le CD marche avec une lecteur optique qui fourni un courant électrique derrière , courant électrique qui peut représentait tout ce que tu veux , du code machine , une image etc , tout dépend de ce qu'on lit sur le CD.
Mais la on s'éloigne de ton sujet initial (qui est comment est fait un programme assembleur) et que j'ai répondu en langage C principalement (mais que n'importe quel langage peut faire l'affaire).
L'assembleur n'est qu'une version lisible des opcodes , les supports de stockage (parce que c'est ce qu'il est question ici ?) , n'a plus grand chose a voir avec l'assembleur en assembleur c'est plutôt rare qu'on se souci du support de stockage , du moment que les données sont lu/écrit.
Le support est complètement arbitraire et son fonctionnement interne n'est pas important a savoir sauf si tu t’intéresse a l’ingénierie , le but est juste de fournir un courant électrique sur les broches du processeur pour la lecture/écriture des données.
Il faudrait que tu t'oriente vers de l’électronique non ?
Par exemple voila les broche de différent composant électronique :
http://fr.meric.free.fr/Articles/Cla...l_59b5acb0.jpg
Bonjour,
Quand tu achètes un ordinateur et que tu le démarres, ou lorsque tu appuies sur reset, qui donne l'ordre au micro-processeur et aux périphériques qui l'entourent de se remettre dans l'état initial, ledit micro-processeur est fait pour démarrer son exécution à une adresse fixe en mémoire, définie par le constructeur. Généralement, il s'agit même d'un vecteur, c'est-à-dire que l'adresse fixe en question est en fait celle d'un pointeur vers le bon emplacement, ce qui facilite les choses tant à la conception qu'à l'exploitation.
Ce tout premier programme doit donc être un code en langage machine situé en ROM, donc en mémoire non volatile et non inscriptible. Il se charge d'une part d'initialiser tous les composants de l'ordinateur s'ils ont besoin de l'être pour que ce dernier soit utilisable, puis met à disposition du programmeur un minimum de primitives d'exploitation, comme la lecture/écriture de secteurs sur disquette et/ou sur disque dur, ainsi que la rédaction d'un peu de texte à l'écran. Sur PC, ce mini-logiciel s'appelle le BIOS (« Basic Input/Output System ») mais il est nommé différemment sur les autres architectures. Sur les 8 bits, il portait souvent le nom de « moniteur ».
Après cette phase, on peut faire ce que l'on veut aussi : il est tout-à-fait possible de poursuivre avec des logiciels en ROM (cas des consoles de jeu à cartouche), on peut embrayer sur un système entier, ou alors, simplement utiliser ce système primitif pour charger en mémoire le premier secteur d'un disque et l'exécuter. Ce secteur contiendrait tout juste assez de code pour charger une suite d'autres secteurs consécutivement en mémoire et de là, lancer une amorce suffisamment longue pour charger ensuite un système d'exploitation entier. C'est ce que l'on appelle un boot, en référence probable au coup de botte que l'on donne sur le kick d'une moto pour lancer le moteur. Cette procédure était d'ailleurs appelée kickstart sur Atari ST.
Les IBM PC ont été d'emblée conçus sur ce modèle : tout en RAM à part le BIOS, mais il n'étaient pas d'emblée équipés de disque dur. Le boot se faisait sur disquette. Tant et si bien qu'un langage BASIC était parfois inclus sur les tout premiers modèles (XT), sur lequel on atterrissait si la procédure de démarrage échouait pour quelque raison que ce soit (par exemple, s'il n'y avait pas de disquette du tout). Ce détail a servi d'exemple à toutes la génération des ordinateurs 8 bits qui étaient systématiquement livré avec un BASIC en ROM ou à la limite en cartouche. Du coup, c'était ce BASIC qui servait — de fait — de système d'exploitation : non seulement il formait une très bonne interface utilisateur mais apportait également bon nombre de fonctions évoluées, bien plus que le simple BIOS ou le moniteur, si bien que la plupart des logiciels du commerce de cette époque étaient fait pour être lancés avec « RUN "programme" » même quand ils étaient écrits en langage machine.
Toujours est-il qu'à l'époque, sur PC, on lançait le DOS depuis une disquette à cette fin puis, de là, on changeait de disquette et on lançait le logiciel qui nous intéressait ensuite. Il existait des disquettes dites « bootables », c'est-à-dire des logiciels conçus pour être directement lancés depuis leur disquette au démarrage et pas appelés depuis le DOS. Ça permettait d'être totalement autonome et d'avoir la totalité de la mémoire à sa disposition, mais ça impliquait de réinventer la roue et tout réécrire depuis le départ (sauf les fonctions BIOS toujours en ROM).
Tu peux toujours, toi-aussi, concevoir une disquette bootable, ou à la limite un CD/DVD ou une clé USB à condition que ton PC ne soit ni trop ancien (incapacité de lire a priori le support concerné) ni trop récent (problèmes avec l'UEFI). Sur PC, le secteur de boot est le tout premier secteur d'une disquette ou d'un disque dur. Il est appelé MBR (Master Boot Record) sur les disques durs car ceux-ci peuvent être subdivisés en partitions et parce qu'il contient en plus la table des partitions primaires. Il te suffit d'écrire un petit programme en assembleur, compilant en 446 octets maximum, de le placer au début de ton secteur, et de placer les valeur 55h AAh dans les deux derniers octets de ton secteur. Il s'agit d'une signature indiquant qu'il y a quelque chose de valable dans ce secteur et que cela peut être exécuté sans risque.
Fais une recherche sur ce forum et dans le sous-forum « programmation d'OS » en particulier, car ce sujet a été de nombreuses fois débattu.
Bien sûr que si. Tu peux intégrer du code assembleur dans un source C, le compilateur transformant schématiquement d'abord ton code C en assembleur, puis ce code assembleur en code machine.Donc il n' y a aucun méthode pour contacter le processeur directement ?
C'est difficile de nos jours car on utilise un système d'exploitation, l'OS t’empêche de faire ce que tu veux. Tu ne pourras pas écrire directement sur un périphérique, tu seras obligé de passer par le système et les drivers de périphériques. Par ailleurs, pour commander un périphérique directement en assembleur, par exemple sans OS, tu dois connaitre et savoir utiliser ses spécifications techniques, quand elles sont publiques, sinon tu peux passer que par le driver.
Quand à l'amorce du système, sur PC, le BIOS charge le 1er secteur du disque à l'adresse 0xc7c00 et saute à cette adresse. Avec les machines en UEFI (l'UEFI remplaçant maintenant le BIOS), celui-ci va chercher à charger un fichier .efi dans le dossier EFI de la partition système EFI du disque dur (nommée ESP). L'installation du code amorce ou du fichier EFI est à la charge du système lors de son installation.
le BIOS ou l'UEFI sont eux-même des programmes en ROM.
Au tout démarrage du CPU, celui-ci va exécuter le code présent dans le cas du x86 à l'adresse 0xffff:fffe (si ma mémoire ne me fait pas défaut), l’électronique devant faire en sorte que le code de démarrage du BIOS ou de l'UEFI soit câblé à cette adresse. Pour les autres CPU, le principe est le même exemple pour le Motorola 68000 qui a équipé les premiers Macintosh, les Atari ST, Amiga, imprimantes Laserjet, le CPU démarrait à l'adresse $00000004.
Merci infiniment pour le temps que vous avez accordé à mon sujet
Je vais essayer de bien lire ce que vous m'avez conseillé
mon but final est de manipuler mon ordinateur sans aucun moyen intermidiare, selon vos réponses, j'ai bien saisi que c'est un sacré boulot.
En tout cas, je vais essayer![]()
Et c'est une très bonne chose. Tout programmeur devrait s'attacher au moins une fois à cette tâche. Évidemment, c'était plus facile avec les anciennes machines…
Pas forcément. Ça dépend surtout de ce que tu veux faire. Si tu veux réécrire ton propre OS from scratch jusqu'à obtenir quelque chose que tu vas utiliser au quotidien, alors oui, tu en as pour une vie entière. Si par contre, tu veux simplement faire des preuves de concept pour manipuler individuellement tel ou tel composant, et éventuellement écrire un pilote minimaliste pour un des périphériques de ta machine, alors tu peux le faire en quelques mois.selon vos réponses, j'ai bien saisi que c'est un sacré boulot.
En tout cas, je vais essayer![]()
Le sous-forum « assembleur → programmation d'OS » est fait pour cela.
PDP8-E, que du bonheur !
Un ensemble de clés en face avant, tu les positionnais en fonction de ce que tu voulais faire, des switches "Load Address", "Deposit", "Examine", "Run" et en avant ! Avec les schémas du cpu et un oscilloscope (même pas numérique à l'époque), tu pouvais voir certains morceaux d'instructions s'exécuter, genre la sonde sur le bit de retenue en bout du registre, tu voyais basculer le flip-flop si l'addition dépassait la capacité du registre, trop bien !
Maintenant tu ne vois plus rien, tu ne sais pas ce qui se passe, je comprends les interrogations de l'OP, trop rares de nos jours, hélas...
Pour ma part sans aller au PDP-8 , je pense qu'une machine 8 bits reste tout a fait abordable dans sa compréhension.
Comme je le répète souvent ici , si on commence deja par vouloir comprendre comment fonctionne un PC c'est certain que c'est plus compliqué que si on veut comprendre comment fonctionne un commodore64 ou un amstrad CPC par exemple.
En fait Jamal comme on te l'a dit plus haut l'ordinateur ne comprend que des 1 et 0 et en fait ces 1 et 0 ce sont des signaux sous forme de pulsions électriques de différentes puissances dont généralement géré par les milliards de transistors installés dans les différents composants de ton ordinateur. Ces transistors gérent le courant electrique qui se trouvent dans ton pc et ce courant electrique est produit par la batterie de ton pc ou bien quand tu le branches sur une prise.
mais ceci ne relève plus du domaine informatique mais de la physique.
je te conseillerai premièrement si tu veux en savoir plus de lire un cours sur les origines de l'informatique et les premières machines qui ont été inventées puis de lire un cours sur les transistors et leur fonctionnement.
mais là je ne peux te promettre qu'après tu utiliseras ton pc sans intermédiaire à moins que tu ne te mettes à marcher avec des ampermètre et voltmètre et tout genre de materiel qui sert pour manipuler le courant electrique.
Pas tout-à-fait, puisqu'en l'occurrence, les transistors et la physique qui leur est associée n'est utilisée que pour véhiculer de l'information, laquelle est elle-même basée sur le paradigme du binaire tout-ou-rien et de la logique du premier ordre. Mais dans l'absolu, il est tout-à-fait possible de remplacer tout ce qui est électrique ou électronique par des cellules entièrement pneumatiques ou hydrauliques. Ce serait juste beaucoup plus gros et beaucoup plus lent, mais les concepts sous-jacents à la mise en place d'un processeur demeureraient.
Et là encore, ce que tu dis est vrai si tu t'appuies, comme tu le fais, sur sa volonté d'utiliser sa machine « sans intermédiaire ». Par contre, la question initiale était de savoir en quel langage sont écrits les compilateurs de langages. Et on pointait du doigt le fait que ces compilateurs peuvent tout-à-fait se compiler eux-mêmes.
effectivement je confirme que les compilateurs peuvent etre écrit en differents langages.
pour leur écriture je proposerai déja meme la forme de Backus Naur (en abrégé B.N.F) qui est très utilile pour la description syntaxique des instructions de langages de programmation et dans leur transcription par le compilateur.
Je ne pense pas que le posteur original veut faire un programme assembleur.
Mais si je devais conseillé un c'est de reprendre un open source (j'ai une préférence pour VASM personnellement qui est facile a modifier pour ajouter un assembleur ).
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.
Partager