houla, un beau "C'est toi le PEBKAC" bien mérité.

C'est clair ! En ASM au moins tu contrôles ton code, tandis que le C fournit un code générique pas forcément bien optimisé.

Re-essaye encore une fois.

Pfff
vous etes vraiment a l'ouest les gars... le C est largement assez bas niveau pour faire des programmes tres developpés. L'ASM est bien trop specifique a chaque CPU pour etre encore utile de nos jours... Surtout dans l'embarqué ou ils existe des dizaines de CPU differents plus ou moins compatibles. Il serait debile de partir sur de l'ASM etant donné qu'il serait impossible de changer de proc sans recoder une bonne partie des programmes.
Franchement, croire qu'on a plus de "maitrise" sur le code en ASM par rapport au C, c'est la preuve qu'on est un gros noob qui se la joue et rien de plus

Et je pense que le mec qui ne sait pas ce qu'il fait en C, ne sait pas ce qu'il fait tout court quelque soit le langage qu'il utilise.

Exactement. On peut comprendre qu'il préfère l'ASM, mais il y a d'autres langages adaptés à son problème, celui-ci est loin d'être suprême. Surtout pour la maintenance.

Et si jamais t'as très très très peu de mémoire pour stocker ton code (genre16 ou 32ko) t'es bien content de coder en assembleur pour ne rien avoir d'inutile.

Apprendre l'ASM pour savoir ce qui se passe dans le proc est indispensable, mais vouloir programmer en ASM parce que le C serait trop aléatoire, c'est PEBKAC.

Coder une ou deux fonctions critiques en ASM, ça peut se justifier pour les raisons de performance si le compilo est limité. Mais sur un programme entier, les optimisation du compilateur sont souvent plus efficace que les optimisation humaines.
Sans parler du temps de dev qui explose et du programme produit qui est très peu lisible (donc plus facilement buggé)...

Après, pour la beauté du geste, pourquoi pas.

Tu peut très bien écrire de ma merde incompréhensible en ASM comme tu peut écrire du code lisible et optimisé en C (et vice versa).
L'argument "quand tu a 16 ou 32 ko de mémoire, t'est obligé d'écrire en ASM", c'est vraiment que tu sait pas coder correctement en C.

@SmoKe42 : si les mecs ont le choix de coder en C alors leur équipement embarqué ne semble pas aussi limité.
Bien sur que l'ASM peut être nécessaire dans certains cas voire indispensable mais tu justifies pas son emploi avec un "au moins, je sais ce que je fais". C'est complètement délirant. Y'a bien assez de bonnes raisons pour ne pas avoir à utiliser cet argument de gamin melonné du ciboulot après la découverte de sa première érection...

> Y'a bien assez de bonnes raisons pour ne pas avoir à utiliser cet argument de gamin melonné du ciboulot après la découverte de sa première érection...

Rien que ça... Voilà ce que c'est de dire qu'on veut programmer en ASM, on passe pour un "gamin melonné du ciboulot après la découverte de sa première érection".
Note pour plus tard : dans ce genre de situation, annoncer qu'on va utiliser Java (JEE bien sûr, sinon c'est pas fun) !

Disons qu'en assembleur on ne sais pas plus ce que l'on fait, mais on est plus sûr que le code est comme on voulait car on ne dépend pas des options et des choix parfois obscurs du compilateur.
Après ça dépend beaucoup de la nature de son projet embarqué.
Certains procs sont agréables à coder en ASM et le code n'est pas forcément long ou illisible.
Le C a aussi ses contraintes et on écrit parfois bien du code sans valeur intrinsèque (casts,etc...) pour couler son idée dans le moule du C, et bien malin (ou bien noob) celui qui peut prétendre qu'il maitrise à fond les "effets de bord" du C...

@birdy : relis moi mieux, c'est pas le fait d'utiliser ASM ou non que je trouve idiot. Ce que je trouve idiot est de justifier son emploi par l'argument "au moins, je sais ce que je fais". C'est complètement ridicule et dénote d'une grosse incompétence en C ET en ASM. Pourquoi ? Parce que croire qu'on ne peut pas faire de choses très bas niveau en C et croire qu'on doit utiliser ASM pour tout et n'importe quoi signifie une grosse incompétence.

