Pourquoi écrire en Assembleur?

Utiliser l'assembleur comme langage de programmation n'est pas si populaire de nos jours. Comme si c'était une règle les gens préfèrent utiliser des langages de troisième (3GL) ou quatrième génération (4GL).

D'habitude - pour des applications simples - ceci est absolument vrai. Il y a cependant des situations où il est prudent de peser tous les arguments pour et contre l'utilisation de l'assembleur.

D'un côté il y a les arguments contre l'utilisation de l'assembleur en large partie basés sur des préjugés, et de l'autre côté il y a les arguments pour l'utilisation de l'assembleur comme langage relativement inconnu. Quand vous vous basez sur les préjugés de l'assembleur sans connaître les avantages, il devient très difficile de prendre des décisions objectives concernant le choix de ce langage de programmation.

Une règle reste importante comme c'est le cas pour tout les langages de programmation: sans personnel bien entraîné vous ne pourrez jamais aboutir, sans bonne documentation vous finirez par faire n'importe quoi.

Ci-dessous vous trouverez une vue d'ensemble des plus importants avantages de l'assembleur. Ensuite nous essayerons de réévaluer les préjugés. Nous terminerons par un petit résumé.

Les avantages de l'assembleur.

Travailler avec l'assembleur vous offre une palette de possibilités, qui ne sont pas (toutes) disponibles avec les langages 3GL et 4GL.

• Les erreurs corrigeables.
  Combien de fois arrive-t-il à votre application de tomber en panne si facilement? Un abend S0C7 parce qu'il y a des blancs, où on attendait des zéros? Un fichier intermédiaire qui était alloué juste un peu trop court? Avec l'aide d'une routine assembleur relativement assez simple ces problèmes peuvent être évités et résolus. Votre application ne tombera plus en panne, elle continuera juste à tourner. Tous les problèmes rencontrés sont reportés soit dans le joblog ou dans un log séparé, laissant la possibilité au contrôleur des commandes de faire les actions nécessaires.
• Utilisation de la mémoire au-dessus des 16MB.
  Il y a encore des entreprises qui sont obligées de compiler avec Amode=24. En ajoutant de simples modules en assembleur vous pouvez avoir votre application qui tourne au-dessus des 16MB, réduisant les besoins de mémoire en dessous des 16MB où il en manque le plus facilement.
• Gestion dynamique de la mémoire.
  Les programmes qui maintiennent des données en tables ou listes, ne savent souvent pas à l'avance de quelle quantité de mémoire ces objets vont avoir besoin. En assembleur l'espace mémoire peut être alloué et désalloué dynamiquement, vous laissant agrandir ou diminuer votre espace mémoire.
• Optimisation..
  Les derniers compilateurs génèrent un code très efficient. Mais ils ne peuvent cependant pas décider quels critères d'optimisation sont d'importance primordiale dans vos programmes spécifiques. Parce que le programmeur a la connaissance de la structure de votre application, il peut prendre cette décision. Il peut par exemple choisir de réduire le risque de page volée, rendant le programme plus rapide et réduisant la pagination du système.
• Utilisation des facilités du système d'exploitation. De tels services ne sont pas disponibles dans les langages de haut niveau ou, s'ils sont disponibles, la consommation supplémentaire induite par l'appel des langages de haut niveau à ces services dépasse largement les bénéfices de performance que l'on peut attendre.
  Parmi d'autres:
  • Data spaces.
    Les programmes qui ont besoin d'un espace de travail important pourraient bien utiliser les data spaces. Ceci réduit le besoin d'allouer des fichiers de travail (qui à son tour réduit les I/Os) et dans le même temps diminue les besoins dans votre espace mémoire, réduisant le risque de débordement.
  • Virtual look-aside facility.
    VLF vous donne la possibilité de garder vos données dans un espace mémoire virtuel, en dehors de votre espace mémoire, dans le cas d'utilisation importante les données qui peuvent être reconnues (par exemple: des membres de PDS de certaines librairies) ceci peut substantiellement réduire les temps d'I/O de votre application.
  • Accès concurrents sur plusieurs fichiers.
    Quand une application a besoin d'accéder à des enregistrements de deux fichiers ou plus, ces enregistrements peuvent être lus et/ou écrits en même temps. Il est même possible d'accéder à plusieurs enregistrements dans un même fichier en même temps. Cette concurrence peut faire gagner considérablement de temps d'attente sur les I/Os, spécialement quand les fichiers sont sur des volumes différents.
  • Sous-tâches.
    En découpant une tâche en sous-tâches, cette tâche peut tourner considérablement plus vite. Par exemple: en éliminant le besoin d'écrire des données sur un fichier de travail. Ou en laissant à une sous-tâche le soin de créer les enregistrements nécessaires à un journal financier, rendant la transaction des ventes plus rapide.
  • Réentrance.
    En rendant réentrant les segments de programmes très utilisés, ils peuvent être placés dans une mémoire commune (de préférence au dessus des 16MB bien sûr). Ceci veut dire que les programmes qui utilisent ce code peuvent être exécutés plus efficacement, parce que les chances d'une faute de page dans ce genre de code sont minimes.

