Posez votre question Signaler

Compilé ou interprété

jemd - Dernière réponse le 17 juin 2011 à 12:49
Bonjour,
Dans mon apprentissage des langages de programmation, j' ai du mal à saisir la différence entre langage interprété et langage compilé. Même si j'en ai lu les diffférentes définitions.
L'un interprète au fur et à mesure et l'autre non !
Mais savoir ca ne me renseigne pas vraiment sur les avantages de l'un par rapport à l'autre ! (l'un est plus rapide : le compilé, bon d'accord mais après...)
Pourquoi choisir l'un plutôt que l'autre etc.
ben voilà mon trouble actuel.
Si quelqu'un peut m'éclaircir sur ce sujet, il en sera d'avance remercié.
Lire la suite 
Réponse
+9
moins plus
ah d'accord !!
si j'ai bien compris ...
dans le cas ou on crée un programme dans un langage qui doit être compilé pour que le processeur le traduise...On doit avoir obligatoirement un compilateur, non ?!

La seule exception : les tous premiers ordinateurs que l'on programmait LANGUAGE MACHINE (code binaire).
Dès que l'assembleur est apparut, on à utilisé un language qui n'était plus directement le language machine. Mais ce language de "deuxième génération" est plus simple que les languages plus haut niveau (troisième génération), qu'ils soient interprétés ou compilés, car à chaque instruction "assembleur" correspond une inscruction "language machine". C'est juste une réécriture très direct dans un format plus "humain", plus simple à écrire (avec des identificateurs : noms de variables ou de fonction, aux lieu des ardesses mémoires, des nombres).
Par contre, avec les L3G (languages troisième génération), une instruction du programme correspond souvent à de multiples instructions assembleurs (je te l'avait démontré précédemment).


Et donc une fois le programme compilé il n'est plus nécessaire de faire appel sur n'importe quelle machine à un compilateur pour ouvrir le même programme. C'est ca ?!

Tout à fais. J'irais même plus loin. Interresse toi un moment au démarrage de l'ordinateur. La tension viens d'être mise, la mémoire est vierge, sauf la mémoire morte (ROM) qui contient, à une adresse stratégique fixée à laquelle le processeur va chercher ses toutes première instructions, le programme d'initialisation, qui "réveille" les périfériques (clavier, carte vidéo, port USB, disque dur, etc...), puis charge le système d'exploitation, auquel il donne la main.
Ce programme ne peux même pas être écrit avec un compilateur classique, puisque ces derniers sont conçu pour coopéré avec un système d'exploitation, hors dans le cas du démarage, il n'y a aucun S.E., chargé, disponible.
C'est un des avantages de la compilation : on devient autonome.
Un bémol quand même : souvent on fait appel à des "bibliothèque partagé", c'est à dire des bout de programme très commun, regroupé une fois pour toute dans un fichier unique, ce sont les fameuses DLL.
Et en cas d'abscence de la DLL requise, celà pose évidemment problème.

De l'autre coté, un avantage (tordu) des languages interprété : la modification/génération "en-ligne" des programmes : on peut se permettre d'écrire un programme qui écrit des bouts de programme et les éxécute.

Autre avantage, plus concret, au "débuggage" : lorsqu'une erreur se produit, un interpréteur (language interprété, donc) peut dire exactement à quelle ligne le programme s'est craché, et ce DE MANIERE NATIVE.
C'est possible de le faire avec les languages compilé, mais celà necessite un débugger, et son utilisation reste plus lourde, plus difficile à prendre en main.


Par contre dans un langage interprété, il est toujours nécessaire d'avoir sur la machine utilisée pour ouvrir le programme un interpréteur !? C'est ca ?

Tout à fait.


Mais alors les langages interprétés ne créent pas de ".EXE" !!

Question piège. En fait, la plupart des language interprété PEUVENT être compilé. Il n'y a pas de "language interprété" au sens de "language qui ne peux pas être compilé" et vice versa. L'adjectif désigne en fait l'usage qui est fait, le plus couramment, pour éxécuter le language.
L'exemple de BASIC : GW-BASIC et QBasic était des language interprétés. Les interpréteurs étaient faciles à obtenir (souvent livré avec les systèmes d'exploitation, Néanmoins ils disposaient aussi de compilateur (mais celà devait être des outils professionels, je n'en ai jamais eu sous la main).

Pour conclure, on peut dire qu'il n'y a pas, fondamentalement, de différence, ce qui change c'est l'ordre des opérations qui servent à éxécuter le programme.
Dans le cas de la compilation, on effectue une lecture et une traduction complète du programme, en une fois, vers le language binaire. Effectivement, passé cette phase, le compilateur n'est plus utile.
Dans le cas de l'interpréteur, on effectue la lecture d'une instruction, que l'on traduit jusqu'au language machine, puis éxécute. Puis on recommence avec la ligne suivante.

Si on voulais faire une analogie, le microprocesseur est un interpréteur matériel. (A chaque étape, il charge un code binaire qui a une signification, et effectue les opération correspondante, puis recommence avec l'instruction suivante, ainsi de suite, etc...)

Pour Java, c'est encore un cas bâtard. Pour comprendre clairement les chose, il faut séparer Java et le ByteCode. Le ByteCode est un genre d'assembleur, pour un processeur qui n'existe pas. La machine virtuelle est donc un "émulateur de microprocecesseur fictif". Le ByteCode est un language interprété par la machine virtuelle, de la même manière que l'assembleur est interprété par un processeur. (Il me semble d'ailleurs que depuis, on été crée des "puces Java", càd capable d'interpréter du ByteCode).
Par contre, Java, en soit, est un language compilé, puisque traduit en ByteCode.

Pour conclure vraiment cette fois,
La Compil' est une TRADUCTION
L'interprétation une EXECUTION.
jemd- 16 avril 2005 à 10:21
tout d'abord merci beaucoup SKZ81 pour toutes tes explications qui commencent à éclairer un peu plus ma gouverne !

Mais en informatique les réponses entrainent souvent de nouvelles questions, j'espère que cela s'arrêtera un jour sinon je suis parti au moins jusqu'après la retraite pour tenter de répondre à toutes !

Faut dire que ta conclusion m'a perturbé, car j'aurais dit le contraire peut-être mon coté littéraire...mais bon je te fais confiance sans problème.

Donc je résume, le compilateur comme l'interpréteur passe par l'os qui redirige le programme tout neuf et traduit en binaire vers le processeur qui peut alors l'exécuter. Cela lors de la création d'un programme.
Lors de l'utilisation du programme sur une autre machine le programme compilé passe par l'os qui le dirige vers le processeur qui l'exécute.
Pour le programme interprété, c'est le même parcours à la différence près qu'un interpréteur est placé entre le programme et l'os ( ou entre l'os et le processeur ??).

Un programme interprété peut -être compilé ! C'est donc un abus de langage de dire qu'il ya des" langages interprétés" ou alors c'est que les langages compilés eux ne peuvent pas être interprétés !!??


Enfin deux questions pour finir

La première concerne la portabilité des langages, celle-ci dépend-elle des os ou des processeurs ou bien encore des deux si l'on estime qu'un système d'exploitation est lié à un processeur ?

la deuxième concerne ces fameuses dll, je me suis toujours demandé ce qu'elles pouvaient contenir comme informations communes à plusieurs programmescar j'ai du mal à saisir encore les similitudes que peuvent contenir des programmes différents ??

ouf fatigué je suis moi ...
Répondre
Ajouter un commentaire
Réponse
+3
moins plus

Mais en informatique les réponses entrainent souvent de nouvelles questions, j'espère que cela s'arrêtera un jour sinon je suis parti au moins jusqu'après la retraite pour tenter de répondre à toutes !

Y'a des chances, pourtant... Mais t'inquiète, dans l'intervale tu apprendra de plus en plus de chose, donc tu SAURA FAIRE de plus en plus de choses. Mais c'est un apprentissage laborieux.

Faut dire que ta conclusion m'a perturbé, car j'aurais dit le contraire peut-être mon coté littéraire...mais bon je te fais confiance sans problème.

TRADUCTION / EXECUTION ?
Je t'avoue que dans l'interprétation peut aussi inclure une phase de traduction. Mais elle se fait au niveau élémentaire des instructions.
Si on regarde au niveau global, celui du programme, et qu'on se pose la question : dans quel but principal je passe tel programme dans un programme nommé "interpréteur" ou "compilateur", on tombe sur cette conclusion.
Càd : j'ai une entrée (un programme en "code source"). Si je le passe dans un compilateur, le résultat produit est un nouveau fichier, un programme traduit.
Si je le passe dans un interpréteur, le résultat est l'éxécution du programme. On peux toujours voir un interpréteur comme un processeur, qu'il soit matériel ou logiciel, et même s'il effectue une étape de traduction, lui aussi. Il ne met pas (en théorie) à disposition de l'utilisateur une traduction du language source.


Donc je résume, le compilateur comme l'interpréteur passe par l'os qui redirige le programme tout neuf et traduit en binaire vers le processeur qui peut alors l'exécuter.

A peu de chose près : une précision tout de même.
Le fait que le code binaire "passe par l'os" signifie qu'il fait appel à lui, ce qui n'est pas systématique. Par exemple pour faire un calcul il exploite directement et uniquement le microprocesseur. Mais pour accèder au matériel, réserver de la mémoire, etc... il délègue au système d'exploitation.
Deux avantage : on peux bétonner la sécurité, et les programmes créé ne sont pas obligés de connaitre le matériel sur lequel il tourne, puisque l'OS fait l'interface...
Le compilateur "passe par l'OS" si on veux pour faire son travail, mais celà n'a rien à voir avec les actions effectuées par le programme compilé.
Le compilateur transforme des instructions du progtamme compilé en appel aux fonction de l'OS. Le programme compilé, de façon autonome, lors de son éxécution, fera appel, tout seul comme un grand, aux fonctions de l'OS.
Dans le cas d'un interpréteur, il lit l'instruction suivante du programme interprété, et si besoin est, l'interpréteur fait appel à une fonction de l'OS.

NB : l'os n'est pas un "passage obligé". C'est plutôt un endrois où on "va faire des détours", aux moments où c'est necessaire.


Lors de l'utilisation du programme sur une autre machine le programme compilé passe par l'os qui le dirige vers le processeur qui l'exécute.

Cf au dessus : on dira plutôt "Lors de l'utilisation du programme sur une autre machine, le processeur exécute le programme compilé qui passe par l'os [pour effectuer certaines tâches spécifiques]"

Pour le programme interprété, c'est le même parcours à la différence près qu'un interpréteur est placé entre le programme et l'os ( ou entre l'os et le processeur ??).

Entre le programme et l'os.


Un programme interprété peut -être compilé ! C'est donc un abus de langage de dire qu'il ya des" langages interprétés" ou alors c'est que les langages compilés eux ne peuvent pas être interprétés !!??

Oui c'est un abus de language. Sauf qu'il y a souvent une "majorité" qui l'emporte, j'ai jamais entendu parler qui faisait du C interprété en pratique. Ca reste possible, mais c'est stupide.
C'est plutôt l'inverse : certain language interprété ne peuvent pas être compilé, l'inverse est faux.
Et il s'agit d'une minorité : ceux qui dispose de l'instruction "éxécute".
Cette instruction spéciale demande à l'interpréteur d'éxécuter une nouvelle ligne de code, qui à très bien pu être construite en fonction des évènements qui se sont produits durant l'éxécution.
Avec un interpréteur, celà ne pose aucun soucis. Avec un programme compilé, c'est beaucoup plus difficile à mettre en oeuvre, et celà demande d'embarquer soit un compilateur, soit un interpréteur. Bref, on perd un des avantages principaux.
Mais bon, c'est l'éxception tordue.


Enfin deux questions pour finir

La première concerne la portabilité des langages, celle-ci dépend-elle des os ou des processeurs ou bien encore des deux si l'on estime qu'un système d'exploitation est lié à un processeur ?

Mal dit : en règle générale, un language est toujours portable. C'est une question qui se pose individuellement pour chaque programme.
Ceci dis, certain language sont conçu pour faire en sorte que les programme écrit dans se language soit intrisèquement portable : le principe est celui de l'abstraction.
L'idée est de camoufler au maximum les spécificités du "système cible" (celui sur lequel s'éxécute le programme derrière une "interface de programmation". Si cette interface est disponible à l'indentique sur tous les systèmes possible, les programmes écrit dans ce language serait universellement portable.
Cette interface est constituée par une bibliothèque standard, dans le cas des languages compilés, qui transforme les intructions du language en appel a l'os (le rôle du compilo est de transformer les instructions, soit en intstruction destinés au microprocesseur, soit en appel aux routine, fonctions, sous-programmes (3 synonymes) de la bibliothèque standard) ;
dans le cas des languages interprétés, l'interface de programmation est l'ensemble des intruction, mots-clef, etc... que l'interpréteur est capable de comprende.
Du point de vue du programmeur, la différence est très très mince.

Malheureusement, certaine boîte, microsoft en tête incluent des spécificités dans les languages, bibliothèques, etc... qu'ils développent, de telle manière qu'il soit impossible ou presque de se passer du combiné Windows / ses bibliothèques / ses languages. (Sachant que la dépendance par des languages et va vers windows, bref...)

Certaines interfaces de prog, comme POSIX en C/C++ permettent de créer des programmes portables indépendamment du système d'exploitation.
Inversement, toujours en C/C++, les Microsoft Fondation Classes (MFC) ne permettent de créer QUE des application Windows (à une époque, il existait un port des MFC pour Mac, puisque Office pour Mac était dispo. Maintenant je ne sais pas : 1) si M$ l'a rendu public 2) si ça marche toujours).

Ce n'est pas tout à fait un problème d'OS (en général il propose toujours plus ou moins des fonctionnalités équivalentes).
Par contre ça peux devenir un problème de matériel.

Tu évoquais les µ-processeurs (µP, ça va + vite). Tant que tu n'inclus pas de module en ASM, il n'y a pas de soucis, un compilateur est justement là pour faire la traduction vers le µP cible.

C'est plus un problème de périférique. Pas question de lancer une appli graphique sur une carte mère dépouillé de toute carte graphique, qui dispose uniquement du mode texte !!!
De la même manière, en poussant le vice, un language ou une bibliothèque (une bibli' est un ensemble de fonctions (telles que celle qui permettent d'afficher une ligne à l'écran, de calculer un cosinus ou une racine carrée, de lire ou écrire un fichier sur le disque dur, etc...) qui forme une extention à l'interface de programmation, par abus, au "language") ;
une biblio' ou un language spécifiquement créé pour les téléphones portables ou les peacemakers ne permettra pas d'écrire des programmes ayant un sens sur une station de travail...


la deuxième concerne ces fameuses dll, je me suis toujours demandé ce qu'elles pouvaient contenir comme informations communes à plusieurs programmescar j'ai du mal à saisir encore les similitudes que peuvent contenir des programmes différents ??

Elle contiennent déjà, ce dont j'ai parlé au dessus : les fonctions de la bibliothèque standard, des fonctions type "drivers", qui permettent de convertir une commande (instruction) standard en manipulation d'un composant électronique, afin de s'abstraire (ignorer) des spécificités du matériel, etc...

En général, ce ne sont pas des "informations" au sens de "données", ou "document", mais des procédures, des routines, des sous-programmes. Exemple : la méthode permettant de décoder le MP3 est identique quelque soit le traitement effectué ensuite sur le son décompréssé. Il est donc tout à fait cohérent de créer un bibli' partagée, dite aussi dynamique (Dynamic Linking Librarie), qui se charge exclusivement de décompresser les MP3 et qui peux être partagée par différents programme.
kij_82 4100Messages postés jeudi 7 avril 2005Date d'inscription ContributeurStatut 30 septembre 2013Dernière intervention - 18 avril 2005 à 10:15
Tu prend quoi pour écrire tout ca d'un coup ? ;)
Répondre
SKZ- 24 avril 2005 à 15:04
En tout cas c'est pas bon pour la santé ;°)
Répondre
Ajouter un commentaire
Réponse
+1
moins plus
Un langage compilé génère directement un exécutable autonome, qui se suffit à lui-même pour fonctionner car il contient du langage machine. (C, VB, Windev)
Avantage : Rapide
Inconvénient : Fermé si on n'a pas le source, besoin de l'outil de développement pour modifier.


Un langage interprété a besoin d'un interpréteur (cqfd).
Par exemple, le qbasic d'il y a une dizaine d'année, se lançait avec la commande : qbasic /run prog.bas
Avantage : le programme prog.bas est un fichier texte, facilement modifiable.
Inconvénient : C'est forcément plus lent que quand c'est compilé.
jemd- 15 avril 2005 à 14:04
?? ah bon , je croyais, mais je sais pas grand chose ,qu'un compilateur était necessaire pour exécuter un programme ??
Répondre
pmx 142Messages postés vendredi 15 avril 2005Date d'inscription 14 mars 2008Dernière intervention - 15 avril 2005 à 14:15
Eh bien non ! C'est peut-être ce qui va clarifier tout ça ...

Un compilateur créé un programme executable (un .exe ou .com).
Tu peux lancer notepad.exe sans avoir de compilateur, non ?

Concernant les programmes interprétés, comment lancer un fichier texte contenant un programme basic sans l'interpréteur ?
Répondre
jemd- 15 avril 2005 à 17:20
ah d'accord !!
si j'ai bien compris ...
dans le cas ou on crée un programme dans un langage qui doit être compilé pour que le processeur le traduise...On doit avoir obligatoirement un compilateur, non ?! Et donc une fois le programme compilé il n'est plus nécessaire de faire appel sur n'importe quelle machine à un compilateur pour ouvrir le même programme. C'est ca ?!
Par contre dans un langage interprété, il est toujours nécessaire d'avoir sur la machine utilisée pour ouvrir le programme un interpréteur !? C'est ca ?
Mais alors les langages interprétés ne créent pas de ".EXE" !!
Ai-je tout compris ou manque t-il un détail dans le raisonnement ?
Répondre
pmx 142Messages postés vendredi 15 avril 2005Date d'inscription 14 mars 2008Dernière intervention - 18 avril 2005 à 09:16
C'est exactement ça !
Répondre
vkey pmx - 2 juin 2009 à 00:50
je vous donne le tuyaux


une compile est un simple command

et le compilateur compile tout cest code pour en former un plus gros ex windows media player



les compile son le son
les input
appel de windows fenetre pour media player de son nom

on ne peut pas executer un program compilateur et modifier windows media player
sellement dans le compilateur program et la matrix de compile

juste un ptis help pour exemple de code svp jai deja fais de la programation avec la tit tortue
ben un rifresh sa sera bon

tu ferme ta geule tu lis les cris de livre

tu apprend les code tu les ecrit les copie sa marche ben jai juste pas de structure osti
help ecriver moi a l adress reelstreet@hotmail.com //( merc1) beaucoup=+joie=++ (d avance12)?
Répondre
Ajouter un commentaire
Réponse
+1
moins plus
un language est dite compilé lorsqu'il est traduit en instructions lisibles par la machine (code natif) et peut être exécuté indépendamment de tout autre programme à l'exception du système d'exploitation.

par contre, un language interprété n'est pas exécuté directement par la machine mais par un autre programme appelé interprète ; il doit être en fonctionnement sur la machine où l'on veut lancer un programme interprété

on outre , il existe des langages dits semi-interprétés ou semi-compilés, pour lesquels il existe un compilateur traduisant le programme non pas en « langage-machine » mais en un code intermédiaire assez analogue à de l'assembleur. Pour pouvoir exécuter ces programmes sur une machine donnée, il faut y faire tourner un interpréteur pour ce code intermédiaire. Le code intermédiaire est souvent appelé p-code, Byte Code, code objet... ; l'interpréteur peut, lui, être appelé p-machine ou machine virtuelle.par exemple (java).
Ajouter un commentaire
Réponse
+0
moins plus
Tu as oublié que pour faire un programme multiplateforme, le compilé oblige à tout recompiler alors que l'interprèter peut passer facilement...

Par contre, si tu n'as pas la bonne machine virtuelle tu as des problèmes alors qu'avec le compilé seul l'OS est limitant...
jemd Luffy =) - 15 avril 2005 à 18:20
euh finalement ce n'est pet-être pas la même chose, java doit être compilé dans un premier temps d'après ce que je comprends et la machine virtuelle permet d'utliser ensuite le programme sur n'importe quel processeur .
question : cette machine virtuelle est-elle installée d'office par chaque fabricant ou bien est-elle utilisée dans le programme même ? ou bien est-ce encore un logiciel installé plus classiquement ??
des questions toujours des questions...
Répondre
beeboo 27Messages postés dimanche 17 avril 2005Date d'inscription 9 mai 2005Dernière intervention Luffy =) - 23 avril 2005 à 10:40
Le Java n'est pas, à proprement interprété, il se trouve dans un état entre l'interprété et compilé. C'est à dire que lorsqu'un source java est compilé, il ne génère pas du code machine du processeur de la machine sur lequel il se trouve mais un pseudocode machine qui est le même quelle que soit la machine et est interprété par une machine virtuelle.

