Discussion :

[Pierre Maurette]

Bonjour,
J'ai lu le fil en diagonale. Je donne juste mon avis, qui ne vaut que ce qu'il vaut.

Quand on demande à quelqu'un "Dans quel langages programmez-vous ?", s'il répond "C, Java et assembleur", ça ne me gêne pas, tout le monde comprend. Bien qu'on aurait pu préciser par exemple "assembleurs Motorola, x86 et PIC".

D'un autre coté, qu'est-ce qu'un langage informatique ? c'est à mon avis quelque chose de plus ou moins normatif qui décrit comment obtenir un comportement - un résultat prédictible - à partir d'un texte, le code source. Dans cette acception, les langages "assembleur" sont écrits par les ingénieurs chez les fondeurs. Et encore, essentiellement ceux de la première génération, celle qui définit l'architecture. Ensuite on va au mieux patcher le langage. L'idée de langage est alors dans un jeu d'instructions cohérent, des mnémoniques parlant, etc. tout ce qui fait qu'un listing - même sous DEBUG sous DOS - décrit de façon à peu près lisible ce qu'il fait.

Les "assembleurs", plus généralement des macro-assembleurs, sont alors des outils très puissants. Ils assurent bien entendu le rôle de traducteur du texte en code objet, c'est mécanique, et en général rendent ce code objet exécutable par l'OS - travail du lieur -, ce qui est beaucoup moins trivial. Ils sont fait pour que le code source soit lisible - symboles - donc maintenable. Je répète, ce sont vraiment des outils puissants, par exemple le préprocesseur de MASM est bien mieux fichu - quoiqu'un peu ésotérique parfois - que celui du C ou du C++. Mais la chaîne da fabrication se distingue de toute celles utilisant un langage de haut niveau sur un point FONDAMENTAL: le code sorti d'un "assembleur" est TOTALEMENT prédictible. Comparé à un vrai langage, disons à un langage de haut niveau, il n'y a aucune mise en relation entre code source et comportement. Le macro-assembleur génère non pas un comportement, mais plus ou moins une image mémoire(*). Et le manuel du fondeur - le microprocesseur - fait correspondre chaque octet de cette image mémoire et un comportement local, instantané. Rien d'un tant soit peu global, même au niveau de la fonction la plus simple.

(*) Cette image mémoire est totalement prédictible, je le répète. Mais effectivement, les étapes édition de liens + loader font qu'il est préférable de faire confiance à son assembleur que d'assembler à la main

[amaury pouly]

C'est aussi une bonne manière de voir ce dont la machine est capable. Autrefois, il y avait plein de machines différentes qui avaient chacune leur caractéristes. Aujourd'hui, il y a 99% de PC, et quand il y a autre chose, on lance un système d'exploitation dessus dont la première fonctionner est de faire abstraction de la machine et d'uniformiser le tout. Moralité : tous les atouts et les particuliarités d'une machine sont passés sous silence. Et pour compenser, on ajoute toujours plus de puissance. C'est comme si, au lieu de dessiner des avions aérodynamiques, on partait de l'existant - un autobus -, qu'on lui collait deux ailes et qu'on motorisait suffisamment jusqu'à ce que ça vole.

Je ne suis pas tout à fait d'accord avec la comparaison.

Le but d'un système d'exploitation est d'abstraire, certes, mais il y a de bonnes raisons pour cela. Si l'on devait tenir compte des subtilités de chaque machine dans chaque programme, on aurait pas finit ! Justement, c'est le système d'exploitation qui s'en charge et c'est à lui qu'est délégué la tâche de bien utiliser toutes les particularité de la machine. D'ailleurs ta comparaison n'a pour moins aucun sens. L'autobus a bien des portes, comme l'avion. Il peuvent tous les deux se déplacement, tourner, gérer leur vitesse,... Certes, les mécanismes sous-jacents n'ont rien à voir mais ils restent des véhicules. Et bien le pendant du système d'exploitation, c'est pour moi ce concept et non pas l'autobus en lui-même.

D'ailleurs, je te ferai remarquer, à titre de pinaillage, que le concept d'autobus est déjà une uniformisation. Entre un autobus un étage et un deux étages, entre une propulsion à essence et à diesel, entre le volant à gauche et à droite,... il y a bien des façon de concevoir ton autobus et pourtant qu'un tu prends un autobus, tu te fiches souvent de savoir quels sont ses spécifications. L'important pour toi c'est que c'est un transport de masse !

[Obsidian]

Je ne suis pas tout à fait d'accord avec la comparaison.

C'est parce que tu n'as pas tout-à-fait compris ce que je voulais dire, ce qui n'est pas très grave.

Le but d'un système d'exploitation est d'abstraire, certes, mais il y a de bonnes raisons pour cela. Si l'on devait tenir compte des subtilités de chaque machine dans chaque programme, on aurait pas finit ! Justement, c'est le système d'exploitation qui s'en charge et c'est à lui qu'est délégué la tâche de bien utiliser toutes les particularité de la machine.

