Auparavant, il y avait de très bonnes raisons de garder les noms d'instructions / registres brefs. Ces raisons ne s'appliquent plus, mais les noms cryptés courts sont encore très courants dans la programmation de bas niveau.

Pourquoi est-ce? Est-ce simplement parce que les vieilles habitudes sont difficiles à briser ou y a-t-il de meilleures raisons?

Par exemple:

• Atmel ATMEGA32U2 (2010?): TIFR1(Au lieu de TimerCounter1InterruptFlag), ICR1H(au lieu de InputCapture1High), DDRB(au lieu de DataDirectionPortB), etc.
• Jeu d'instructions .NET CLR (2002): bge.s(au lieu de branch-if-greater-or-equal.short), etc.

Les noms non cryptés, plus longs, ne sont-ils pas plus faciles à utiliser?

Lorsque vous répondez et votez, veuillez considérer les points suivants. Bon nombre des explications possibles suggérées ici s'appliquent également à la programmation de haut niveau, mais le consensus est généralement d'utiliser des noms non cryptés consistant en un mot ou deux (à l'exclusion des acronymes couramment compris).

En outre, si votre argument principal concerne l'espace physique sur un diagramme en papier , sachez que cela ne s'applique absolument pas au langage d'assemblage ni au langage CIL. De plus, j'apprécierais que vous me montriez un diagramme dans lequel les noms abrégés sont lisibles mais lisibles qui aggravent le diagramme. . D'après une expérience personnelle acquise dans une société de semi-conducteurs sans usine, les noms lisibles conviennent parfaitement et donnent des diagrammes plus lisibles.

Quelle est la chose principale qui est différent au sujet de la programmation de bas niveau , par opposition aux langages de haut niveau qui rend les noms énigmatiques laconiques souhaitables à faible niveau , mais pas de programmation de haut niveau?

La raison pour laquelle le logiciel utilise ces noms est que les feuilles de données utilisent ces noms. Comme le code à ce niveau est très difficile à comprendre sans la feuille de données, créer des noms de variables que vous ne pouvez pas rechercher est extrêmement inutile.

Cela soulève la question de savoir pourquoi les feuilles de données utilisent des noms abrégés. C'est probablement parce que vous avez souvent besoin de présenter les noms dans des tableaux comme celui-ci où vous n'avez pas de place pour les identifiants à 25 caractères:

En outre, des éléments tels que les schémas, les diagrammes d'épingles et les sérigraphies pour cartes de circuits imprimés sont souvent très exigus.

Loi de Zipf

Vous pouvez constater vous-même, en consultant ce texte, que la longueur des mots et la fréquence d'utilisation sont généralement inversement liées. Les mots qui sont très souvent utilisés, comme it, a, but, you, et andsont très courts, alors que les mots qui sont moins souvent utilisés comme des observe, comprehensionet verbositysont plus longs. Cette relation observée entre fréquence et longueur est appelée loi de Zipf .

Le nombre d'instructions dans le jeu d'instructions pour un microprocesseur donné se chiffre généralement par dizaines ou par centaines. Par exemple, le jeu d'instructions Atmel AVR semble contenir une centaine d'instructions distinctes (je n'ai pas compté), mais bon nombre d'entre elles sont des variantes d'un thème commun et ont des mnémoniques très similaires. Par exemple, les instructions de multiplication incluent MUL, MULS, MULSU, FMUL, FMULS et FMULSU. Vous n'avez pas à regarder la liste des instructions très longtemps avant de vous faire une idée générale que les instructions commençant par "BR" sont des branches, les instructions commençant par "LD" sont des charges, etc. Il en va de même pour les variables: Même les processeurs complexes n'offrent qu'un nombre limité d'emplacements pour stocker des valeurs: registres de conditions, registres à usage général, etc.

Comme il y a si peu d'instructions et que les noms longs prennent plus de temps, il est logique de leur donner des noms courts. En revanche, les langages de niveau supérieur permettent aux programmeurs de créer un grand nombre de fonctions, méthodes, classes, variables, etc. Chacune d'entre elles sera utilisée beaucoup moins fréquemment que la plupart des instructions d'assemblage, et des noms plus longs et plus descriptifs sont de plus en plus importants pour donner aux lecteurs (et aux auteurs) suffisamment d'informations pour comprendre ce qu'ils sont et ce qu'ils font.

De plus, les jeux d'instructions de différents processeurs utilisent souvent des noms similaires pour des opérations similaires. La plupart des jeux d'instructions comprennent des opérations pour ADD, MUL, SUB, LD, ST, BR, NOP, et s'ils n'utilisent pas ces noms exacts, ils utilisent généralement des noms très proches. Une fois que vous avez appris les mnémoniques pour un jeu d'instructions, il ne faut pas longtemps pour s'adapter aux jeux d'instructions d'autres périphériques. Ainsi , les noms qui pourraient sembler « cryptique » vous sont à peu près aussi familiers que des mots tels que and, oret notpour les programmeurs qui sont qualifiés dans l'art de la programmation de bas niveau. Je pense que la plupart des personnes travaillant au niveau des assemblées vous diraient qu'apprendre à lire le code n'est pas l'un des plus grands défis de la programmation de bas niveau.

En général

La qualité des noms ne consiste pas uniquement à avoir des noms descriptifs, elle doit également prendre en compte d'autres aspects, ce qui conduit à des recommandations telles que:

• plus la portée est globale, plus le nom doit être descriptif
• plus il est utilisé souvent, plus le nom doit être court
• le même nom doit être utilisé dans tous les contextes pour la même chose
• des choses différentes devraient avoir des noms différents même si le contexte est différent
• les variations doivent être facilement détectées
• ...

Notez que ces recommandations sont en conflit.

Mnémotechnique

En tant que programmeur en langage assembleur, utiliser short-branch-if-greater-or-equalpour bge.sme donne la même impression que lorsque je vois, en tant que programmeur Algol qui effectue la géométrie informatique SUBSTRACT THE-HORIZONTAL-COORDINATE-OF-THE-FIRST-POINT TO THE-HORIZONTAL-COORDINATE-OF-THE-SECOND-POINT GIVING THE-DIFFERENCES-OF-THE-COORDINATE-OF-THE-TWO-POINTSau lieu de dx := p2.x - p1.x. Je ne peux tout simplement pas admettre que les premiers sont plus lisibles dans les contextes qui me sont chers.

Enregistrer les noms

Vous choisissez le nom officiel dans la documentation. La documentation sélectionne le nom de la conception. La conception utilise de nombreux formats graphiques où les noms longs ne sont pas adéquats et l'équipe de conception utilisera ces noms pendant des mois, voire des années. Pour les deux raisons, ils n'utiliseront pas le "drapeau d'interruption du premier compteur", ils l'abrègeront dans leur schéma ainsi que lorsqu'ils parleront. Ils le savent et utilisent des abréviations systématiques, par exemple TIFR1pour réduire les risques de confusion. Un point ici est que ce TIFR1n'est pas une abréviation aléatoire, c'est le résultat d'un schéma de nommage.

Hormis les "vieilles habitudes", le code Legacy, écrit il y a 30 ans et toujours utilisé, est très courant. Malgré ce que pensent certaines personnes moins expérimentées, refactoriser ces systèmes pour les rendre jolis coûte très cher pour un petit gain et n’est pas viable commercialement.

Les systèmes embarqués proches du matériel - et accédant aux registres, ont tendance à utiliser des étiquettes identiques ou similaires à celles utilisées dans les fiches techniques du matériel, pour de très bonnes raisons. Si le registre s'appelle XYZZY1 dans les feuilles de données matérielles, il est logique que la variable qui la représente soit probablement XYZZY1, ou si le programmeur passait une bonne journée, RegXYZZY1.

En ce qui concerne le bge.s, cela ressemble à l'assembleur - les quelques personnes qui ont besoin de le savoir plus longtemps sont moins lisibles. Si vous ne parvenez pas à vous concentrer bge.set à penser que branch-if-greater-or-equal.shortcela fera une différence - vous ne faites que jouer avec le CLR sans le savoir.

L’autre raison pour laquelle vous verrez des noms de variable courts est due au fait que les abréviations sont très répandues dans le domaine ciblé par le logiciel.

En résumé, des noms de variable abrégés qui reflètent une influence externe, tels que les normes de l'industrie et les fiches techniques matérielles, sont attendus. Les noms abrégés de variables internes au logiciel sont généralement moins souhaitables.

Il y a tellement d'idées différentes ici. Je ne peux accepter aucune des réponses existantes comme la réponse: d'une part, il existe probablement des facteurs qui contribuent à beaucoup cela, et d' autre part, je ne peux pas connaître peut - être que l' on est le plus important.

Alors, voici un résumé des réponses postées par d’autres ici. Je poste ceci en tant que CW et mon intention est de marquer finalement que cela est accepté. Veuillez éditer si j'ai manqué quelque chose. J'ai essayé de reformuler chaque idée pour l'exprimer de manière concise mais claire.

Alors, pourquoi les identifiants courts cryptiques sont-ils si courants dans la programmation de bas niveau?

• Parce que beaucoup d'entre eux sont suffisamment communs dans le domaine respectif pour justifier un nom très court. Cela aggrave la courbe d'apprentissage, mais constitue un compromis intéressant compte tenu de la fréquence d'utilisation.
• Parce qu’il ya généralement un petit ensemble de possibilités qui est corrigé (le programmeur ne peut pas ajouter à l’ensemble).
• Parce que la lisibilité est une question d'habitude et de pratique. branch-if-greater-than-or-equal.shortest initialement plus lisible que bge.s, mais avec certaines pratiques, la situation est inversée.
• Parce qu'ils doivent souvent être tapés à la main, parce que les langages de bas niveau ne sont souvent pas accompagnés d'IDE puissants dotés d'une bonne complétion automatique, ou que la climatisation n'est pas fiable.
• Parce qu'il est parfois souhaitable de regrouper de nombreuses informations dans l'identifiant, et qu'un nom lisible aurait une longueur inacceptable, même selon des normes de haut niveau.
• Parce que c’est à cela que ressemblaient les environnements de bas niveau. Rompre l'habitude nécessite un effort conscient, risque d'ennuyer ceux qui ont aimé les anciennes méthodes et doit être justifiée. S'en tenir à la manière établie est le "défaut".
• Parce que beaucoup d'entre eux sont originaires d'autres sources, telles que les schémas et les feuilles de données. Ceux-ci, à leur tour, sont affectés par des contraintes d'espace.
• Parce que les personnes chargées de nommer les choses n’ont même jamais considéré la lisibilité, ou ne réalisent pas qu’elles créent un problème, ou sont paresseuses.
• Parce que dans certains cas, les noms sont devenus partie intégrante d’un protocole d’échange de données, tel que l’utilisation du langage assembleur en tant que représentation intermédiaire par certains compilateurs.
• Parce que ce style est immédiatement reconnaissable comme étant de bas niveau et qu’il a donc l’air cool pour les geeks.

Personnellement, j’ai le sentiment que certaines d’entre elles ne contribuent pas réellement aux raisons pour lesquelles un système nouvellement développé choisirait ce style de nommage, mais j’ai pensé qu’il serait faux de filtrer certaines idées dans ce type de réponse.

Je vais jeter mon chapeau dans ce bazar.

Les conventions et normes de codage de haut niveau ne sont pas identiques aux normes et pratiques de codage de bas niveau. Malheureusement, la plupart d'entre eux sont des restes de code hérité et de processus de pensée anciens.

Certains, cependant, servent un but. Bien sûr, BranchGreaterThan serait beaucoup plus lisible que BGT , mais il existe actuellement une convention, une instruction et, en tant que telle, a acquis un peu de traction au cours des 30 dernières années d’utilisation standard. Pourquoi ont-ils commencé avec cela, probablement une limite de largeur de caractère arbitraire pour les instructions, les variables et autres; pourquoi le garde-t-il, c'est une norme. Cette norme est la même chose que d'utiliser int comme identifiant, il serait plus lisible d'utiliser Integer dans tous les cas, mais est-il nécessaire pour ceux qui programment depuis plus de quelques semaines ... non. Pourquoi? Parce que c'est une pratique courante.

Deuxièmement, comme je l’ai dit dans mon commentaire, bon nombre des interruptions sont nommées INTG1 et d’autres noms cryptés, qui ont également une fonction. Dans les schémas de circuit, il n’est PAS bon convention de nommer vos lignes et cela pourrait encombrer verbalement le schéma et nuire à la lisibilité. Toute verbosité est traitée dans la documentation. Et comme tous les schémas de câblage / circuits ont ces noms abrégés pour les lignes d'interruption, les interruptions elles-mêmes ont également le même nom afin de préserver la cohérence du concepteur intégré depuis le schéma de circuit jusqu'au code pour le programmer.

Un concepteur a un certain contrôle sur cela, mais comme dans tout langage de champ / nouveau, des conventions suivent, matériel à matériel, et doivent donc rester identiques dans tous les langages d'assemblage. Je peux regarder un extrait d'assemblage et être capable de comprendre l'essentiel du code sans jamais utiliser ce jeu d'instructions, car il s'en tient à une convention, à une convention LDA ou à une relation qui le lie est probablement en train de charger un registre. MV déplace probablement quelque chose de quelque part vers ailleurs, il ne s'agit pas de ce que vous jugez bon ou de pratique de haut niveau, mais bien de la langue. En tant que tel, il a ses propres normes et signifie que vous, en tant que concepteur, devez les suivre. Elles ne sont souvent pas aussi arbitraires que ils semblent.

Je vous laisse avec ceci: Demander à la communauté intégrée d’utiliser des pratiques verbeuses de haut niveau revient à demander aux chimistes d’écrire en permanence des composés chimiques. Le chimiste les écrit brièvement pour eux-mêmes et tout le monde le comprendra, mais il faudra peut-être un peu de temps au nouveau venu pour s’adapter.

Une des raisons pour lesquelles ils utilisent des identificateurs courts cryptiques est qu’ils ne le sont pas pour les développeurs. Vous devez réaliser qu'ils travaillent avec cela tous les jours et que ces noms sont vraiment des noms de domaine. Donc, ils savent par cœur ce que TIFR1 signifie exactement.

Si un nouveau développeur arrive dans l'équipe, il devra lire les fiches techniques (comme l'explique @KarlBielefeldt) pour se familiariser avec celles-ci.

Je pense que votre question utilise un mauvais exemple car en effet, sur ce type de code source, vous voyez généralement de nombreux identifiants de cryptage inutiles pour des éléments ne relevant pas du domaine.

Je dirais surtout qu'ils le font en raison de mauvaises habitudes qui existaient lorsque les compilateurs ne complétaient pas automatiquement tout ce que vous tapez.

Sommaire

L'initialisme est un phénomène omniprésent dans de nombreux cercles techniques et non techniques. En tant que tel, il ne se limite pas à la programmation de bas niveau. Pour la discussion générale, voir l'article de Wikipedia sur Acronym . Ma réponse est spécifique à la programmation de bas niveau.

Causes des noms cryptiques:

1. Les instructions de bas niveau sont fortement typées
2. Nécessité d'intégrer beaucoup d'informations de type dans le nom d'une instruction de bas niveau
3. Historiquement, les codes à caractère unique sont privilégiés pour la saisie des informations de type.

Les solutions et leurs inconvénients:

1. Il existe des schémas de nommage de bas niveau modernes qui sont plus cohérents que les historiques.
   • LLVM
2. Cependant, la nécessité de rassembler beaucoup d'informations de type existe toujours.
   • Ainsi, les abréviations cryptiques peuvent encore être trouvées partout.
3. Une lisibilité améliorée de ligne à ligne aidera un programmeur débutant novice à maîtriser la langue plus rapidement, mais ne facilitera pas la compréhension de gros morceaux de code de bas niveau.

Réponse complète

(A) Des noms plus longs sont possibles. Par exemple, les noms des éléments intrinsèques C ++ SSE2 comportent en moyenne 12 caractères, par rapport aux 7 caractères du mnémonique d’assemblage. http://msdn.microsoft.com/en-us/library/c8c5hx3b(v=vs.80).aspx

(B) La question passe ensuite à la question suivante: Combien de temps doit-on obtenir sans instructions cryptées à partir d'instructions de bas niveau?

(C) Nous analysons maintenant la composition de tels schémas de nommage. Voici deux schémas de nommage pour la même instruction de bas niveau:

• Schéma de nommage n ° 1: CVTSI2SD
• Schéma de nommage n ° 2: __m128d _mm_cvtsi32_sd (__m128d a, int b);

(C.1) Les instructions de bas niveau sont toujours fortement typées. Il ne peut y avoir d'ambiguïté, d'inférence de type, de conversion de type automatique ou de surcharge (réutilisation du nom de l'instruction pour désigner des opérations similaires mais non équivalentes).

(C.2) Chaque instruction de bas niveau doit coder un grand nombre d'informations de type dans son nom. Exemples d'informations:

• Famille d'architecture
• Opération
• Arguments (entrées) et sorties
• Types (Entier Signé, Entier Non Signé, Flottant)
• Précision (largeur de bit)

(C.3) Si chaque information est épelée, le programme sera plus détaillé.

(C.4) Les schémas de codage de type utilisés par divers fournisseurs avaient de longues racines historiques. Par exemple, dans le jeu d'instructions x86:

• B signifie octet (8 bits)
• W signifie mot (16 bits)
• D signifie dword "double-mot" (32 bits)
• Q signifie qword "quad-word" (64 bits)
• DQ signifie dqword "double-quad-word" (128 bits)

Ces références historiques n’avaient aucune signification moderne, mais restaient toujours présentes. Un schéma plus cohérent aurait mis la valeur de la largeur de bit (8, 16, 32, 64, 128) dans le nom.

Au contraire, LLVM est un pas en avant dans la direction de la cohérence des instructions de bas niveau: http://llvm.org/docs/LangRef.html#functions

(D) Indépendamment du schéma de nommage des instructions, les programmes de bas niveau sont déjà verbeux et difficiles à comprendre car ils se concentrent sur les moindres détails de l'exécution. Changer le schéma de nommage des instructions améliorera la lisibilité ligne par ligne, mais n'éliminera pas la difficulté de comprendre les opérations d'un gros morceau de code.

Les humains ne lisent et n'écrivent des assemblages qu'occasionnellement, et il ne s'agit généralement que d'un protocole de communication. C'est-à-dire qu'il est le plus souvent utilisé comme une représentation textuelle intermédiaire sérialisée entre le compilateur et l'assembleur. Plus cette représentation est détaillée, plus le protocole est inutile.

Dans le cas des opcodes et des noms de registre, les noms longs nuisent à la lisibilité. Les mnémoniques courts sont préférables pour un protocole de communication (entre compilateur et assember), et le langage assembleur est la plupart du temps un protocole de communication. Les mnémoniques courts conviennent mieux aux programmeurs, car le code du compilateur est plus facile à lire.

Surtout c'est idiomatique. Comme @TMN le dit ailleurs, tout comme vous n'écrivez pas import JavaScriptObjectNotationou import HypertextTransferProtocolLibraryen Python, vous n'écrivez pas Timer1LowerHalf = 0xFFFFen C. Cela semble tout aussi ridicule dans son contexte. Tous ceux qui ont besoin de savoir le savent déjà.

La résistance au changement peut provenir en partie du fait que certains éditeurs de compilateurs C pour systèmes intégrés s’écartent de la syntaxe et des normes de langage afin d’implémenter des fonctionnalités plus utiles à la programmation intégrée. Cela signifie que vous ne pouvez pas toujours utiliser la fonctionnalité de saisie semi-automatique de votre éditeur de texte ou IDE préféré lors de l'écriture de code de bas niveau, car ces personnalisations empêchent toute analyse du code. D'où l'utilité des noms de registres courts, des macros et des constantes.

Par exemple, le compilateur C de HiTech incluait une syntaxe spéciale pour les variables qui devaient avoir une position spécifiée par l'utilisateur en mémoire. Vous pourriez déclarer:

volatile char MAGIC_REGISTER @ 0x7FFFABCD;

À présent, le seul IDE existant qui va analyser ceci est le propre IDE de HiTech ( HiTide ). Dans tout autre éditeur, vous devrez le saisir manuellement, à partir de la mémoire, à chaque fois. Cela vieillit très vite.

De plus, lorsque vous utilisez des outils de développement pour inspecter les registres, vous obtenez souvent un tableau avec plusieurs colonnes (nom du registre, valeur en hexadécimal, valeur en binaire, dernière valeur en hexadécimale, etc.). Les noms longs signifient que vous devez étendre la colonne de noms à 13 caractères pour voir la différence entre deux registres et jouer à "repérer la différence" sur des dizaines de lignes de mots répétés.

Cela peut sembler ridicule, mais toutes les conventions de codage ont-elles pour but de réduire la fatigue oculaire, les saisies superflues ou d’aborder toutes les autres petites plaintes?

Je suis surpris que personne n'ait mentionné la paresse et que d'autres sciences ne soient pas abordées. Mon travail quotidien en tant que programmeur me montre que les conventions de dénomination pour tout type de variable dans un programme sont influencées par trois aspects différents:

1. Le fond scientifique du programmeur.
2. Les compétences de programmation du programmeur.
3. L'environnement du programmeur.

Je pense qu'il est inutile de discuter de programmation de bas niveau ou de haut niveau. À la fin, il peut toujours être épinglé aux trois premiers aspects.

Une explication du premier aspect: beaucoup de "programmeurs" ne sont pas des programmeurs en premier lieu. Ils sont mathématiciens, physiciens, biologistes ou même psychologues ou économistes, mais nombre d'entre eux ne sont pas des informaticiens. La plupart d’entre eux ont leurs propres mots-clés et abréviations spécifiques à un domaine que vous pouvez voir dans leurs "conventions" de dénomination. Ils sont souvent piégés dans leur domaine et utilisent les abréviations connues sans se soucier de la lisibilité ni des guides de codage.

Une explication du deuxième aspect: la plupart des programmeurs n’étant pas des informaticiens, leurs compétences en programmation sont limitées. C’est pourquoi ils se moquent bien souvent des conventions de codage mais plus des conventions propres à un domaine, comme indiqué en premier. De plus, si vous ne possédez pas les compétences d'un programmeur, vous ne comprenez pas les conventions de codage. Je pense que la plupart d'entre eux ne voient pas le besoin urgent d'écrire un code compréhensible. C'est comme le feu et oublier.

Une explication du troisième aspect: Il est peu probable que vous respectiez les conventions de votre environnement qui peuvent être des codes anciens que vous devez supporter, des normes de codage de votre société (gérées par des économistes peu soucieux du codage) ou du domaine auquel vous appartenez. Si quelqu'un a commencé à utiliser des noms cryptés et que vous devez le prendre en charge, il est peu probable que vous changiez les noms cryptés. S'il n'y a pas de normes de codage dans votre entreprise, je parie que presque tous les programmeurs écriront leurs propres normes. Enfin, si vous êtes entouré d’utilisateurs du domaine, vous ne commencerez pas à écrire une langue différente de celle qu’ils utilisent.