L'assemblage est-il toujours pertinent? [fermé]

Existe-t-il des différences majeures entre le langage d'assemblage et les langages de niveau supérieur en ce qui concerne le codage et / ou la gestion de projets? De toute évidence, il faut plus d'instructions en langage assembleur pour effectuer une opération particulière que dans la plupart des autres langages, mais y a-t-il des différences qui affectent la façon dont un projet doit (ou devrait) être exécuté en fonction du ciblage du langage assembleur (spécifiquement le langage assembleur x86 / x64) ?

Dans la mesure où il existe des différences entre le langage d'assemblage et d'autres langages, il semble raisonnable de deviner qu'au moins certains d'entre eux sont des avantages pour les autres langages. Quelqu'un peut-il signaler les inconvénients spécifiques du langage d'assemblage et les moyens d'atténuer ces inconvénients?

Un exemple spécifique serait la disponibilité du personnel. Quelqu'un a-t-il eu du mal à trouver des programmeurs en langage assembleur expérimentés, et si oui, quelles mesures peuvent être prises pour atténuer ce problème?

Oui - mais pas souvent.

Dans un sens, l'assemblage n'est vraiment qu'un proxy pour le langage machine, vous pouvez donc bien sûr faire tout ce que vous pourriez faire avec un langage de niveau supérieur.

L'inverse n'est pas toujours le cas. Par exemple, il y a quelques années, j'ai travaillé sur un processeur ARM qui avait des opcodes funky pour changer les états graphiques qui ne pouvaient être utilisés qu'en mode noyau. Ils n'auraient pas d'équivalent direct dans un langage de niveau supérieur, et je suis sûr que la fonction dans le pilote du noyau Linux pour changer ces états incluait un assemblage.

Sur les microprocesseurs des années 80 et du début du milieu des années 90, si vous aviez du code dont vous aviez besoin pour exécuter très rapidement, vous l'écririez souvent en assembleur, car un humain qualifié pourrait facilement écrire un assemblage plus optimisé que la plupart des C les compilateurs pourraient générer. Certains des premiers programmes Mac ont été entièrement écrits en assembleur, et ils étaient étonnamment rapides pour l'époque. Même sans écrire tout le programme dans l'assemblage, j'ai certainement fait ma part d'optimisation des boucles internes en C via l'assemblage intégré.

Mais les choses ont commencé à changer au milieu des années 90. Les processeurs ont commencé à inclure des fonctionnalités telles que le pipelining et la prédiction de branche, de sorte que l'ordre des instructions le plus efficace n'était pas toujours évident pour un humain. Pire que cela, la commande la plus efficace variait parmi les processeurs de la même famille; par exemple, les compilateurs PowerPC offraient généralement des commutateurs cibles pour les séries G3, G4 et G5. Le même code objet s'exécuterait sur chacun d'eux, mais il s'exécuterait plus efficacement sur l'une de ces séries.

Depuis lors, l'ordre des instructions est devenu de plus en plus compliqué, en particulier sur les CPU plus complexes sur le plan architectural comme x86, PowerPC et SPARC. (Je crois que ARM est toujours assez simple de cette façon.) Un autre facteur important est la taille du code - le code qui utilise plus de cycles CPU mais peut rester dans le cache CPU s'exécute souvent beaucoup plus rapidement que le code qui utilise moins de cycles CPU mais déclenche des récupérations de mémoire lentes . Les principaux compilateurs modernes peuvent faire un bien meilleur travail d'optimisation de code sur ces processeurs qu'un humain ne peut raisonnablement le faire.

Je n'ai pas trouvé de bonne raison d'écrire l'assemblage depuis au moins 15 ans. Je pense qu'en 2011, les principales utilisations de l'assemblage seraient:

• Pour lire les vidages de démontage lors du débogage, ce que je fais parfois même aujourd'hui.
• Traiter des fonctionnalités CPU non standard, comme ce mode graphique funky.
• Écriture du compilateur - il fournit un format intermédiaire lisible par l'homme pour traduire des langues de niveau supérieur en.

Essayez de programmer un microcontrôleur pour un "petit embarqué" - une télécommande d'alarme de voiture, un moniteur de batterie de téléphone, un contrôleur de clavier, un régulateur de vitesse de ventilateur, sans utiliser d'assemblage.

Pendant que la frontière bouge, il y a toujours de la place pour l'assemblage.

Il y a 15 ans, votre compteur kilométrique de vélo était mécanique, un four à micro-ondes était en circuits analogiques, la télécommande du téléviseur était en circuits numériques, le tuner TV Sat était écrit en assembleur, un firmware du téléphone était en C et une applet d'ordinateur était en Java.