On est bien d'accord. Ce n'est pas l'abstraction en elle-même que je critique mais ses seuls effets pervers.

D'ailleurs ta comparaison n'a pour moins aucun sens. L'autobus a bien des portes, comme l'avion. Il peuvent tous les deux se déplacement, tourner, gérer leur vitesse,... Certes, les mécanismes sous-jacents n'ont rien à voir mais ils restent des véhicules. Et bien le pendant du système d'exploitation, c'est pour moi ce concept et non pas l'autobus en lui-même.

Oui et, en en remontant encore plus haut, les véhicules et les appareils électro-ménagers sont tous des machines. Au bout d'un moment, il faut quand même recommencer à se pencher sur les différences.

D'ailleurs, je te ferai remarquer, à titre de pinaillage, que le concept d'autobus est déjà une uniformisation. Entre un autobus un étage et un deux étages, entre une propulsion à essence et à diesel, entre le volant à gauche et à droite,... il y a bien des façon de concevoir ton autobus et pourtant qu'un tu prends un autobus, tu te fiches souvent de savoir quels sont ses spécifications. L'important pour toi c'est que c'est un transport de masse !

Même remarque qu'au-dessus. Tu peux concevoir un bus à deux ou trois étages à partir d'un bus existant (chassis, contraintes terrestres, manière de le conduire, etc), mais tu ne peux pas concevoir un avion à partir d'un autobus. À partir d'un moment, la différence est trop grande et l'existant devient trop peu adapté. Tu dois concevoir un appareil beaucoup plus léger (la composante verticale a beaucoup moins d'influence sur un engin roulant), tenir compte des lois de l'aéro-dynamique, et tu dois piloter ton avion d'une manière totalement différente de celle dont tu conduit ton bus. La seule chose restante sont les sièges qui, eux, ne sont mêmes pas obligatoires (avions cargo à containers) et qui doivent de toutes façons être repensés pour être adaptés au vol.

[amaury pouly]

D'accord, je n'avais pas très bien cerné ta remarque. Toutefois, quand on y pense il n'y a pas tant de différences que ça entre les différentes machines dont on dispose. Exception faite de matériels hyper spécifiques(et encore), tous les ordinateurs actuels sont de type Neumann, ont pratiquement tous les même bus d'entrée-sortie, utilisent les même mémoires,... Au fond, seule la force brute fait vraiment la différence. Les uniformisations que font les systèmes d'exploitation ne font que refléter l'uniformisation sous-jacente du matériel. Après on peut discuter si c'est bien ou pas.

[souviron34]

D'accord, je n'avais pas très bien cerné ta remarque. Toutefois, quand on y pense il n'y a pas tant de différences que ça entre les différentes machines dont on dispose. Exception faite de matériels hyper spécifiques(et encore), tous les ordinateurs actuels sont de type Neumann, ont pratiquement tous les même bus d'entrée-sortie, utilisent les même mémoires,... Au fond, seule la force brute fait vraiment la différence. Les uniformisations que font les systèmes d'exploitation ne font que refléter l'uniformisation sous-jacente du matériel. Après on peut discuter si c'est bien ou pas.

Pas tout à fait...

Ce que tu dis est vrai pour le monde PC (et encore).

Mais ce à quoi réfère Obsidian, c'est les différents types de constructeurs, et le fait qu'il n'y a pas que les PCs dans le monde informatique.

Il faut bien comprendre une chose, c'est que la généralisation a , depuis le début, été faite pour la portabilité des applications, pas pour ne pas profiter des systèmes..

Ainsi, dans l'ordre chronologique, on citera : les langages de programation "portables" (C, Fortran, Cobol). Puis les échanges de fichiers (Kermit, ancêtre de ftp). Puis la normalisation graphique (XWindow). Puis éventuellement (avec des variantes) la normalisation de la gestion d'une machine (Unix). Puis la normalisation de l'interconnection (http) et celle de la présentation de documents (HTML), et maintenant de la configuration des applications (XML) et de leur analyse (UML).

