J'espère, Basile, que tu ne vas pas penser que je t'en veut (ce qui n'est absolument pas le cas) ;-).
J'ai une approche pratique de la programmation temps réel matériel et il me semble qu'il ne faut pas jeter le bébé avec l'eau du bain concernant l'assembler.
Actuellement je travaille sur un projet de contrôle d'accès (désolé de ne pas être plus précis, discrétion oblige). Je peux t'assurer que les micro-calculateurs ne suivent absolument pas si le code est rédigé en C (expérience faite), d'où obligation de l'assembler. Et pourtant, la dimension temporelle n'est pas vraiment exigeante et, en plus, on la maîtrise plus ou moins en étant également partie prenante du développement matériel.
Et, en matière de coûts, il ne s'agit pas de salaires de stagiaires français mais de salaires suisses d'ingénieurs confirmés (qui gagnent environ le double de leurs homologues en France). Et pourtant, ces gens là travaillent, en assembler. Tout cela dans une entreprise de renommée mondiale qui a pour clients pas mal de grandes boîtes françaises (la quasi totalité du PAF par exemple). Il faut donc bien penser que les coûts sont compétitifs (en plus d'un savoir-faire difficile à trouver) et que l'utilisation de l'assembler ne péjore pas ces coûts.
Citation
Basile STARYNKEVITCH
De plus, pour le x86, les optimisations dépendent du modèle de processeur cible; elles sont différentes sur AMD et sur Intel et peut-être même sur Opteron et sur Turion!
Les applications qui nécessite l'assembler ne tournent pas, en général, sur ce type d'architecture. Et, de toute façon, elles interagissent tellement étroitement avec le matériel qu'elles ne sont pas, intrinséquement, portables.
Citation
Basile STARYNKEVITCH
En pratique, les quelques programmeurs en assembleur que j'ai connus connaissaient mal toutes les subtilités (optimisations, extensions, builtins, inline asm) de GCC et ne codaient pas mieux qu'un bon programmeur qui maîtrisait GCC - en se permettant de temps à autre le mot clef asm.
gcc est peut-être relativement bien foutu en terme de génération de code rapide (encore que l'on trouve mieux), mais il n'est pas toujours à disposition, en fait, on n'a pas toujours à disposition un compilateur C performant.
Citation
Basile STARYNKEVITCH
Et j'ai déjà lu plusieurs papiers (y compris assez anciens) qui illustraient que pour une routine d'une centaine de lignes, certains compilateurs l'optimiseront mieux que le programmeur humain.
Il n'y a plus que les attardés qui pondent des centaines de lignes en assembler (d'ailleurs, en existe-t-il encore ?). Un module assembler ne dépasse que très rarement une soixantaine de lignes (ce que l'on peut voir en totalité sur son écran). Et ça, je ne l'ai pas lu: c'est ma pratique.
Citation
Basile STARYNKEVITCH
...
Le contrôle d'un avion se fait en C (en écrasante majorité).
...
Je suis au regret de te contredire, l'avionique est un domaine que je connais particulièrement bien pour y avoir oeuvré de nombreuses années et pour y oeuvrer encore de temps en temps (en fonction de mes mandats). En théorie, tu peux programmer en n'importe quel langage, moyennant quelques restrictions (interdiction de mémoire dynamique entre autres) qui interdisent ipso-facto certains langages, par exemple tous les langages orientés objets. En pratique, tu n'as
aucune chance de voir ton logiciel certifié s'il n'est pas écrit en
ADA. Et un logiciel d'avionique non certifié peut être directement mis à la poubelle.
De toute façon, l'avionique n'a pas vraiment de contraintes de temps dramatiques, y compris le contrôle des gouvernes ou le contrôle des vibrations des réacteurs: on est dans des vitesses d'ordre mécanique, c'est-à-dire des ordres de grandeur plus lent que l'électronique.
Amha, la rapidité et la sûreté de codage ne dépendent absolument pas du langage utilisé, c'est plutôt une affaire de formation du programmeur. Et là je dois regretter des lacunes invraisemblable dans les formations actuelles. Combien de programmeur connaissent le fonctionnement interne d'un CPU ? Et ceux qui connaissent le fonctionnement, les électroniciens par exemple, sont souvent de piètres programmeurs. Même en programmant en langage "évolué", la connaissance de ce fonctionnement permet d'amélorer ses techniques de codage. Par exemple, éviter la pagination, accès plus performants aux tableaux par une utilisation judicieuses des pointeurs, etc.
Non, il faut être clair. Le choix du langage de programmation dépend de l'application. Il serait parfaitement aberrant, voire "criminel", d'écrire un interface graphique machine-utilisateur en assembler (ce serait tout aussi aberrant de l'écrire de toute pièce en C en négligeant l'utilisation d'une "tools box").
Je ne verrais pas non plus l'utilisation de Java pour un logiciel d'avionique (de toute façon interdit pour cause d'allocation dynamique de mémoire). En fait, dans ce cas, et si l'on veut gagner sa vie, ADA est obligatoire.
De même,en général, je ne vois pas trop l'intérêt de mélanger les langages dans des applications nécessitant l'utilisation de l'assembler. Ce genre d'applications n'ont pas, dans la plupart des cas, d'interface homme-machine et c'est la totalité du logiciel qui doit être performante, c'est donc la totalité du code qui est en assembler.
Dans le cas particulier de Melle Linux, tout dépend de ce qu'elle veut faire. S'il s'agit d'une application réelle, hors contexte temps réel matériel, je suis, comme toi Basile, assez réservé (pour ne pas dire plus) quand à l'utilisation de l'assembler dans ce cas.
Par contre, s'il s'agit d'apprendre quelque chose, alors là, l'utilisation de l'assembler me paraît interessante. Mais, dans ce cadre, pour apprendre, je verrais plutôt la réalisation d'un module en assembler, assemblé par
as et, ensuite "linké" à un programme C. Il y a là quantité de choses à apprendre:
- la notion d'édition des liens,
- les liens entre modules: par registres matériels, par piles, par stucture, etc.
- etc.