La machine virtuelle est donc propre à Java (et sans doute à quelques autre langages) mais elle ne peut être considérée comme un interpretteur car les code qu'elle lit n'est pas le source.

Certaint langages, bien que compilés nécessitent un "runtime" c'est à dire une collection de fonctions (en général sous la forme de DLL) qui sont nécessaires à son exécution. Cela permet de créer un exécutable pas trop grand et facilement distribuable si l'on utilise des fonctions standards (c'est à dire qui utilisent les runtimes les plus communément utilisés et donc présents sur la plupart des PC)
Répondre
jemd- 23 avril 2005 à 11:24
oui mais de toutes façons, une fois interprété le langage sera compilé afin d'être traduit en binaire non ?? a moins que quelque chose m'aie échappé, ce qui est tout à fait possible
Répondre
hanaa beeboo - 17 mars 2009 à 23:50
ok je veux que l'interpréteur
Répondre
nicocorico- 17 juin 2011 à 12:49
En fait et pour simplifier, le processeur contient un registre qui pointe sur la prochaine instruction à éxécuter - le registre EIP -; dans le cas du language éxécuté, ce registre pointe sur les instructions du programme lui-même, alors que dans le cas de l'interprété, ce registre pointe sur les instructions de l'interpréteur; cet interpréteur lit pas à pas le texte ou des codes décrivant quelles fonctions il doit utiliser ainsi que les paramètres associés, et ce sans jamais donner la main (le registre EIP) aux codes lus puisque le processeur ne les comprendrais pas... et c'est donc l'interpréteur qui contient toutes les fonctions qui peuvent être exécutées, le programme se contentant de dire lesquelles. Le programme lu peut donc contenir du texte donnant le nom des fonctions ou bien des codes accélérant la lecture par l'interpréteur, une sorte de compilation donc...
Répondre
Ajouter un commentaire
Réponse
+0
moins plus
Ajouter un commentaire
Réponse
+0
moins plus
donc ces dll on peut en récupérer comme de vulgaires pilotes sur le net ? mais sur la machine , elles se situent ou , elles appartiennent au SE ou bien elles occupent une place définie sur le disque dur comme un logiciel classique juste avec une extension différente?

un merci énorme pour toutes tes explications, je viens de gagner 15 jours de travail.

en fait je viens de m'apercevoir que je ne connais pas bien le fonctionnement du SE car je pensais que les programmes ou n'importe quelle instruction passait d'abord par lui avant d'être traités par le µp !!
C'est toute mon approche de la machine qui vient d'être modifiée !
(j'ai récupéré le pavé de Tannenbaum sur les SE mais j'ai pas encore eu le temps de m'y plonger dedans)
SKZ- 24 avril 2005 à 15:18
elles appartiennent au SE ou bien elles occupent une place définie sur le disque dur comme un logiciel classique juste avec une extension différente?
Les deux mon capitaine !!!
Disons que c'est PLUTOT la deuxième solution, les DLL sont des fichiers que l'on trouve fournie avec des logiciels, sur le net, parfois gratuite, d'autre fois non.
Le seul point commun entre toutes c'est que se sont des BIBLIOTHEQUES, une collection de fonction qui vont aider le programmeur dans sa tâche : les sous-programme qu'elle propose lui évite d'avoir à réinventer la roue à chaque programme.
En tant que programmeur, tu peux te faire ta propre "jemd.dll" privée.

Mais certaines DLL fondamentale sont fournies avec le SE.
NB : une très grande majoritées des données du SE sont dans des fichiers "normaux" sur le disque. Parfois un peu cachés, protégés, mais des fichiers normaux.


en fait je viens de m'apercevoir que je ne connais pas bien le fonctionnement du SE car je pensais que les programmes ou n'importe quelle instruction passait d'abord par lui avant d'être traités par le µp !!

Et oui, comme je te disais, le SE supervise le matériel, mais dans la mesure où un programme ne souhaite pas accèder au matos (Disque Dur, écran, etc...) il n'a aucun besoin de passer par le SE, il fait ses p'tites bidouilles dans son espace mémoire réservé de façon autonome, en controllant directement le µP.

L'os garde quand même une certaine autorité : il est sensé pouvoir suspendre ou interrompre le processus sur demande de l'utilisateur.
Répondre
Ajouter un commentaire
Réponse
+0
moins plus
bonjour,

Je viens de voir le bios !

en fait si j'ai bien compris ce que je viens d'apprendre sur les langages et pour les intégrer dans une analyse par couche :

-Une fois le programme écrit,l'éditeur de programme est en relation avec le SE, lequel va mettre le programme à compiler par l'intermédiaire du bios en relation avec le compilateur qui une fois le programme compilé fait passer le programme toujours par l'intermédiaire du bios directement au processeur. Celui-ci une fois le programme exécuté, dirige les infos (ou plutôt les données ou mieux encore les bits)vers les périphériques de sortie qui vont afficher les résultats (ce qui veut dire que les données binaires seront transformées au niveau de la carte du périphérique en données analogiques).

ouf je me demande si j'ai bien tout compris ?? (en fait en résumant je me demande si le compilateur se trouve entre le SE et le µprocesseur ou entre l'éditeur et le SE?)

Merci à tous pour votre aide et particulièrement à SKZ
SKZ- 24 avril 2005 à 16:00
Bon, c'est un peu tout en vrac..
L'éditeur de programme, on parle d'IDE (Environnement de Developpement Intégré, en anglais), fait appel au compilateur, sur demande de l'utilisateur, mais le BIOS n'à pas grand choses à voir là dedans.
NB : en général, on peut appeller le compilateur soi-même.

Le BIOS (basic Input/Output System) est historiquement un très vieux composant.
Il propose des fonction de bases dont peut se servir l'OS.
Historiquement, l'OS est une sur-couche du BIOS.
Qu'est-ce que ça veut dire ? que le BIOS ne se place PAS entre le programme en language machine et le processeur.
C'est de la même manière que l'OS (du point de vue du programmeur), une collection de fonctions, de sous-programmes.

Encore une fois, le BIOS est activé uniquement sur demande (celà peut être une demande de l'OS, ou bien d'un programme, etc...)

Mais tout celà, depuis les années 90, n'est plus vrai.
Depuis que l'on a inventé le "mode protégé", qui permet de sécuriser la gestion de la mémoire dans un système multi-tâche (immagine si paint s'amuse à écrire dans le mémoire de word et vice-versa).
Le mode protégé introduit un nouveau type d'adresses mémoires, dites "virtuelle", et le code binaire du BIOS n'est pas compatible avec se mode.