Ces normalisations successives n'ont eu pour but que de faciliter (et rendre transparent) le portage d'une application (ou d'un document) d'un constructeur à l'autre, pas de gommer les différences entre les constructeurs...

Les matériels, au contraire, ne sont pas uniformisés. C'est bien la raison pour laquelle les graphistes continuent à utiliser des Macs ou des Silicon Graphics, pour laquelle Hewlet Packard a des serveurs qui ne sont pas des serveurs "PC", pour laquelle NEC ou IBM fabriquent des supercalculateurs, etc etc... Que ce soit les bus, les cartes graphiques, etc, ne sont pas les mêmes, et ils ont leurs spécificités...

Alors il se trouve que Mi$ avec sa puissance commerciale a "intoxiqué" le marché, et que comme le dit Obsidian 99% des ordis d'aujourd'hui sont des PCs. Mais cela n'empêche que son point est valide...


PS: une petite remarque au cas où vous seriez passé rapidement dessus. J'ai dit que Unix (et ses dérivés dont Linux) a été adopté pour étendre la portabilité de la gestion d'une machine. Cela n'empêche en rien que les perfomances ou les caractéristiques du matériel soient différentes, et qu'il n'y ait pas moyen d'en profiter...

[Jean-Marc.Bourguet]

comme le dit Obsidian 99% des ordis d'aujourd'hui sont des PCs.

Qu'entends-tu par ordinateur? Pour moi, la majorite des ordis aujourd'hui sont des machins embarques. Je ne sais plus ou j'ai lu que par an BMW seul vendait plus de processeurs tournant Linux que MS ne vendait de licenses de Windows.

[souviron34]

un rapport très étoffé (en français ) sur le dernier Consumer Electronics Show à Las Vegas en Janvier (http://www.oezratty.net/wordpress/20...port-ces-2009/) indique , p 96, uniquement pour les mobiles :

Symbian : 68 %
Apple: 3.6
RIM : 10.6
Microsoft : 12.2
Linux : 4.4
Others : 1.2

Je ne trouve pas les satistiques sur les PCs de part le monde, mais ça doit être assez proche de 85 % M$, 15% Linux.

[Rémi Coquet]

…L'assembleur est un langage par métonymie, c'est tout…

...Moi je dis que l'assembleur est une compétence… on travaille à autre chose qu'à superposer toujours plus de couches de tâches à l'utilité plus bureaucratique les unes que les autres…

… j'accueille avec autant d'enthousiasme tout ce qui témoigne d'une économie de concepts face à l'invasion des rouleaux-compresseurs qui écrasent tout pour mieux vendre leurs middleware ingérables.

…un langage informatique est un ensemble de conventions qui permettent à un humain de communiquer avec une machine afin de lui faire executer un traitement...

...On peut cependant admettre que dans l'acception "langage de programmation", on parle d'écrire du texte, lisible, qui ensuite est transformé par un outiil pour être compréhensible par la machine...

… me semble naturelle d'attendre d'un langage de programmation qu'il apporte un minimum d'abstraction, et que ce n'est clairement pas le cas de l'assembleur…

…Je crois que tu confonds entre langage haut niveau et bas niveau...

… la manière de construire un programme en assembleur est toujours la même : une ligne contenant un code opération, découpée en quatre champs : l'étiquette (directement soluble en adresse mémoire), le mnémonique de l'instruction, la ou les opérandes, et le commentaire.
Si, avec tout ça, l'assembleur n'est pas un langage…

…un compilo produit de l'assembleur de meilleur qualité que ce que peut faire n'importe quel être humain... Je vois mal l'intéret de "programmer" en assembleur…C'est aussi en ça que je dis que de parler de langage de programmation dans le cas de l'assembleur alors qu'il n'a plus vocation qu'à être produit par un compilateur, boarf...

…

Sous la capillarite de ce que certains nomment et craignent troll…

De nombreuses choses très intéressantes, le sujet est épineux et plusieurs notions s'entrechoquent ; En effet, beaucoup d'implicites non-traitéss et écartés:
HLL/LLL Compilateur/Dé-compilateur Assembleur/Dé-assembleur Efficacité/Productivité Pertinence/Passéisme Pouvoir/Manipulation etc.

En tout cas, bravo, bel effort collectif !

Je ne pouvais raisonnablement pas tous vous citer et j'espère ne froisser personne avec les "raccourcissements" de leurs propos que je ne souhaite que formels.

Pour revenir sur certaines notions subjectives liées aux langages:

- D'une part, il me semble (j'ai bien dit, il-me-semble) qu'un langage est un conteneur de descripteurs d'intentions, de faits, qui peuvent être formulés de diverses manières et sujets à une certaine souplesse d'interprétation: Une compilation de référents, de citations, d'évocations à d'autres ensembles complexes de concepts préétablis, réunis pour former un discours cohérent. Par contre, un rassemblement de commandes minimalistes, même au sein d'une routine, n'en fait pas encore un langage de ce point de vue là.
Un "langage" n'est pas seulement un empilement de commandes de base mais des descriptions et des citations (includes, bibliothèques…) finalement, un ensemble de scripts (qui ne sont donc ni l'exécution ni le code) très génériques d'automation destinés à un interpréteur de langage, justement, qui le traduit en exécutions qui ne sont plus elles-mêmes un langage, mais ses représentations finales, actuelles, le code: Une série de commandes qui n'ont plus de sens globale, même pas pour le CPU cible !
Ce principe de traduction des intentions et des concepts est intéressant, dans une certaine mesure, pour la portabilité (il ne faut pas rêver non-plus !).
La différence est subtile à certains endroits et forcément sujette à tensions, selon ce que l'on souhaite défendre ou promouvoir implicitement: C'est, il me semble encore, bien là que le "vrai" (si la vérité existe dans ce genre de débat) problème se situe et que la discussion (ou le troll si certains préfèrent la nommer ainsi) à ses moments de bravoure !