Les préjugés contre l'assembleur.

Il y a plusieurs préjugés contre la programmation en assembleur. Les plus importants sont:

1. En assembleur la programmation structurée est impossible.
   Ceci est faux. Sur ce point l'assembleur offre actuellement plus de facilités que la plupart des 3GLs.
2. Maintenir les programmes en assembleur coûte beaucoup plus cher que les 3GLs.
   Quand les programmes de 3GLs ont été créés ceci était vrai! Depuis cette vérité est hautement discutable.
3. L'Assembleur est un langage où tout est permis, et difficile à apprendre.
   L'Assembleur est certainement un peu moins lisible au profane qu'un programme Cobol. D'autres langages comme C et C++ sont plus difficile à maîtriser.

Ad 1.

En assembleur la programmation structurée est impossible.
En amenant une structure dans les programmes c'est d'abord et surtout une question de style et de qualité. Si le langage de programmation utilisé offre de bonnes facilités, ce peut être une aide, mais pas plus que cela.

• Dans le monde des programmes la segmentation de l'assembleur offre plus de possibilités que les 3GLs: proche des sous-routines ou des fonctions il est aussi possible en assembleur de diviser les programmes en CSECTs, qui à leur tour peuvent être subdiviser en sous-routines et/ou fonctions.
  En plus de cela, on peut choisir diverses façons d'appeler ces routines. Parmi elles il y a l'appel standard MVS avec le registre 14, la pile de linkage ou les autres mécanismes d'appel, avec ou sans utilisation d'une table de branchement.
  Enfin, pour passer des paramètres, on peut choisir entre passer par valeur, passer par référence ou un mélange des deux.
• Quand on est concerné par des contrôles de boucles, l'assembleur offre des facilités comparables aux 3GLs: ce sont les branchements sur index et les branchements sur compteurs. Avec l'aide des macros ces facilités peuvent être étendues avec des instructions plus puissantes.
• Comme la plupart des 3GLs, l'assembleur permet de copier du code standard de librairies dans vos programmes.
• Pour finir l'utilisation des macros offre de larges possibilités pour structurer les programmes et pour standardiser les routines pendant l'écriture des programmes. En paramètrant l'assemblage il est possible en plus d'optimiser le code qui sera généré. La plupart des 3GLs n'offrent pas de fonctionnalités comparables.
   
  

Ad 2.

Maintenir les programmes en assembleur coûte beaucoup plus cher que les 3GLs.
Quand les 3GLs ont été lancés il y avait un grand nombre de programmes en assembleur. Parce que la programmation structurée était une nouvelle méthode, ces programmes ont perdu beaucoup d'intérêt. En assembleur - comme dans les autres langages - vous pouvez mettre une structure ou ne pas le faire. Avec toutes les conséquences habituelles pour leur maintenance.
En assembleur vous avez plus d'opportunités que dans les 3GLs pour faire n'importe quoi. Mais grâce aux macros, vous avez un nombre considérable d'options pour mettre une structure dans vos programmes, bien plus que dans d'en d'autres langages.
 
L'habileté à manier un langage est d'une importance primordiale. Un programmeur 3GL qui utilise aussi lassembleur ne peut jamais se mesurer à un professionnel de l'assembleur. Les effets sont mesurables non seulement en terme de temps nécessaire pour que le travail soit fait, mais aussi en terme de qualité du code produit. Le problème majeur, ensuite, est d'avoir des programmeurs expérimentés dans votre équipe. Un problème que vous rencontrerez quel que soit votre choix de langage de programmation, spécialement dans ces conditions.
 