Depuis, le BIOS ne sert plus essenciellement qu'à une seule chose : paramétrer, à la mise sous tension, les différents composant du PC, l'initialisation.
Pour celà, le processeur démarre en mode réél, charge le programme d'init du BIOS et le déroule.
En général, il se termine par le chargement et l'éxécution du contenu du premier secteur du premier disque dur.
Ce secteur est généralement un "Loader", un petit programme qui charge un plus gros.
Ce plus gros programme est en fait le système d'exploitation... Qui commute en mode protégé.
L'OS, ainsi est obligé de réécrire toutes les fonctions du BIOS.
Répondre
Ajouter un commentaire
Réponse
+0
moins plus
petite modification

"ouf je me demande si j'ai bien tout compris ?? (en fait en résumant je me demande si le compilateur se trouve entre le SE et le µprocesseur ou entre l'éditeur et le SE?)"

la réponse est : c'est entre le SE et le processeur
SKZ- 24 avril 2005 à 15:43
Perdu !!
Ni l'un, ni l'autre, ni le troisième.

Le compilateur, si tu tiens à l'encadrer, se trouve entre ton code source et ton fichier éxécutable.
C'est un programme dont les données d'entrée sont un programme, ça c'est pareil pour un interpréteur.
Mais la sortie est différente.
Dans le cas d'un compilateur, c'est un fichier programme, mais aucune action !!!