- D'autre part, les notions de Compilation et d'Assemblage ne recouvrent pas du tout les mêmes mécanismes et il paraît normal de vouloir abstraire le 'seul', particulier, qu'est celui qui est assemblé, de tous ceux qui sont compilés. Il est certes maladroit, ou plutôt malaisé, de se "battre" sur un vocable aussi fourre-tout et diversement appréhendé: Langage, mais le sujet et surtout les tensions récurrentes qu'il produit, démontre bien que l'assembleur se démarque d'une manière qu'il est seul à posséder de part ses propriétés uniques d'autonomie et de control. Il est la base porteuse (la dernière atteignable humainement, que cela soit en hexadécimal ou via une norme de transcodage de mnémoniques) que génère in fine un compilateur. Il est capable, sans l'intermédiaire d'une interprétation ni besoin de passes multiples de mise en formes ou de compléments, de produire "la même chose" par simple transcodage: Il n'y à donc pas de traduction, ce qui est le propre d'un langage, mais simplement, échange "in place", sans retranchements, sans ajout, ni substitution un peu à la manière d'une norme:
Un exemple de confusion similaire, la norme MIDI, appelée par certains "Langage MIDI" ce qui est compréhensible mais néanmoins totalement inexact. Le morse, pareillement, est un transcodage sans intelligence, une norme d'échange qui dépasse apparemment les langages car qu'il peut véhiculer tous ceux qui utilisent sont alphabet, sa norme, certes, cela ne fait pas de lui un langage pour autant mais simplement une norme d'échange, ou plutôt un support de transmission objective non interprétant: Il est le canal et non l'objet.

… J'espère que chacun comprendra le propos et n'en fera pas "un troll capillotracté" justement .

[moumine]

Salut,

− INFORMAT., PROGRAMMATION. Ensemble de symboles et de règles permettant de combiner ces symboles afin de donner des instructions à un ordinateur.
♦ Langage de programmation. ,,Langage préétabli utilisé pour écrire les programmes d'un ordinateur déterminé`` (Mess. Télém. 1979). Langage symbolique. ,,Langage de programmation utilisant des codes mnémoniques pour représenter les instructions machines`` (Informat. 1972). [Langage symbolique :] code intermédiaire entre le langage machine et les langages externes (langues naturelles ou langages documentaires), et permettant au programmeur de communiquer aisément avec l'automate. C'est pourquoi les langages symboliques sont aussi appelés langages de programmation (Coyaud, Introd. ét. lang. docum., 1966, p. 14).

