Discussion :

[liquid_stone]

Bonjour,

Je me suis posé une question et ne pouvant trouver la réponse même en cherchant un peu, je la pose à ceux qui connaissent les 2 langages :
Quels sont les critères qui permettent de choisir l'un ou l'autre quand on veut faire de la prog systeme ?

Merci de votre participation

[Alcatîz]

Bonjour !

Personnellement, à part l'obligation d'obtenir un exécutable de taille très réduite, je ne vois pas sur quel plan l'Assembleur pourrait être préféré au C.

Mais l'un n'empêche pas l'autre : tu peux inclure du code Assembleur dans un programme C.

[Smortex]

Même avis ... N'utiliser l'assembleur que si cela est indispensable (Taille extrèmement réduite, bootloader, etc ...)

[Mac LAK]

Je mets un (petit) bémol à l'affaire : certes, l'assembleur est à réserver aux "loaders" (MBR par exemple) de manière générale, mais il est également extrêmement utile pour les parties de code critique en terme de temps d'exécution, ou lorsque l'on tape directement dans le matériel...

Mon boulot est (notamment) de développer des programmes embarqués, notamment des drivers et des API sur ces drivers, et même si le code de "haut niveau" n'est qu'en C, faudrait être malade pour vider un composant Ethernet uniquement en C.... Vive le REP INSB/OUTSB !! ;-)

[Smortex]

mais il est également extrêmement utile pour les parties de code critique en terme de temps d'exécution,

Je met un bécard à ton bémol (Si je ne m'abuse du temps ou on faisait de la flute au collège) Je connais peu de programmeurs qui optimisent mieux leur code en assembleur que ne le font la plupart des compilateurs C... Si tu prends un compilo de chez... mettons Intel, tu constatera que le code qu'il te pond est assez loin de ce à quoi tu pouvais t'attendre, mais en nombre de cycles d'horloge, il est loin devant
La plupart des compilos utilisent des trucsbien fourbes ce qui rends le code assez indigeste, .... mais plus performant

Donc a moins de connaitre sur le bout des doigts les manuels de Intel... Un programme en C sera toujours plus rapide.

[Mac LAK]

Heu.... Là, franchement, j'ai un GROS doute sur le fait qu'un programme C soit plus rapide qu'un programme Assembleur, surtout et notamment si tu prends un mix langage évolué (C, Pascal, Delphi) avec des boucles optimisées en ASM... Et ça, même si tu actives l'intégralité des optimisations de vitesse de ton compilo, et quel que soit la société ayant fabriqué ledit compilo... Et il ne faut pas confondre "vitesse d'exécution humaine" avec "vitesse d'exécution machine" : lorsque tu tapes directement dans un contrôleur en suivant les timings de la datasheet et que tu te rends compte que la SEULE et UNIQUE solution est d'insérer 2 NOPs entre les accès pour tenir le timing, je voudrais franchement savoir COMMENT tu fais ça en C... Mais tu es excusable si tu n'as jamais écrit de driver bas niveau et/ou fait des programmes embarqués (je ne parle pas d'une appli pour PocketPC, bien entendu !! :-) ).

En pratique, et si tu veux rigoler un bon coup, les optimisations d'un programme C partent en vrille si tu as l'idée (saugrenue) de laisser des warnings dans le code : j'ai passé un nombre hallucinant de lignes de code en revue dans ma boîte sur le sujet, pour pouvoir justement activer les optimisations... Bref, c'est loin d'être la panacée. Et quoi que tu fasses, ton compilateur C ne sera JAMAIS capable de détecter des invariants dans ton code (au sens algo du terme) et d'en tirer parti, car il faudrait passer en langage B puis le traduire en C pour effectuer ce genre de fourberie... Mais un développeur travaillant directement en ASM en est capable, lui.

Et si c'est pour truffer le code d'appels inlines et préfixés de 1, 2 ou 3 underscores avant chaque nom de fonction (ce qui, en général, shunte les protections de la CLib : c'est pas une bonne idée sur un langage qui est aussi permissif que le C), sans parler des directives "register" sauvages, je préfère de l'assembleur inline bien clair : ça évite de fouiller dans les méandres du compilateur pour comprendre le pourquoi du comment...

Pour le "respect" du code, je suis d'accord avec toi à UNE condition : lorsque l'on utilise l'assembleur comme langage évolué... Peu de gens savent que l'on peut faire de la programmation orientée objet (POO pour les intimes) avec de l'Assembleur, directement sous TASM... Et lorsque ces fonctions sont actives, effectivement du code cadre de procédure est inséré. Si tu restes à de l'assembleur inline (ce qui est tacite lorsque l'on parle de "code critique"), tu as ce que tu requiert sans autre forme de procès.

Quant à connaître les manuels d'Intel, est-ce qu'il existe un VRAI développeur Assembleur qui ignore les cycles machines pris pour les instructions ? C'est quand même le B.-A.BA. du développement ASM ! Perso, j'ai le "TASM Reference Manual" chevillé à mon bureau, avec la "Bible du PC" à côté, et je ne vois vraiment pas comment on peut faire sans...

Donnes-moi n'importe quel code en C un tantinet complexe (une fonction strcpy() n'est PAS un bon exemple :-)), et je te promets que l'on peut gagner du temps dessus en passant les boucles critiques en Assembleur (natif bien entendu), par exemple sur proc x86 car c'est celui que je connais le mieux. N'importe quel profiler de code correct te le prouvera sans ambiguïté.

Désolé de la longueur et du ton, mais là, je ne pouvais pas laisser dire un truc pareil... Nothing personal, comme on dit ! ;-)