@birdy :
Et surtout croire qu'on maitrise mieux son code en ASM est encore pire parce que, bien que ca puisse etre vrai sur qq routines, à l'échelle d'un programme entier, ca devient très vite incompréhensible. Et les gens compétents le savent bien et s'en méfient.
On peut aussi faire de la daube en C bien entendu mais il y a besoin d'une moins grande discipline pour maintenir le code dans le temps.

En même temps il n'a pas tord. Evidemment ici ne pas savoir ce qu'on fait -> instruction aléatoire.
Je pense qu'il parle plutôt de maitriser les instructions générées et exécutées.
Ce qui peut dans certains facilite le débugage et la pédagogie.
Sans compter que dans certains cas l'optimisation laisse à désirer ... (notamment le changement de pages)
Ce qui parfois sur une 16F84A change tout.

L'argument "on sait ce qu'on fait" se tient.
En C, tu fais un malloc, tu réserve de la place quelque part en mémoire. En assembleur, faut tout faire à la main. Je pense que c'est ce que voulais dire le "on sait ce qu'on fait", en tout cas je le comprend comme ça.

Le code sera pas forcément plus optimisé ni plus beau, mais indéniablement plus fun à écrire (pour les gens bizarres comme moi en tout cas).

La discussion ici engagée montre en tout cas qu'il n'y a pas PEBKAC.
Après d'avis personnel sur de l'embarqué je préfère aussi de l'ASM.

Moi je crois surtout que le gars s'est contenté de donner son avis. J'ai pas l'impression qu'il ait voulu dire que le C est moins bien, mais juste qu'il l'aime moins.

Mais je vous en prie. Continuez à vous agresser mutuellement.

Simplement pour préciser qu'il y a des choses qu'il est impossible de contrôler en C, comme l'utilisation des instructions SIMD des processeurs qui les proposent.
C'est un exemple, mais il dénote que pour de l'embarqué, surtout de l'embarqué critique, il peut exister des choses qui ne peuvent être écrites qu'en asm.

Quoiqu'il en soit PEBKAC à l'auteur qui fait du très mauvais esprit en comprenant (volontairement ?) de travers la phrase de son collègue. J'aurais du mal à croire que l'auteur ait pu sincèrement interpréter la remarque comme ça...

il ne faut pas non plus oublier qu'il est en apprentissage (en classe)

Sauf raison réellement valable, il a réellement du temps à perdre. Surtout quand on a accès au code ASM après compilation (d'accord, pas humainement compréhensible, certes, mais ça se fait (un TP d'ASM en guise de preuve :D ))

Un gros PEBKAC à benlaug, qui n'a certainement jamais programmé de sa vie un système digne de ce nom pour oser affirmer pouvoir tout maîtriser avec le C.

Car c'est effectivement le hasard des chaînes de compilation qui bâtit les programmes. Celles-ci réservent souvent de mauvaises surprises aux programmeurs système, parce qu'elles en font trop (mécanismes sous-jacents du langage) ou bien pas assez (fonctions du processeur inaccessibles).

Il s'apercevra de son erreur après quelques années d'expérience.

Un gros "C'est toi le PEBKAC" à l'auteur principalement à cause des trois dernières lignes de mauvais esprit...

En effet, tu peux être un maître du C, si le compilateur n'en fait qu'a sa tête, tu auras un code de merde. L'ASM est le seul moyen d'être certain du code final et de "savoir ce que l'on fait"

Ca me rappelle un projet (en langage C) à l'école d'ingé, où on devait utiliser des signaux pour qu'une action dans un processus déclenche une autre action dans un autre processus (les joies des SIG_USR...). Le même code source fonctionnait très bien sur certaines machines et envoyait des segmentation fault à tout va sur d'autres.
Toutes les machines utilisaient gcc pour compiler, les seules différences c'étaient le hardware (évidemment) et la distrib linux qui tournait dessus.

@Acorah : « la distrib linux qui tournait dessus. » Pas la même distro = pas forcément la même version de la libc et de gcc = des effets de bords potentiellement pas géré de la même manière ?

"des effets de bords potentiellement pas géré de la même manière" = "au moins, en Assembleur on sait ce qu'on fait"

Et PEBKAC à benlaug dont la dernière phrase laisse fortement penser qu'il ne connait pas la différence entre un langage compilé et un langage assemblé.