Il y a 7 ans, un four à micro-ondes était dans un circuit numérique, une télécommande de télévision a été écrite en assemblage, un décodeur TV a été écrit en C, votre téléphone a exécuté une interface utilisateur basée sur Java.

De nos jours, un compteur kilométrique de vélo est en circuit numérique, un four à micro-ondes obtient un micrologiciel en assemblage, une télécommande de télévision a un micrologiciel en C, un décodeur TV fonctionne en Java, votre téléphone a Linux.

Tu veux parier les 7 prochaines années? Au fur et à mesure que de plus en plus de technologies obtiennent des langages de contrôle plus avancés, l'assemblage gagne de nouvelles bases et continuera de les obtenir. Regardez ce qui se fait aujourd'hui avec les circuits mécaniques ou analogiques. Vous pouvez parier l'assemblage là-bas dans quelques années. Votre interrupteur d'éclairage? Votre robinet d'eau? Votre bouilloire? Votre brosse à dents?

Il y aura toujours un nouvel appareil, appareil, jouet, article de vie commune à programmer en assemblage.

Je base cela principalement sur les assembleurs que j'ai utilisés - principalement MASM, NASM et (dans une moindre mesure) TASM. Certaines des versions ultérieures de TASM avaient (ont?) Des fonctionnalités pour prendre en charge OO, mais je ne les ai pas beaucoup utilisées et je n'essaie pas de les commenter.

Premièrement: la plupart des langues ont évolué vers une structure qui est au moins un peu comme un arbre. Qu'il soit orienté objet, ou basé sur un objet, ou exactement quoi, il y a beaucoup de choses définies sur les relations entre les différentes parties d'un système. Il y a aussi beaucoup de choses à "protéger" une partie d'un système contre les "interférences" accidentelles, mais d'autres parties (même si la protection peut généralement être contournée si vous le souhaitez). En revanche, le langage d'assemblage est relativement "plat" - la plupart des relations entre le code (et les données) dans différentes parties du système sont établies principalement par la documentation et, dans une moindre mesure, par les conventions de dénomination.

Le résultat de cela est qu'il est souvent beaucoup plus facile de coupler le code beaucoup plus étroitement que ce ne serait idéal. Les exigences qui ont motivé le choix du langage d'assemblage pour commencer (performances plus élevées, taille plus petite, etc.) récompensent souvent cela également - en contournant les interfaces approuvées et ainsi vous pouvez souvent obtenir du code plus petit et plus rapide (mais généralement pas beaucoup) mieux dans toutes les dimensions). Le langage et les outils eux-mêmes font beaucoup moins pour restreindre ce que vous faites (bon ou mauvais), ce qui impose une charge beaucoup plus lourde aux gestionnaires pour éviter les problèmes. Je ne dirais pas que c'est qualitativement différent, mais quantitativement - c'est-à-dire que la direction doit travailler pour éviter les problèmes de toute façon, mais dans le cas du langage d'assemblage, il faut généralement des directives plus (et souvent plus strictes) sur ce qui est ou ce qui ne l'est pas '' t acceptable.

L'atténuation de ces problèmes est en grande partie une question de directives plus rigoureuses, davantage de conseils de la part d'un personnel plus expérimenté et de conventions de dénomination plus spécifiques et soigneusement appliquées.

La dotation est un problème. Les problèmes que j'ai rencontrés, cependant, n'étaient pas principalement ceux auxquels je m'attendais. Trouver des gars avec un peu de personnalité "fighter jock" qui étaient heureux de sauter dans le code du langage d'assemblage était assez facile. La plupart ont fait un travail assez raisonnable, malgré un manque presque total d'expérience préalable dans l'utilisation du langage d'assemblage.

La difficulté que j'ai rencontrée a été de trouver plus de cadres supérieurs - des gens qui pouvaient garder le projet sous au moins un semblant de contrôle, et n'étaient pas complètement habitués aux langues qui fourniraient (et appliqueraient en grande partie) les directives nécessaires pour garder le code raisonnablement maintenable et compréhensible.

Avec le recul, j'ai peut-être été / causé certains des plus gros problèmes à cet égard. Je peux voir deux sources de problèmes de ma part. Tout d'abord, au moment du projet auquel je pense, j'avais codé principalement dans des langages de niveau supérieur pendant un bon moment, et en utilisant uniquement le langage d'assemblageen dernier recours. En tant que tel, lorsque je l'ai utilisé, presque toutes les astuces possibles pour gagner en performance n'étaient pas seulement un jeu équitable, mais attendu. Deuxièmement, à l'époque où j'avais travaillé sur certains systèmes écrits entièrement (ou principalement) en langage assembleur, c'était sous la direction de chefs de projet plutôt ironiques. À l'époque, j'étais relativement jeune et je regrettais franchement la façon dont ils géraient les choses, alors j'avais tendance à faire le contraire. Rétrospectivement, ce qu'ils faisaient était vraiment important, et pas seulement parce qu'ils étaient vieux et inflexibles (ce qui, je suis à peu près sûr, c'était comment je voyais les choses à l'époque).