Je crois que c'est assez clair.
(D'après le dico)

A+

[Forthman]

Rigolez pas, mais moi aussi quand Rémi Coquet intervient, ça me fait mal à
la tête

Avec mon faible QI il me faut lire 2 ou 3 fois ses phrases pour les comprendre... et encore je n'arrive à en saisir que 30% je pense

D'ailleur si j'ai bien compris (là je prends des risques)
sa réponse est : p't'être bien que oui, p't'être bien que non

a+ François

[Rémi Coquet]

@ (feu)Pierre:
@Forthman

p't'être bien que oui, p't'être bien que non

Effectivement, tu (vous) souligne(iez)s la différence entre un langage sujet à interprétations et controverses, nécessitant un traducteur et, un code formel (immuable dans sa forme comme dans son fond) contrôlé directement par un codeur, sans intermédiaire (nous y reviendrons plus loin):

Je constate donc que chacun a, de manière implicite ou explicite, (pour prendre deux termes dont la symétrie permet, comme pour subjectif/objectif, de simplifier l'énoncé de concepts complexes qui font appel à des démonstrations a faibles propensions universelles) clairement compris le propos.

Pour être direct:

Je, considère que

- Les mnémoniques sont "clairement" du code et non un langage (le µP cible ne comprenant pas ce qu'il fait)

- Les HLL et les LLL sont tous des scripts et non du code natif (La forme et le fond s'adressant à deux interprétations successives (la logique et les intentions particulières du codeur puis celle du compilateur) avant de devenir des ordres non interprétés)

- Un compilateur r-assemble, fait une compilation de plusieurs sources avec interprétations, dans le but de fournir à l'assembleur un code assemble-able (La suite Visual pour son Assembleur commun MAsm par exemple). L'utilisation d'un compilateur tiers, celui "fourni" dans le SDK, celui d'Intel… produisant des résultats radicalement différents, tant au niveau du code que des performances de ce dernier: Il est donc clairement question d'un langage situé à la hauteur du compilateur).

- Un Assembleur assemble du code, généré et interprété seulement par le codeur humain automate intermédiaire.

- L'utilisation d'un même vocable pour désigner deux concepts recouvrant deux réalités largement différenciées pratiquement, est très dommageable pour des relations humaines de qualité, voir raisonnables:

• Assembleur: Outil qui assemble du code (ou "swapeur in place" pour utiliser un gallicisme douteux)

• L'assembleur: Fait de coder directement à l'aide de mnémoniques de substitution

Si la forme et un peu plus claire (c'est ce que je souhaitai initialement… maintenant le résultat objectif sera soumis à votre appréciation) je ne suis pas sûr que cela n'engendre pas des agacements épidermiques (CF: Post ayant trait à la double négation).

[Invité]

Je crois, deadalnix, que tu confonds...

L'ensemble des instructions défini un langage. (MOV, ADD, SUB... ce sont des symboles d'opérations , au même titre que read, fopen, ou new...)

Comme le dit Médinoc, c'est le code machine qui lui n'est plus un langage.

Mais quand tu fais un programme en assembleur, il faut bien que tu le compiles pour le rendre exécutable. C'est donc bien un langage de programmation...

-------------------------------------

Pas tout à fait !

les instructions MOV, ADD, etc...sont directement comprises par le processeur

Si avant compilation, on a dans le code source assembleur :
MOV EAX,1
ADD EBX,EAX

Apres compilation, on aura la meme chose !!!


Nooptax

[Médinoc]

Ben non.
Après compilation, tu auras un code de quelques octets.

[Rémi Coquet]

Pas tout à fait !

les instructions MOV, ADD, etc...sont directement comprises par le processeur

Si avant compilation, on a dans le code source assembleur :
MOV EAX,1
ADD EBX,EAX

Apres compilation, on aura la meme chose !!!

Ben non.
Après compilation, tu auras un code de quelques octets.

Le terme compilation est ici totalement inapproprié (c'est un là le véritable problème et non pas une simple facétie linguistique, justement !) pour ne par dire dangereusement inadéquat par les faits même qu'il suggère: Celui d'assemblage est propre "uniquement" à l'assembleur. Assembler et compiler ne sont pas, et ne seront jamais, des synonymes ; il est donc déconseillé de les utiliser de manière indistincte. Il ne viendrait à l'idée de personne d'assembler du C++, C# ou tout autre langage (la liste des opérations est d'ailleurs amusante). Il existe des HLL et des LLL, cependant tous sont des langages comme ces termes l'indiquent clairement. L'assembleur n'est pas un LLL, c'est "de" l'assembleur. On parle d'assembleur 8086, 6800.. Certes, mais à cause, justement, des différences de substitutions: Mov, par exemple, étant substitué de manières différentes selon le µP cible. La soi-disant portabilité des HLL étant une vue de l'esprit et sous-entend, par implicites douteux et simplistes, une phase d'assemblage sur-interprétée ?!?
[TROLL ON] La productivité étant le prétexte d'un prosélytisme éhonté ayant pour but de vendre toujours plus d'outils de production sous licence. Ceux-ci étant conçus pour dévaloriser (rendre à la fois commun et confus) de plus en plus un métier, forçant ainsi la baisse des salaires du plus grand nombre au profit de celui des consultants…[/TROLL OFF]
Donc, assembler, c'est substituer "in-place" un strict et unique équivalent numérique:
Ceci "est" cela
et non:
Ceci "signifie" cela

Si le langage est une représentation de concepts complexes, d'éléments chaînés entres-eux, les mnémoniques ne sont que des substitutions uniques formées à partir d'initiales de concepts dans le but de faciliter leur mémorisation ; mais leur équivalence est univoque et ce dans tous les cas.
Tout comme l'icône est (depuis un bon petit moment) la représentation simplifiée, sous forme d'image typique, d'une réalité (l'antitype) plus grande et plus complexe, les éléments d'un langage compilé sont des conteneurs multiples:
If peut signifier -> cmp, test, or, add, sub, xor, cmovxx etc. la liste est longue.
En assembleur, il faudra faire un choix nettement plus précis, celui-là même que ne fera pas le compilateur X en raison de sa vision contextuelle proche de la cécité (et encore… chaque compilateur produira un code différent selon les facéties de ses concepteurs) afin que le processeur effectue d'une manière exacte et rigoureuse l'enchaînement des commandes que le codeur a imaginé et écrit.
Un PE qui compilerait, serait injustement nommé "Assembleur" par son (ses) concepteur(s) et justement nommé "compilateur" par ses détracteurs.
Effectivement, dire " les instructions MOV, ADD, etc. sont directement comprises par le processeur" est "vrai dans le principe" et "Apres compilation, on aura la même chose" un "paraître un abus" de langage (là encore justement). Cependant, ce qui est exprimé ici, c'est clairement l'unicité de sens face à l'ambivalence, l'opposition irréductible entre interprétation (compilation) face à l'assemblage:
Il n'y a "aucune" différence entre xor eax 32 et 83 F0 20.
Simplement, le premier est exprimé sous forme mnémonique le second sous forme numérique.
Sans vouloir lancer un troll au meilleur de sa forme, personne ne parlera de langage dans le cadre d'une substitution 020 (Hex) par 32 (Dec) ou par 100000 (Bin) tout au plus de changement de base… Cela paraîtrait évidemment un peu capillotraqué, même si le langage des nombres existe pour certains ésotérismes n'ayant que peu de rapport avec l'assemblée des assembleurs.

[souviron34]

Pas tout à fait !

les instructions MOV, ADD, etc...sont directement comprises par le processeur

Si avant compilation, on a dans le code source assembleur :
MOV EAX,1
ADD EBX,EAX

Apres compilation, on aura la meme chose !!!

Ben non, sinon il suffirait que tu lances ton .asm..



C'est ce que j'ai répété plus haut..

Du moment qu'il y a traduction, c'est un langage...

On n'édite pas un programme en assembleur en écrivant je ne sais pas quoi en binaire..

On écrit un utilisant un ensemble d'instructions faisant partie d'un "jeu d'instructions", dont l'expression ASCII signifie relativement quelque chose pour l'humain..

Une fois cela fait, on ne peut pas l'exécuter tel quel..


Qiue je sois sous Unx ou sous DOS, si je tapes "MOV" ou "ADD", cela n'appellera pas ce que je souhaites, mais (si cela existe) l'utilitaire (binaire) portant ce nom, et non pas ce que fais la traduction de cette instruction par la "compilation" de mon programme assembleur.

Le terme compilation est ici totalement inapproprié (c'est un là le véritable problème et non pas une simple facétie linguistique, justement !) pour ne par dire dangereusement inadéquat par les faits même qu'il suggère: Celui d'assemblage est propre "uniquement" à l'assembleur. Assembler et compiler ne sont pas, et ne seront jamais, des synonymes ; il est donc déconseillé de les utiliser de manière indistincte.

Enfin, dans un forum tel que dvp, il faut quand même rester au niveau..

Nous ne sommes pas (pour la plupart) des chercheurs en informatique de systèmes, ni en ethnolinguistique...

Mais simplement des "programmeurs", plus ou moins avancés et plus ou moins spécialisés dans un domaine d'applications..

Or doncques, pour ce "néophyte" de la discussion philosophico-linguistique, l'argument déjà présenté maintes fois et repris ci-dessus est clair : quel que soit le terme utilisé, on ne dialogue pas avec le coeur de la machine directement en assembleur à partir du "prompt" de l'OS, il faut faire tourner un autre progamme (binaire) (que l'on l'appelle "compilateur" ou "assembleur" (et c'est là qu'est la confusion, pas sur l'opération, mais sur le nom de l'outil)), qui prendra en entrée notre fichier (texte, donc éditable et lisible à l'oeil nu) et le transformera en un ensemble binaire (non éditable ni lisible à l'oeil nu), qui lui sera compris par la machine... DONC C'EST UN LANGAGE...

La confusion sur le mot "assembleur" provient non du langage, mais de l'outil pour produire le code binaire.. Dans un cas (autres langages) on utilise les mots "compilation", "compiler", "compilateur", et "éditeur de liens", dans l'autre on utilise les mots "assembleur" ou "assembler", ce qui porte à confusion puisque dans ce cas le même mot est utilisé pour l'outil et pour le langage..

Mais en ce qui concerne le "jeu d'instructions que l'on écrit dans un fichier texte afin de définir un programme", c'est bien un langage....

[Rémi Coquet]

Je vais "tenter de faire court" vu que pas mal de choses ont été largement déjà dites:

Du moment qu'il y a traduction, c'est un langage...

L'inversion de sens te trompe:

Du moment que C'EST un langage il y à traduction, l'inverse est un implicite que tu ne démontres pas. Tu affirmes donc ici qu'il y a traduction sans le justifier, je soutiens très fermement le contraire:

La traduction induit une interprétation, désolé. Ici, dans la phase d'assemblage, il n'y a aucune interprétation possible, uniquement une substitution garantie unique: A = 1 et uniquement 1, B = 2 et uniquement 2 etc. Ni A ni B ne sont traduits en 1 et 2, ils sont juste toujours substitués de même univoque.
Le codeur en assembleur n'écrit donc pas un script mais le code final transcodé. Non pas une représentation de concept mais un équivalent formel unique.
L'ASCII n'est pas un langage que je sache, tout au plus un format utilisable dans le meilleur des cas par un protocole, c'est le même cas que pour MIDI etc. Si tu programmes donc en langage ASCII, plusieurs risquent de t'appeler dactylo.

On n'édite pas un programme en assembleur en écrivant je ne sais pas quoi en binaire...

Je crains que tu ne te sois fait pas mal d'ennemis en une seule affirmation:

- Non seulement il n'est pas question de "n'importe quoi" au niveau de l'écriture Mais...

- Plusieurs ayant écrit tout au long de leurs vies des programmes et pas des moindres ! Uniquement en hexadécimal ou en masques binaires (tu vas me dire qu'ils ont été traduits d'hexa en binaire ?!?).
Pour certains, cette forme d'édition est nettement plus lisible (je ne pense pas que n'es jamais réellement fais de l'assembleur, cela se voit: Ne le prends pas mal, ce sont toujours les mêmes profils qui affirment les mêmes lieux communs ou raccourcis à base d'implicites, ou légendes urbaines, ou désinformation(s) ou banalité(s) ou …).

On écrit un utilisant un ensemble d'instructions faisant partie d'un "jeu d'instructions", dont l'expression ASCII signifie relativement quelque chose pour l'humain..

Une fois cela fait, on ne peut pas l'exécuter tel quel..

Je ne reviens pas sur la première affirmation largement traitée ailleurs mais la deuxième est totalement fausse: Une fois cela fait (comme tu dis) tu peux parfaitement le lancer ! Rien ne t'empêche non-plus de coder en temps réel, de modifier ton code dynamiquement etc.
Cela s'appelle de l'assembleur, un PE, un exe enfin du code exécutable. Quelle magie imaginais-tu donc que nous allions avaler ?

Enfin, dans un forum tel que dvp, il faut quand même rester au niveau..

Je me permets de ne pas répondre à cette assertion incongrue ni à une bonne partie de la suite qui contient la réitération d'affirmations totalement erronées que j'ai déjà suffisamment traitées, avançons. Ceci dit, je ne pense pas non-plus que DVP fasse garderie ('Ha... un instant... on me parle dans l'oreillette...').

Plus sérieusement (ou moins, je ne sais plus):

...(un outil)... qui prendra en entrée notre fichier (texte, donc éditable et lisible à l'oeil nu) et le transformera en un ensemble binaire (non éditable et lisible à l'oeil nu), qui lui sera compris par la machine... DONC C'EST UN LANGAGE...

Tu dis "donc" ad hoc, démonstration imparable, je suis extatique.

… Mais en ce qui concerne le "jeu d'instructions que l'on écrit dans un fichier texte afin de définir un prorgramme", c'est bien un langage....

Je constate, effectivement, que le niveau est tel que tu le décri(e)s: C'est bien un langage car c'est lisible (ou pas) à l'œil nu: Avec une démonstration d'une telle ampleur et d'une telle précision j'espère que tu es devenu au moins consultant ou MVP -> Nous entrons de facto dans "un lieu où la main de l'homme n'a jamais mis le pied" Ça c'est sûr, c'est du langage ou pour le moins une forme linguistique attrayante que je me garderai bien de commenter (Ha, c'est déjà fait ?).

Dis-moi, je profite de tes lumières pendant que tu es encore "de" ce monde, puisque le µP cible "comprend", ne peut ont pas parler de langage -> Tiens, essaies "Langage Machine" ça devrait plaire comme raccourcis pour ajouter à la confusion d'implicites.

L'assembleur n'est pas un langage, tout au plus un transcodage ultra rigide, c'est ce qui fait d'ailleurs sa puissance face aux langages abstractifs. Il est possible l'écrire directement dans une EE.PROM ou même directement dans la mémoire spécialisée d'un µP. Mais là, puisqu'on ne passe plus par de l'ASCII lisible, on ne parle plus de langage mais de don au chat. Le Chat machine est donc à proprement parler un…

[souviron34]

Pour certains, cette forme d'édition est nettement plus lisible

J'admet le "pour certains", mais ce n'est, je ne pense pas, et de très très loin, la majorité sur ce site, comme dans la profession..

(je ne pense pas que n'es jamais réellement fais de l'assembleur, cela se voit: Ne le prends pas mal, ce sont toujours les mêmes profils qui affirment les mêmes lieux communs ou raccourcis à base d'implicites, ou légendes urbaines, ou désinformation(s) ou banalité(s) ou …).

Non, juste quelques petites centaines de lignes sur un PDP 11/73 en 1986/87, au Laboratoire Central de Thomson..


je ne vais pas plus loin, il y a trop ..


Ah pardon.. Excuse-moi.. Je ne suis pas théoricien.. Juste un grand pratiquant...

[Graffito]

J'ai lu en diagonale, mais pour répondre à la question initiale sur la terminologie, revenons 30 ans en arrière et plus.

A l'époque où la plupart des participants au forum étaient en culottes courtes ou juste à l'état de projet, on classait :

• Cobol, fortran ou C sous le nom de "langages évolués",
• l'assembleur avait aussi droit au titre de "langage de programmation",
• le code binaire exécutable étant appelé "langage machine".

Ainsi l'assembleur était un langage.

Quant à savoir si la signification du mot "langage" a évolué avec les progrès techniques ....

[Rémi Coquet]

Culottes-courtes et centaines de lignes sur un PDP 11/73 en 1986/87

La base de l'argumentation, puisqu'il est question d'argumenter sur une question ouvertement trollesque, descend donc d'un cran:
"Autrefois, quand vous n'étiez pas là..." Ou, "Autrefois on appelait cela comme ça, c'est donc une "réalité" normative".
Plus amusant, quelques centaines de lignes (hello word ?) peuvent servir de base aux pratiquants face aux "théoriciens" (ceux qui ne pensent pas la même chose que nous en fait).

En un maux, ce n'est même pas la peine d'argumenter sérieusement ou même d'en discuter: For bien, pourquoi donc poster dans ces cas là ?

Je suis sûr que plus d'un client ou adepte des HLL à haut rendement de productivité, se montreront comblés par ces genres de discours conformistes et rassurants "à pas cher" [FONT=Verdana]pour lisses encéphales[/FONT].

Il y a, cependant, énormément de chances que plusieurs parmi nous maîtrisent parfaitement et depuis longtemps le sujet, peut-être même avec une antécédence certaine et soient des pratiquants notoires... Terrain donc glissant où les étiquettes n'assurent rien de valide, rien qui n'aille de soit…


Pour ma part, vous l'avez compris, je ne suis pas vraiment convaincu par l'œil nu, les culottes courtes, les dictionnaires au bifidus et autres Wiki-là-pedro comme je te pousse à peine orientés, les arguments marketings ou la vision de mon arrière-grand-mère astronome-exploratrice dans sa cuisine (néanmoins sympathique).


Si je peux me permettre un petit rappel sur le vocable en (soumis à la) question sans forcément vous offusquer ou être stigmatisé théoricien (à la manière des intellectuels russes ou chinois ou… qu'il faut isoler et ré-éduquer pour la salubrité du plus grand nombre):
En informatique (si celui-ci signifie vraiment encore quelque chose tellement il est flou) et historiquement, le mot langage vient de l'anglais language (merci rémi quel puits de science) et se trouve être une adaptation très malheureuse car nos amis anglophones ne goutent pas vraiment la sensibilité française et l'opposition langue/langage système/fonction que nous assumons parfaitement.
Langue voir code serait une adaptation plus pertinente (nous sommes sur un forum francophone si ne m'abuse).
Le problème dégénère encore lorsque le contraste Natural/language Machine language c'est répandu comme la réponse "French Horn" à "Cors anglé" (à cause de l'angle formé par l'anche et non pas cors anglais évidemment !).
Nous n'utilisons pas le terme langue machine pour des raisons évidentes liées au contexte homme/machine, aux types de rapports qui peuvent les unire et qui sont, pour le moment, du domaine de la commande et non de la communication historique ou affective (personne dans la conception d'une IHM ne parle de langue interface ou de gestuelle linguistique, ouf… merci !).

Reste donc, code.

Je suis donc obligé de constater qu'un codeur produit du code et qu'un programmeur produit, in-fine via compilation, du code.
Ce code peut donc être transcoder sans être interprété ou traduit.
Dans le cas des High Level Languages il est nécessaire de passer par plusieurs étapes de mises en formes, de liaisons et d'interprétations (voir d'optimisations mécaniques (mécanismes)) pour pouvoir générer ce que le codeur produit directement.
C'est pour cette dernière raison que des outils comme MASM (qui sont en fait les compilateurs finaux de suites logiciels) ajoutent à la confusion ambiante en générant indirectement le code (ce qui est aisément vérifiable). Ceux-ci sont nommés un peu abusivement assembleurs (vaste débat).

Tout-çà pour signifier que les choses ne sont pas si simplistes, que ce soit à l'œil nu aussi bien qu'en culotte-courtes d'ailleurs, et ce quelle que soit l'antériorité méthushélienne voir antédiluvienne de vos artères.

[EDIT:]

Que l'auteur me pardonne mais son propos (plus bas) est toujours de mise

Je suis le premier à être choqué qu'on adule autant les compilateurs de nos jours, mais je dois reconnaître que niveau troll là tu t'es lâché.
Ce ne serait pas une bonne idée de verrouiller ce topic avant qu'on atteigne le point Godwin ?

Faute de bois le feu s'éteint...

[souviron34]

puisqu'il est de bon ton de considérer tout ce qui a plus de 30 ans comme un dinosaure et que visiblement nous descendons ici à un niveau de sémantique qui dépasse mes pauvres capacités, j'aimerais connaître simplement pourquoi un ensemble d'instructions cité plus haut :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
MOV EAX,1
ADD EBX,EAX

peut marcher sur un PDP 11/23 en 1987, sur un PC avec Windows 3.1, sur une EEPROM de 2009, sans que cela soit un langage....



maintenant c'est vrai que je ne sais pas ce que signifie HLL ou autres sigles, donc je ne suis qu'un ignare obtus et simpliste...