A voir également:
- Langage interprété vs compilé
- Udp vs tcp - Guide
- Honor magic 5 pro vs s23 ultra - Guide
- Naruto vs pain épisode netflix ✓ - Forum Cinéma / Télé
- X86 vs x64 ✓ - Forum Windows
- Psp 2000 vs 3000 ✓ - Forum PSP
9 réponses
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.
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.
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
Messages postés
4088
Date d'inscription
jeudi 7 avril 2005
Statut
Contributeur
Dernière intervention
30 septembre 2013
857
18 avril 2005 à 10:15
18 avril 2005 à 10:15
Tu prend quoi pour écrire tout ca d'un coup ? ;)
SKZ
>
kij_82
Messages postés
4088
Date d'inscription
jeudi 7 avril 2005
Statut
Contributeur
Dernière intervention
30 septembre 2013
24 avril 2005 à 15:04
24 avril 2005 à 15:04
En tout cas c'est pas bon pour la santé ;°)
pmx
Messages postés
138
Date d'inscription
vendredi 15 avril 2005
Statut
Membre
Dernière intervention
14 mars 2008
28
15 avril 2005 à 12:55
15 avril 2005 à 12:55
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é.
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é.
pmx
Messages postés
138
Date d'inscription
vendredi 15 avril 2005
Statut
Membre
Dernière intervention
14 mars 2008
28
15 avril 2005 à 13:44
15 avril 2005 à 13:44
Disons que le programme compilé n'a pas besoin du compilateur pour être exécuté. Par contre, le programme interprété a lui, besoin de l'interpréteur à chague exécution.
jemd
>
pmx
Messages postés
138
Date d'inscription
vendredi 15 avril 2005
Statut
Membre
Dernière intervention
14 mars 2008
15 avril 2005 à 14:04
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 ??
pmx
Messages postés
138
Date d'inscription
vendredi 15 avril 2005
Statut
Membre
Dernière intervention
14 mars 2008
28
>
jemd
15 avril 2005 à 14:15
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 ?
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 ?
jemd
>
pmx
Messages postés
138
Date d'inscription
vendredi 15 avril 2005
Statut
Membre
Dernière intervention
14 mars 2008
15 avril 2005 à 17:20
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 ?
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 ?
mehdi_boussarhane
Messages postés
50
Date d'inscription
dimanche 23 novembre 2008
Statut
Membre
Dernière intervention
15 janvier 2012
13
16 juin 2011 à 11:49
16 juin 2011 à 11:49
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).
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).
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
teebo
Messages postés
33491
Date d'inscription
jeudi 14 octobre 2004
Statut
Modérateur
Dernière intervention
24 février 2011
1 793
15 avril 2005 à 12:59
15 avril 2005 à 12:59
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...
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...
kij_82
Messages postés
4088
Date d'inscription
jeudi 7 avril 2005
Statut
Contributeur
Dernière intervention
30 septembre 2013
857
15 avril 2005 à 13:51
15 avril 2005 à 13:51
Ce qui te sert à interpréter ton code : par exemple, une machine virtuelle java, ou Perl.
++
++
jemd
>
kij_82
Messages postés
4088
Date d'inscription
jeudi 7 avril 2005
Statut
Contributeur
Dernière intervention
30 septembre 2013
15 avril 2005 à 14:02
15 avril 2005 à 14:02
machine virtuelle ou interpreteur c'est pareil ?
kij_82
Messages postés
4088
Date d'inscription
jeudi 7 avril 2005
Statut
Contributeur
Dernière intervention
30 septembre 2013
857
>
jemd
15 avril 2005 à 14:16
15 avril 2005 à 14:16
Euh... bonne question, je ne me l'a suis jamais posée à vrai dire !
Abus ou extension de langage ? je ne sais pas !
++
Abus ou extension de langage ? je ne sais pas !
++
Salut =)
c'est vrai que c'est une bonne question et à l'adresse suivante (http://emmanuel-remy.developpez.com/Java/Generalites/Generalites.htm) il y a :
"La machine virtuelle Java est aussi appelée interpréteur Java." donc je pense qu'on peut assimiler les 2 notions.
c'est vrai que c'est une bonne question et à l'adresse suivante (http://emmanuel-remy.developpez.com/Java/Generalites/Generalites.htm) il y a :
"La machine virtuelle Java est aussi appelée interpréteur Java." donc je pense qu'on peut assimiler les 2 notions.
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)
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)
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.
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.
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
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
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.
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.
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
"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
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
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
...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 ??
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 ??
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.
16 avril 2005 à 10:21
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 ...