Donc, si nous voulons faire une comparaison valable du personnel entre assembleur et 3GLs, nous devons comparer des hommes de métier avec des hommes de métier, et nous devons aussi prendre en compte la vieillesse des programmes (en terme de mesure de structure), ainsi que la qualité de la documentation disponible.
 
Notre expérience, pour les nouveaux programmes, montre que vous avez besoin de 10 à 20 pour cent de main d'œuvre en plus pour programmer en assembleur. Quand la maintenance est concernée, les différences sont trop dépendantes de la disponibilité de la documentation et de l'importance de la structure dans les programmes pour donner une estimation valable.
 
Un exemple: un de nos clients a un module assembleur, écrit par nous, et un module Cobol, les deux faisant exactement la même chose. Pour les dernières modifications le programmeur assembleur était prêt en un jour, alors que le programmeur Cobol avait besoin de trois jours. Bien que ceci semble exceptionnel, cela prouve que la maintenance de programmes assembleur n'est, par définition, pas plus coûteux que la maintenance des programmes 3GL.
 

Ad 3.

L'Assembleur est un langage difficile à apprendre.
Si vous dépendez de "profanes" vous ne choisirez certainement pas l'assembleur. Comme pour les autres langages vous ne ferez que créer vos propres difficultés!
Bien sûr, il y a de vrais professionnels. Ils ne maîtrisent pas seulement l'habilité de la programmation en assembleur mais ils ont aussi une connaissance approfondie des macros que l'assembleur offre. Ceci nous permet de coder rapidement, efficacement et avec soin.

Résumé.

Les arguments pour et contre l'assembleur sont résumés ici:

• Ecrire en assembleur prend plus de temps, mais moins que ce que les gens en pensent.
• L'assembleur offre plus de facilités pour structurer un programme, même si le manque de professionnels apporte plus facilement des problèmes de maintenance.
• En assembleur on a plus de possibilités pour résoudre ou prévenir des problèmes de performance.
• Cela prend plus d'effort pour trouver ou former des professionnels.

En prenant tout cela en compte, notre devise est: ne pas écrire en assembleur quand ce n'est pas utile. De l'autre côté, si vous avez de bonnes raisons de le faire, ne vous en privez pas; l'assembleur n'est pas un monstre. Et si vous choisissez l'assembleur, utilisez le seulement pour les modules qui en tireront profit. La plus grande partie de vos applications est probablement mieux maîtrisée dans des langages 3GLs ou 4GLs.

Pour terminer, pour certaines applications il n'est tout simplement pas possible d'utiliser un autre langage que l'assembleur. Ceci est particulièrement vrai pour la plupart des exits.
Non seulement le système d'exploitation, mais aussi un bon nombre de produits standards est programmé avec des exits, pour permettre une installation du logiciel adapté à vos besoins. Pour la majorité des exits l'assembleur est simplement inévitable. Avec tous ces arguments il ne devrait plus y avoir de problèmes insurmontables.

Ce site est un membre de WebRing. Vous êtes invités à parcourir la liste des sites des amoureux des mainframes.		Les dinosaures ne sont pas morts. Ils vivent et ils résident dans les centres de données tout autour de nous. Ils parlent plusieurs langues et travaillent magiquement avec les ordinateurs. Attention aux dinosaures! Et au cas où vous attendiez la fin des dinosaures: rappelez-vous que les dinosaures ont régit le monde pendant 155 millions d'années!
Dinosaures et autres anachronismes [ Joindre maintenant | Sites Ring | Au hasard | << Précédent | Suivant >> ]

Pour les avantages de l'assembleur.
Pour les préjugés contre l'assembleur.
Pour le résumé.

Pour la page d'accueil française.
Pour la page d'accueil générale.

Ce texte est écrit par A.F. Kornelis, traduit par René Brandt.
© Copyright: A.F. Kornelis, 1997-2003. Tous droits réservés.
La traduction: © Copyright: René Brandt, 2003. Tous droits réservés.
E-mail l'auteur ou le traducteur.

Ci-dessous vous trouverez le logo de notre sponsor et les logos des sites web auxquels nous adhèrons.