Regarde ça, j'ai shématisé la différence :
http://ghilt.phpnet.org/SKZ81/compil_inter.gif
Répondre
jemd- 25 avril 2005 à 10:49
...donc le compilateur appartient au langage de programmation !! ce qui veut dire que chaque langage possède son propre compilateur !! livré dans le package...
si je veux par exemple programmer en C je dois récupérer un fichier qui va comprendre et l'éditeur du C et le compilateur plus les différentes dll.
(les dll contiennent toutes les variables , constantes, fonctions du programme qui vont fonctionner dans un environnemnt (par ex windows), donc déjà compilées pour être utilisées par le processeur...c'est ca ??
Répondre
jemd SKZ - 25 avril 2005 à 11:07
concernant le shéma (trés sympa), je ne comprends pas comment physiquement le µp utilise le compilateur car je pensais jusque là que le µp exécutait du langage binaire traduit précedemment par ou le compilateur ou l'interpréteur...donc si j'arrive à concevoir la deuxième partie du shéma (avec l'interpréteur) j'ai du mal avec la seconde qui modifie ma connaissance (pseudo) du µp.
Répondre
Ajouter un commentaire
Ce document intitulé «  compilé ou interprété  » issu de CommentCaMarche (www.commentcamarche.net) est mis à disposition sous les termes de la licence Creative Commons. Vous pouvez copier, modifier des copies de cette page, dans les conditions fixées par la licence, tant que cette note apparaît clairement.

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes.

Le fait d'être membre vous permet d'avoir des options supplémentaires.