Citation
Melle Linux
je programme sous linux avec C et je veux inclure dans mon programme C un sous programme assembleur comment puis-je l'inserer et comment puis-je compiler le tout

A mon avis, coder des routines en assembleur est actuellement une grosse bêtise, et une perte de temps humain (qui de nos jours vaut bien plus que le temps machine; pour le reste, le compilateur optimisera suffisamment, et si tu cherches les derniers pourcents d'efficacité documentes toi plutôt sur les très nombreuses optimisations de gcc [gcc.gnu.org] qui propose des tas d'options spécifiques pour ça).

Tu pourrais peut-être avoir envie d'utiliser l'assembleur pour quelques instructions en ligne dans ton code C, par exemple priviliegiées (comme entrée et sortie sur un port dans un module du noyau) ou spécifiques à une extension (MMX, SSE, que sais-je). Pour ces derniers existent des primitives spécifiques de gcc [gcc.gnu.org] (gcc builtins) [www.delorie.com] qui sont préférables à l'assembleur en ligne.

Dasn ces cas, utilise les primitives susdites (builtins qui sont très puissantes en GCC) ou l'instruction asm de gcc. Le noyau notamment en est farci, et peut servir d'exemple. GCC inline assembly [www.ibiblio.org]

Enfin, GCC propose aussi des extensions au langage C [gcc.gnu.org] (spécifiques à GCC mais indépendantes de la machine cible). Elles sont très utiles. Documentes toi!

