Quels sont les avantages / inconvénients de l'utilisation de C par rapport à l'assemblage? [fermé]

15

Fermé . Cette question doit être plus ciblée . Il n'accepte pas actuellement les réponses.

Voulez-vous améliorer cette question? Mettez à jour la question afin qu'elle se concentre sur un problème uniquement en modifiant ce message .

Fermé il y a 5 ans .

J'étudie actuellement l'ingénierie dans les télécommunications et l'électronique et nous avons migré de l'assembleur vers le C dans la programmation de microprocesseurs. Je doute que ce soit une bonne idée. Quels sont les avantages et les inconvénients du C par rapport à l'assemblage?

Les avantages / inconvénients que je vois sont:

Avantages:

Je peux dire que la syntaxe C est beaucoup plus facile à apprendre que la syntaxe Assembler.
C est plus facile à utiliser pour créer des programmes plus complexes.
L'apprentissage de C est en quelque sorte plus productif que l'apprentissage de l'assembleur car il y a plus de choses à développer autour de C que l'assembleur.

Désavantages:

L'assembleur est un langage de programmation de niveau inférieur à C, ce qui en fait un bon outil pour programmer directement sur le matériel.
Est beaucoup plus flexible pour vous faire travailler avec de la mémoire, des interruptions, des micro-registres, etc.

c low-level assembly

— Daniel Conde Marin
source

17

Uhm ... bienvenue au nouveau siècle. Vous l'aimerez ici. Nous avons des microcontrôleurs exécutant .NET , Java , Linux et même des personnes utilisant python pour programmer des PIC .

— ZJR

@ZJR Comment utilisez-vous Python pour programmer un PIC? Quelle photo?

— detly

2

@detly Ce n'est pas un python à part entière, juste un sous-ensemble du noyau. Une couche de syntaxe python sur la fonctionnalité du contrôleur , si vous le souhaitez. pyastra est le premier exemple sur lequel j'ai fait une recherche sur Google , mais je me souviens un peu d'avoir lu des documents d'un autre, qui a également fait des ATMEL.

— ZJR

4

Pour être honnête, avec la complexité des processeurs modernes, je serais surpris si de nombreux programmeurs pouvaient écrire un assembleur plus serré et plus efficace qu'un compilateur C moderne ne peut générer de toute façon. Je détesterais essayer de programmer un processeur d' architecture EPIC dans l'assembleur par exemple - Mel serait à l'aise avec l' Itanium . * 8 ')

— Mark Booth

5

@ZJR Ce nouveau siècle semble passionnant! Je suis curieux cependant, dans quelle langue le runtime .NET, Java VM et Linux ont-ils été écrits, pour ces microcontrôleurs? Comme dans, dans quelle langue la programmation du microcontrôleur a-t-elle été effectuée? Oh ... C ou assembleur ce siècle aussi ...

17

Voici quelques réponses de débordement de pile qui peuvent vous aider (ce sont les meilleures réponses, les réponses acceptées):

Les avantages

/programming/143561/is-there-a-need-to-use-assembly-these-days (pour les utilisateurs 10K uniquement) ou Archive

L'assemblage est utilisé dans les premières étapes du chargeur de démarrage. Lorsque le processeur alimente la pile n'est pas disponible, et il est difficile d'empêcher le compilateur C d'essayer d'enregistrer des choses dans la pile. La majeure partie du chargeur de démarrage est néanmoins écrite en C, une fois la première initialisation effectuée.
L'assemblage est utilisé pour écrire des primitives de verrouillage mutex. Il est essentiellement impossible d'obtenir un compilateur C pour émettre des instructions de barrière de mémoire aux endroits requis.
Les routines comme memset () ou memcpy () sont souvent effectuées en assembleur. Par exemple, j'ai écrit un memset () avec une grande boucle non déroulée, qui calcule dynamiquement une adresse de branche pour sauter au milieu de cette boucle pour une dernière itération. La routine AC aurait généré plus de code, prenant des I $ manquants supplémentaires. De même, les jeux d'instructions CPU incluent souvent le chargement de la ligne de cache ou d'autres instructions qui peuvent considérablement accélérer memcpy (), que le compilateur C n'utilisera pas.