à mon avis, l'assemblage en tant que plate-forme de développement peut ne pas être pertinent pour un usage quotidien. la principale raison de cette opinion peut être parce que la quantité de puissance de calcul qui est retirée d'un processus donné par rapport à la quantité de temps de développement nécessaire pour optimiser le même processus donné ne vaut généralement pas le temps et l'énergie (il existe un terme spécifique pour cela .. ça sonne comme homme / heure ou quelque chose .. veuillez éditer si vous savez de quoi je parle ..) il y a les exceptions évidentes mentionnées ci-dessus mais en ce qui concerne la programmation grand public, l'assemblage n'est pas souvent utilisé.

cela étant dit, l'assemblage est toujours pertinent aujourd'hui lors de l'apprentissage de la programmation dans le contexte des études de génie logiciel, il enseigne à quoi ressemble un langage de programmation de bas niveau et se comporte. je vais continuer et donner l'exemple de ce que nous utilisons en classe ces jours-ci. nous utilisons l'assemblage pep / 8 développé par Stanley Warford (Pepperdine University USA) et son logiciel open source donné ici . principalement utilisé car il virtualise le processeur et affiche le contenu de la mémoire tout en parcourant le code pendant son exécution (très utile pour l'apprentissage, le débogage).

Donc, selon votre utilisation, l'assemblage peut ou non être pertinent à mon avis.

Je pense que vous demandez "les camions sont-ils toujours pertinents si nous avons des voitures?". Je veux dire, l'assemblage a une très large gamme d'applications mais pas aussi large que la programmation de haut niveau, de la même manière qu'il y a beaucoup moins de camions que de voitures.

Dans des domaines comme l'optimisation des algorithmes, vous pouvez utiliser directement les registres du processeur pour améliorer les algorithmes de traitement d'images / vidéo.

Dans des domaines comme la cryptographie, vous pouvez l'utiliser de la même manière.

Dans les nouveaux processeurs avec de nouvelles architectures (souvenez-vous de la date de sortie du microprocesseur Cell), ils devaient certainement écrire des chargeurs de démarrage et ainsi de suite dans l'assemblage (et avec les anciens processeurs aussi, mais les processeurs utilisés depuis longtemps ont une masse très stable et sont difficiles à améliorer) il).

Et bien d'autres exemples pourraient être donnés, cela dépend donc du domaine dans lequel votre entreprise se concentre, si votre entreprise se consacre au développement Web / mobile, il est très probable que vous n'en ayez pas besoin, mais si votre entreprise se concentre sur les microcontrôleurs, systèmes embarqués, etc. est très probable que vous en avez besoin.

Et la disponibilité du personnel, cela dépend, je suppose que si vous demandez à Intel, Qualcomm, ... ils doivent avoir une grande liste de programmeurs d'assemblage (c'est comme si vous demandez à votre lieu de travail "combien de chauffeurs de camion sont ici?" I ne pensez pas beaucoup, mais cela ne veut pas dire qu'il n'y en a pas ailleurs.

Si vous voulez vraiment savoir pourquoi l'apprentissage de l'assemblage est le meilleur choix. Voici les raisons.

1. Pas besoin d'apprendre l'assemblage, si vous allez faire de la programmation sur Visual Basic et ce truc MS.
2. Pas besoin d'apprendre l'assemblage, si vous n'avez pas à faire de gadgets de microcontrôleur sérieux.
3. Pas besoin d'apprendre l'assemblage, si vous avez un espace mémoire à votre disposition tout en travaillant sur le microcontrôleur (Dieu vous aide en interfaçant la mémoire avec le microcontrôleur)
4. Pas besoin d'apprendre l'assemblage, si vous ne voulez pas que Dieu aime l'alimentation de votre microcontrôleur / microprocesseur.
5. Ne pas connaître l'assemblage, c'est comme connaître l'iceberg. Vous pouvez voir 25% de ce que vous et vos capacités de micros et 75% vous ne saurez jamais ou comprendre
6. Essayez d'exécuter Kolibris OS complètement écrit dans Assembly !!! Avez-vous vu un système d'exploitation qui démarre en moins de 5 secondes et l'application démarre avec 1 seconde de clic de souris.
7. Les compilateurs modernes ont des fonctions générales dans le backend et donc le code final généré serait lourd comparé à Assembly.

L'assemblage est comme la Natasha Romanoff des Avengers. C'est un charme et une magie. Tout d'abord, il vous mordra mais croyez-moi, vous n'oublierez jamais le goût.