Compilé ou interprété

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.

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.

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é.

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).

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...

Rien à redire ;-)

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)

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

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