Désavantages

/programming/2684364/why-arent-programs-written-in-assembly-more-often

ASM a une faible lisibilité et n'est pas vraiment maintenable par rapport aux langages de niveau supérieur.
En outre, il y a beaucoup moins de développeurs ASM que pour d'autres langages plus populaires, tels que C.
De plus, si vous utilisez un langage de niveau supérieur et que de nouvelles instructions ASM deviennent disponibles (SSE par exemple), il vous suffit de mettre à jour votre compilateur et votre ancien code peut facilement utiliser les nouvelles instructions.

Exemple

Le dernier post ci-dessous est un post Stack Overflow décrivant un scénario qui montrera un exemple d'assemblage plus rapide que C (lors de l'exécution de la même fonction).

/programming/577554/when-is-assembler-faster-than-c

— jmq
source

20

C est plus facile à programmer que l'assemblage. Il y a des raisons évidentes qui ne méritent pas d'être reprises.
Plus facile à utiliser, C vous permet d'écrire des programmes plus rapidement. Généralement, ces programmes sont également plus faciles à déboguer et plus faciles à maintenir. De plus, il est plus facile de gérer de gros programmes complexes en C.
Souvent, le code généré par un compilateur est tout aussi bon (en termes de vitesse et d'efficacité) qu'un assembleur écrit à la main - sinon mieux.
C est sacrément bas niveau, et il est rare que vous souhaitiez aller beaucoup plus bas. Avoir une couche d'abstraction supplémentaire est rarement une mauvaise chose.
Lorsque vous devez descendre plus bas, vous pouvez utiliser Assembly, sinon vous pouvez utiliser C.
Vous pouvez écrire Assembly en C-code, mais pas C en Assembly-code.

— BBB
source

6

Je dirais que plusieurs fois vous verrez que le code machine optimisé pour le compilateur C est meilleur que votre code d'assemblage écrit à la main

— utilisateur

@crucified - c'était déjà une revendication courante (et généralement justifiée) du milieu à la fin des années 90. Un compilateur applique les optimisations de manière fiable et systématique - pas seulement lorsqu'il remarque l'opportunité.

— Steve314

15

Le programme AC peut être compilé en différentes architectures de microprocesseur.

— cgull
source

4

nous avons migré de l'assembleur vers C dans la programmation des microprocesseurs. J'ai des doutes que c'est une bonne idée

N'ayez crainte, personne ne développe plus de nouveaux programmes en 100% assembleur. De nos jours, C peut être utilisé même pour les architectures 8 bits les plus minuscules et les plus folles. Cependant , connaître un assembleur fait de vous un programmeur C bien meilleur. En outre, il y a toujours quelques petits détails ou deux dans un programme qui doivent être écrits en assembleur.

Je peux dire que la syntaxe C est beaucoup plus facile à apprendre que la syntaxe Assembler.

Oui, la syntaxe est plus facile, certainement. Cependant, l'apprentissage de tout le langage C avec tous les détails ennuyeux est beaucoup plus complexe que l'apprentissage de tous les détails d'un assembleur particulier. C est un langage beaucoup plus grand et plus large. Mais là encore, vous n'aurez peut-être pas besoin d'apprendre tous les détails.

C est plus facile à utiliser pour créer des programmes plus complexes.

En effet, C fournit des mécanismes pour la conception de programmes modulaires, tels que l'encapsulation et les étendues locales / variables locales. Et C a une bibliothèque standard, ainsi qu'une énorme quantité de ressources écrites au cours des 30 dernières années. Et surtout, C est portable.

L'apprentissage de C est en quelque sorte plus productif que l'apprentissage de l'assembleur car il y a plus de choses à développer autour de C que l'assembleur.

C possède de nombreuses fonctionnalités, bibliothèques et ressources prédéfinies, il y aura donc moins de réinvention de la roue. Mais à part cela, votre déclaration est subjective. Je crois que c'est une question de préférence personnelle.

Par exemple, je suis un programmeur C expérimenté, programmant occasionnellement du C ++. Je me trouve beaucoup moins productif en C ++, parce que je ne connais pas ce langage aussi bien que je connais C. Mais juste parce que je ressens cela, cela ne signifie pas nécessairement que la programmation en C est plus productive que la programmation en C ++. Un programmeur C ++ expérimenté aurait sûrement l'opinion contraire.

Et il y a de nombreux aspects à «productif». Un aspect très important est le temps de maintenance, et en particulier le temps nécessaire pour corriger les bugs induits par la maintenance. C est beaucoup plus facile à entretenir que l'assembleur.

L'assembleur est un langage de programmation de niveau inférieur à C, ce qui en fait un bon outil pour programmer directement sur le matériel.

La programmation matérielle peut être effectuée directement dans les deux langues. Les seules choses que vous ne pouvez pas faire en C sont d'accéder aux pointeurs de pile et aux registres de condition, etc., du cœur du processeur lui-même. Donc, si par programmation matérielle vous voulez parler avec votre propre CPU, alors oui, l'assembleur autorise un peu plus que C. Si vous voulez dire accéder au matériel externe, alors l'assembleur n'a aucun avantage sur C. Mais peut-être des inconvénients, car il est souvent plus difficile d'écrire code assembleur générique pour un périphérique externe particulier, que le code C générique.

Est beaucoup plus flexible pour vous faire travailler avec de la mémoire, des interruptions, des micro-registres, etc.

Ce n'est pas correct. C vous permet également de faire tout cela, même si vous devrez peut-être vous fier au code C spécifique au compilateur, comme le mot-clé d'interruption.

En fin de compte, vous devez connaître les deux langues pour programmer les MCU, en mettant l'accent sur C.

De quelle manière l'ensemble du langage C est-il plus complexe que certains des langages machine les plus obscurs? Après avoir fait les deux, je pense que C sans les bibliothèques est considérablement moins complexe. Si vous faites référence à la bibliothèque standard C, vous avez également besoin de quelque chose comme ça dans l'assembleur pour faire quelque chose d'utile. C peut être un langage plus large et plus large, mais vous n'avez pas besoin de le connaître au même niveau de détail. a = b[i] + c;est beaucoup moins compliqué que les instructions à charger b[i](qui nécessitent des calculs) et cdans des registres (qui doivent être rendus disponibles), à ajouter et à stocker.

— David Thornley

1

@DavidThornley Plus vous en apprenez sur C, plus vous vous rendez compte de sa complexité. Connaissez-vous des centaines de cas de comportement indéfini / non spécifié / défini par implication? Connaissez-vous en détail toutes les règles de promotion de type implicite (promotions entières, conversions arithmétiques habituelles)? Toutes les règles et syntaxe particulières concernant les spécificateurs de type? Toutes les différentes formes de tableaux multidimensionnels statiques / dynamiques, y compris les pointeurs de tableau (à ne pas confondre avec les pointeurs vers le 1er élément d'un tableau) Toutes les fonctionnalités de C99 et C11? Etc.

1

@Lundin: Ce qui est important avec C, c'est que vous pouvez poser toutes ces questions et trouver des réponses concrètes. Les compilateurs conformes à la norme sont tenus de documenter leur comportement pour les 62 comportements définis par l'implémentation (et non des «centaines»). La simplicité de l'assemblage en fait une proposition à apporter, ce qui à son tour décharge la complexité que C traite avec votre propre code. Je pourrais contrer votre argument en demandant combien de bibliothèques à virgule flottante ont été écrites en assembleur pour une architecture donnée et pourquoi leur comportement est défini par l'implémentation.

— Blrfl

1

@Lundin: 62 est le nombre de comportements définis par le compilateur répertoriés dans la section 4 du manuel GCC. Le fait de laisser de côté ce qui est défini par la bibliothèque permet une comparaison entre pommes car il n'y a pas de bibliothèque standard pour l'assemblage. L'obligation de documenter est la première phrase du §J.3. GCC et la poignée de compilateurs commerciaux que j'ai achetés ou utilisés depuis que le C89 a été ratifié (Intel, Sun, IBM, Portland Group), donc votre "maximum" qui ne dérange pas ne peut pas se dire conforme. En parlant de normes, comment l'assemblage de x86 écrit avec la syntaxe Intel sur un assembleur avec la syntaxe AT&T fonctionne-t-il pour vous?

— Blrfl

1

@Lundin: Ma voiture est super, merci. Le volant, l'accélérateur, le frein, l'embrayage et le clignotant sont tous dans des emplacements standard, ont un comportement standard et les autres commandes sont toutes clairement marquées avec des symboles standard ISO. Toutes les choses définies par l'implémentation comme le système de divertissement, le CVC, la navigation, le régulateur de vitesse, etc. sont documentées dans un gros livre dans la boîte à gants. L'assemblage est comme mon Plymouth de 1973: il n'y avait pas grand-chose, mais à l'état brut, il n'était pas du tout aussi performant que ce que je conduis maintenant. L'assemblage est la même manière; la complexité vient de ce que vous y ajoutez.

— Blrfl

1

Selon la façon dont vous devez vous embarquer, C va produire de gros programmes lents. Ce qui augmentera sensiblement le coût de cette partie du produit. Il peut s'agir d'une goutte d'eau dans l'océan pour l'ensemble du produit ou peut radicalement changer le produit. Oui, certains pourraient dire que les efforts de développement et de maintenance de logiciels sont moins chers, encore une fois, cela peut être vrai ou faux, si cela est profondément intégré et vise une partie à faible puissance, petite et peu coûteuse, vous ne parlez pas de beaucoup de code. Ce code est principalement spécifique à ce fournisseur ou à cette puce spécifique, donc être en C n'a aucun avantage de portabilité, vous devez de toute façon réécrire avant chaque cible. Avec la série cortex-m d'ARM, nous commençons à peine à pouvoir concurrencer C avec asm, pas que les gens n'utilisent pas C ou d'autres langages de niveau supérieur dans leurs produits intégrés,

Le débat C vs ASM, professionnellement, se résume toujours à l'écrire en C et à utiliser ASM où vous pouvez le justifier. Et vous pouvez le justifier. Dans le monde intégré, il y a des performances et de la taille.

Vous devez inclure la cible dans cette discussion. Bien que beaucoup aient utilisé C avec Microchip (les anciennes photos, pas le pic32 qui est mips) à un coût énorme, c'est un jeu d'instructions affreux pour les compilateurs, un jeu d'instructions très éducatif et intéressant mais un compilateur peu amical. msp430, avr, bras, pouce, mips, tous bons pour les compilateurs. 8051 aussi mauvais.

Encore plus que la langue des outils. Surtout dans les cas où le souci du développement et de la gestion du code est un argument, vous avez besoin d'outils pour être là aujourd'hui et demain. Avoir un outil source unique, y compris même un seul mod gcc, géré par un groupe, est risqué d'un point de vue commercial. Vous trouverez probablement plus d'un assembleur, et toute personne digne de faire partie de cette équipe pourrait concocter un assembleur en un week-end (tant que l'assemblage que vous écrivez n'est pas une directive ghee whiz et une macro heureuse). Pour asm et C, vous voudriez utiliser des outils open source (ou vos propres outils internes) où vous avez une meilleure chance, même si cela signifie utiliser une machine virtuelle pour exécuter une distribution Linux vieille de 10 ans, d'avoir des outils disponibles pour la durée de vie du produit.

En fin de compte, encore une fois, utilisez / apprenez / enseignez C et asm, commencez par C et utilisez asm où vous pouvez le justifier.

— old_timer
source

Ces arguments me semblent démodés. Si vous utilisez un compilateur moderne qui a été écrit au cours des 10 dernières années, je pense que vous aurez du mal à écrire un programme assembleur qui est nettement plus efficace qu'un programme C. À moins que vous n'utilisiez peut-être une architecture de dinosaure de 30 ans comme PIC ou 8051, vous aurez un programme lent, peu importe ce que vous faites ...

Il est assez trivial de corriger un assemblage lent généré par les gcc et llvm les plus modernes. Le gcc 4.x produit un code plus lent et moins efficace que la série 3.x (pour certaines cibles, au moins celles que j'ai évaluées, ARM par exemple). Je pense qu'il est important de dissiper l'idée que le compilateur fait mieux que les humains parce qu'il ne l'est pas. Et même quand il le fait, il ne le fait que lorsque l'humain sait ce qu'il fait. «connaissez vos outils» si vous souhaitez les utiliser efficacement. Commencez par C et utilisez ASM si nécessaire si vous pouvez le justifier ...

— old_timer

Puisque gcc est open source, c'est une étrange bête. Peut-être que ce port particulier est mal fait. Toutes les optimisations de code doivent être effectuées pour la plate-forme spécifique, ce n'est pas une tâche triviale. Il serait plus juste de comparer les performances d'un assembleur manuel à un compilateur commercial pour cette plate-forme.

gcc est multi-cible donc il fait un très bon travail en moyenne mais pas un excellent travail pour une cible particulière. Et c'est ce qui est attendu. mais ce que vous pensez d'un compilateur moderne, des 10 dernières années, etc. L'idée que tout compilateur moderne rend le meilleur code possible est tout simplement fausse. Très vrai qu'en moyenne, c'est beaucoup mieux que l'assembleur codé à la main, difficile de faire un projet de taille décente en asm mieux que C

— old_timer

c'est pourquoi la plupart des gens disent utiliser C jusqu'à ce qu'il y ait un problème, puis réparer le problème à la main si vous le justifiez. avez-vous vraiment besoin de ce petit gain de performances, est-ce vraiment là que se situe votre problème de performances, voulez-vous conserver ce code avec asm, allez-vous continuer à vérifier chaque futur compilateur pour voir si sa sortie répare ou réduit votre problème à un niveau acceptable, etc.

— old_timer

1

Pour l'assemblage, il existe un compromis inévitable entre la maintenabilité du code et les performances. Vous pouvez écrire un assemblage facile à lire / à entretenir, ou vous pouvez écrire du code hautement optimisé; mais vous ne pouvez pas faire les deux.

Pour C, le compromis ne disparaît pas tout à fait, mais il est beaucoup moins visible - vous pouvez écrire un C facile à lire / à entretenir qui est raisonnablement bien optimisé.

Un excellent programmeur en langage assembleur sera capable de battre le compilateur presque tout le temps, mais la plupart du temps, il choisira délibérément d'écrire du code facile à lire / maintenir; et donc un excellent programmeur en langage assembleur sera battu par un compilateur la plupart du temps.

La façon intelligente consiste à utiliser à la fois l'assembly et le C (au lieu de l'assembly ou du C uniquement) - par exemple, utilisez C pour les parties du code où un excellent programmeur de langage d'assemblage aurait choisi d'écrire du code maintenable / lent, et utilisez l'assembly pour le reste (où "hautement optimisé et difficile à maintenir" est en fait justifié).

— Brendan
source

-3

Relativement bon pour l'efficacité de la programmation.
Il est facile de programmer en utilisant le langage c plutôt qu'en utilisant l'assembly.
Le langage C peut être bien plus rapide que le langage d'assemblage.
Il est possible d'écrire l'assembly en code C mais pas C en code assembly.

— Kiran Sapkale
source

3

avantages seulement ....

— Kiran Sapkale

3

Il s'agit principalement d'une version remaniée de Quels sont les avantages / inconvénients de l'utilisation de C par rapport à l'assemblage? ; vous n'avez rien ajouté de nouveau à la discussion ici.

— Martijn Pieters