Evidemment, tous les mecs qui ont voté "c'est toi le PEBKAC" sont des experts en au moins un langage ASM qui surpassent largement les gens qui écrivent des compilateurs C (qui sont des tocards, c'est évident).

Pour moi c'est un "Bel exemple de PEBKAC", surtout que "Je code en ASM parce que je suis trop 1337 pour faire du C" c'est le genre de choses qu'on ne dit vraiment que pour frimer.

Si benlaug est bien le même benlaug que celui qui est en sciences info à l'ULg, il faut savoir que le projet à réaliser dans le cadre du cours de systèmes enfouis est un système embarqué (... forcément) simple qui se base sur un microcontroleur du genre PIC16F87. Coder son projet en assembleur est tout à fait légitime lorsqu'il s'agit de respecter des contraintes de temps très strictes et qu'il faut connaître le temps exacte d'exécution du code (je pense notamment à la génération d'un signal PAL). J'ai vu quelqu'un avoir des problèmes à cause du compilateur qui n'optimisait pas bien son code.

Intéro écrite (à faire en C, C++ ou même C#) :

Que vaut i et j à la fin de la boucle?
int i = 0;
int j = 0;
while ((i++) < 2)
j++;

Et avec ce code?
int i = 0;
int j = 0;
while ((++i) < 2)
j++;

c'est vrai que pour les PICs, en ASM, on gère le temps de gestion du code, à condition d'éviter les calculs avec virgules (ou je ne sais plus quelles caractéristiques un peu bizarre), et là, on peut gérer le temps d'éxécution du code au front d'horloge près (avec l'horloge à 20 Mhz, c'est précis)

@shin:
Si tu lis bien le texte du pebkac c'est de l'embarqué il ne s'agit pas de faire une appli Windows en ASM pour avoir l'air plus "1337"...
Tu dis qu'il faut avoir du temps à perdre ? Utiliser du C pour programmer un PIC je ne crois pas que ça fasse gagner beaucoup de temps (au contraire...)
Ce serait intéressant que benlaug revienne nous dire plus tard si son projet en C a été fini plus vite et/ou plus facilement que celui de son collègue en ASM ;-)

@BSK : Oui c'est ce que je pense aussi avec le recul (plus de place dans mon commentaire et la flemme d'en remettre un pour ça).


@Shirluban : Un jour en entretien pour un stage on m'a demandé ce que je pensais d'une ligne du genre "i++ + ++i - i-- - --i;" (pour ceux que ça intéresse la bonne réponse était évidemment "c'est quoi cette horreur ?"). D'après le technicien le résultat dépend du compilo.


@nigaudouille : L'info ne serait utile que s'ils avaient tous les deux exactement le même niveau en programmation et qu'ils pensent de la même façon, ce qui a peu de chances d'être le cas :/

@shin : Sache que l'optimisation d'un code n'est pas calculable. C'est à dire que quelque soit l'intelligence du gars qui a créée le compilateur. Toi avec tes petites mimines, tu peux faire mieux que le code généré par ce dernier.
Un autre exemple sur une pic (sans timer ou alarme) je veux faire clignoter à temps régulier un truc en même temps que la personne rentre une chose aux clavier. Tout les 50 instructions asm j'inverse la pin 4 de ma portA. (pas de thread - pas d'ordonnanceur)
Je fais comment en C ?


@Acorah : il me semble que ce genre d'horreur est bien définit dans la norme ansi.

@but2ene : Ca m'a étonné aussi, vu que normalement y a des règles pour définir les pré et post incrémentations. Après est-ce que tous les compilos respectent bien les règles ? On peut se poser la question (par exemple regardez le css, c'est un peu l'exemple extrême mais l'état d'esprit est là).

@Acorah : tout les compilo avec la norme Ansi ou Cxx normalement oui (enfin quand il se disent la respecter). Mais beaucoup ne le sont pas.

On est d'accord que le C est plus simple et plus rapide à programmer.
Mais désolé de te dire benlaug que ton camarade a raison, en ASM tu sais exactement ce que va faire ton proc'. Alors qu'en C tu est plus haut level alors à moins d'être une brute et de connaitre TOUTES les fonctions du C et leur fonctionnement sur le proc', tu ne sais pas exactement ce que tu exécutes comme commande. S'il sais bien programmer son SE sera mieux optimiser que le tiens

Je pense surtout que tu n'as pas compris ce que voulais dire ton camarade. Donc tu mérite amplement la pluie de "C'est toi le PEBKAC" :-p