Si tu veux absoluement coder une routine entière en assembleur (attention l"assembleur linux usuel -as, invoqué par la commande gcc sur des fichiers *.s- a une syntaxe différente de l'assembleur microsoftien; il y a aussi nas) tu l'assemble pour produire un fichier objet .o que tu lie normalement (par gcc par exemple).

Expliques nous pourquoi tu veux coder en assembleur! L'utiliser à tort interdit des optimisations possibles (par le compilateur actuel ou futur) dans ton programme

Juste une remarque: le fait que tu poses des questions aussi simples me pousse à croire très fort que tu n'as pas vraiement besoin d'assembleur et que tu commets une erreur à vouloir utiliser l'assembleur :hat: :-p. Autrement tu aurais déjà trouvé et lu l'Assembly HOWTO [www.tldp.org]

----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Tuesday 6 June 2006 17:17:59

Fautes de frappe ci-dessus à propos d'assembleur... C'est NASM [v](pas nas comme écrit à tort ci-dessus)[/v] [nasm.sourceforge.net]

Par ailleurs, l'assembleur est évidemment non portable, y compris à la limite sur la même famille de processeur, en ce sens qu'une instruction x86 à la mode il y a 5 ans peut devenir obsolète dans quelques années, et les processeurs (même x86 dernier cri) la supporteront inefficacement!


----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Tuesday 6 June 2006 17:21:43

Citation
Basile STARYNKEVITCH
...
A mon avis, coder des routines en assembleur est actuellement une grosse bêtise, et une perte de temps humain ...

Basile, je me permet de ne pas partager totalement ton avis. Les assemblers restent indépassables dans certains domaines (essentiellement pour des raisons de rapidité), par exemple le scheduler d'un système d'exploitation, le traitement du signal, etc, et de façon plus générale, les traitements en temps réel matériel, quand on doit réagir en termes de micro secondes (voire de nano secondes) on n'a pas vraiment le choix, quelque soit la puissance de la machine cible. Par exemple, je vois mal programmer le contrôle d'un accélérateur de particules avec un langage dit évolué.

Mais à part ce genre d'applications, effectivement, les assemblers ne devraient plus être utilisés pour de multiples raisons dont la principale me paraît être l'impossibilité de porter le logiciel.

Contrairement à toi, Basile, je ne pense que la programmation en assembler soit une perte de temps humain. Expérience faite, pour un programmeur, (enfin, ce que j'appelle un programmeur) c'est tout aussi rapide de programmer en assembler qu'en C, il suffit d'avoir les idées claires et d'avoir préalablement défini son algorithme. C'est même, parfois, plus rapide au niveau du déverminage, tant on fait attention au moment du codage.

Poste le Tuesday 6 June 2006 18:06:47

Me semble-t-il le scheduler de linux est écrit en C (depuis fort longtemps), avec effectivement des instructions en inline assembly... C'est même un gros fichier: linux-2.6.16.20/kernel/sched.c compte 6167 lignes et c'est bien l'ordonnanceur des tâches du noyau.


Et en pratique, le noyau linux compte beaucoup d'instructions asm mais dans du code C (essentiellement dans les fichiers include)!

Le contrôle d'un accelerateur de particule se fait aussi en C (et de plus en plus). Le contrôle d'un avion se fait en C (en écrasante majorité).

Ce que je voulais dire à Mlle Linux (dont j'imagine qu'elle code un module pour le noyau) c'est qu'il vaut bien mieux utiliser asm dans des fichiers C (propres à gcc, et à la plateforme cible) que de coder des routines de plusieurs centaines de lignes en assembleur. Il y a des tas d'intermediaire entre du code C portable et de l'assembleur pur, et le noyau en est truffé!

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.

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!

Donc je conseille quand même de préférer coder des petits bouts (quelques lignes dans des macros ou des fonctions inline) avec le mot clef asm de GCC plutot qu'un fichier assembleur de centaines de lignes.

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.

J'ai codé en assembleur (et même un peu sur IBM 360), mais je prefère Ocaml.

Et du reste, on peut aussi générer du code machine à la volée (à run-time) Il y des outils (GNU lightning, libjit, ...) qui le permettent agréablement.

J'aimerais bien savoir pourquoi Mlle Linux (quel joli pseudo) voudrait coder en assembleur....



----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Tuesday 6 June 2006 18:30:09

J'ai oublié de préciser que de nos jours, quand on veut faire un traitement rapide, on ne code plus en assembleur x86, mais on développe (hardware-software co-design) le matériel convenable (en VHDL, SystemC ou autre). C'est notamment le cas dans les parties basses des instrumentations sophistiquées d'un accélérateur de particule, et ce n'est probablement pas beaucoup plus cher que de payer des tas d'esclaves indiens ou chinois à pisser de l'assembleur fiable... (sinon, je ne suis pas inquiet, on l'aurait fait).

Même le temps du stagiaire français (et je sais que beaucoup sont mal payés) reste trop cher pour des centaines de lignes d'assembleur.

D'ailleurs, il y a beaucoup moins d'outils d'analyse statique d'assembleur que d'analyse statique de VHDL ou SystemC. (même si il y en a peu).

----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Tuesday 6 June 2006 18:44:53

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.

Poste le Wednesday 7 June 2006 11:06:38

[v]Zut zut, j'avais déjà répondu, mais ça s'est perdu....[/v]


Je travaille sur l'analyse statique de code C critique, et je peux t'affirmer qu'il existe dans le Airbus A380 du code C critique.

je ne suis pas sûr de pouvoir en dire plus, mais par exemple voir les pages du CEA-LIST (LSL, le labo où je bosse) [www-list.cea.fr]
[www-list.cea.fr]

Donc il est certainement inexact qu'aujourdhui le code critique de l'avionique doit être codé en Ada (ou assembleur). C'était autrefois vrai, mais aujourdhui on peut y coder du C (avec des règles strictes) convenablement prouvés.

D'ailleurs, ADA ne suffit pas à éviter les bogues (voir l'épopée d'Ariane 5 vol 501, qui à mon humble avis est plus une erreur de management qu'une erreur technique).

Il me semble aussi que le VAL (metro automatique) a son code critique en C avec une preuve formelle ...

Et dans l'automobile, il y a pas mal de code C, y compris pour les fonctions critiques
[www.numatec-automotive.com]

j'en sais un peu plus, mais je ne peux dire ici que ce qui est déjà publié sur le Web.

----

Basile STARYNKEVITCH

Membre de l'APRIL « promouvoir et défendre le logiciel libre » - adhérez vous aussi à l'APRIL!

Projet logiciel libre: RefPerSys

Poste le Wednesday 7 June 2006 18:10:53