Projet électronique actuel : encore un sens ?

[Sethy]

Quand on voit l'évolution des PCs et des languages : Java, C#, .NET, ... on ne peut que se rendre compte que la tendance est clairement à s'éloigner du matériel le plus possible. Les ordis sont devenus tellement puissant qu'on se faut de cette gabegie. Sur mon C-64, j'avais un traitement de texte qui tenait dessus avec moins de 64k de ram disponible. Maintenant pour faire tourner un traitement de texte, il en faut 1000x plus !

Par contre pour les micro-controleurs, je persiste. Un bon programmeur ASM tirera de bien meilleure performance de son HW qu'un bon programmeur en C.
-----

[invite936c567e]

Et c'est la ou je ne suis pas d'accord avec toi non seulement il faut être un bon programmeur en ASM pour gagner en efficacité par rapport a un compilateur C mais en plus les compilateurs améliorent de plus en plus leurs algorithme de sorte d'optimiser le code asm généré alors oui dans la théorie l ASM l'emporte mais dans la pratique il faut être bon, se prendre la tête pour au final s'apercevoir que le gain de performance est dérisoire par rapport au C enfin c'est ce que j'ai pu me rendre compte dans tout les projets que j'ai pu voir jusqu'à présent.

L'argument consistant à comparer le travail d'un compilateur C avec celui d'un mauvais programmeur en assembleur est fallacieux.

Dans la même veine, on pourrait affirmer que l'assembleur permet de faire des programmes plus longs que le C, parce qu'un programmeur en assembleur travaille beaucoup plus vite qu'un programmeur en C qui a perdu les clés de son bureau et qui reste à la porte sans pouvoir travailler...

Plus sérieusement, un programmeur qui n'est pas bon en C ne fera pas non plus de programmes efficaces, même avec les meilleures optimisation de compilation du monde. L'optimisation permet d'améliorer la traduction du code pour une plateforme donnée, mais en aucun cas elle ne modifie les algorithmes ni corrige les erreurs de conception.


Quand on connaît un temps soit peu son métier, on arrive toujours à faire des programmes plus efficaces en compacité et rapidité en assembleur qu'en C, quelles que soient les fonctions avancées du compilateur. On fait également en assembleur certaines choses impossibles à réaliser en C... sinon au travers de librairies écrites en assembleur.


Pour prendre un exemple récent, j'ai réalisé la semaine dernière un programme en assembleur pour un micro-contrôleur à partir d'un programme C qui n'atteignait pas les contraintes fixées (rapidité, compacité du code, utilisation de la mémoire) malgré tous les outils d'optimisation automatiques que j'ai pu mettre en oeuvre pour y parvenir. La réécriture du programme C « générique » d'origine et la modification des options de compilation avaient permis dans un premier temps permis de quasiment diviser par deux la taille du code et le temps d'exécution, mais cela ne suffisait pas. Après avoir essayé tous les outils dont je disposais (et ils sont pour la plupart excellents), les meilleurs optimisations obtenues ont permis de les baisser de 25%, mais c'était encore insuffisant. Finalement, la réécriture manuelle et optimisée en assembleur m'a permis de les abaisser encore de 30%, et d'atteindre ainsi largement mes objectifs (j'ai même dû insérer une flopée de NOPs, comme quoi il y a maintenant de la marge)...

J'ai pu ainsi implémenter une fonction qui, pour certains, était irréalisable avec le matériel indiqué, et à les croire aurait nécessité l'emploi d'un circuit trois ou quatre fois plus cher et un investissement dans un nouveau système de développement.


Toutefois, il serait parfaitement absurde d'opposer par principe les deux langages, car l'emploi de chacun d'eux trouve naturellement sa justification dans les objectifs à atteindre (type de programme réalisé, environnement, performances visées, budget et durée impartis, portabilité...). Il faut simplement ne pas se tromper d'outil quand un travail se présente.

[invite40805967]

Tu ma quand même obligé d'aller chercher la définition du mot fallacieux c'est pas cool

Oui ce n'est pas un algorithme de compilation qui va corriger des erreurs de conception c'est clair.

Par curiosité quel chose arrive tu à faire en ASM que tu n'arrive pas à faire en C?

Si je te demande le programme en C et le programme en ASM ainsi que ton compilateur j'en demande un peu trop?C'était pour quel type d'application et quel PIC/quartz était utilisé?Ca m'intéresse de trouver un contre-exemple et de l'étudier dans ses moindres détails.

[invite936c567e]

Par curiosité quel chose arrive tu à faire en ASM que tu n'arrive pas à faire en C?

En tout premier lieu toutes les opérations des unités internes des microprocesseurs et microcontrôleurs qui sont réalisées par des instructions spécifiques. Il y a aussi les traitements sur les entités logiques ou matérielles que le C ne peut pas correctement ou pas assez efficacement manipuler, parce qu'il a la fâcheuse tendance à les ignorer ou à ne les considérer que comme de la mémoire (puisqu'au fond, il ne connaît que ça). Je peux aussi citer les cas où l'un des objectifs est de respecter des temps d'exécution strictement définis, ce que le langage C est parfaitement incapable de spécifier au niveau de la programmation.

Si je te demande le programme en C et le programme en ASM ainsi que ton compilateur j'en demande un peu trop?

Oui, c'est un peu trop. Là on entre dans le domaine de la protection de la propriété intellectuelle et du secret industriel.

C'était pour quel type d'application et quel PIC/quartz était utilisé?

L'application est dans le domaine du traitement du signal. Il s'agit d'un µC à architecture AVR, cadencé à 120 MHz.

Par exemple, l'un des problèmes consistait dans le principe à exécuter, dans un temps minimum défini, trois boucles imbriquées, alors que chacun des retours de boucle durait plus longtemps que le temps restant disponible entre chaque itération. Ça donnait quelque chose comme :

for (i=0;i<imax;i++) {
	jmax = t1[i];
	t3 = t2[i];
	for (j=0;j<jmax;i++) {
		n = t3[j];
		for (k=0;k<8;k++) {
			r = traitement(n, k);
			synchronisation();
			transfert(r);
		}
	}
}

L'optimisation automatique a permis de régler le retard de la boucle « for (k=...) », mais chaque nouvelle boucle « for (j=...) » faisait rater une synchro, et chaque nouvelle boucle « for (i=...) » faisait rater deux synchros.

[invite936c567e]

Oups... ce n'est que l'horloge qui tourne à 120 MHz. Le µC est cadencé à 60 MHz.

Et il faut lire j++ au lieu de i++ dans la seconde boucle for(...).

[invitea613d208]

la différence de temps est minime et non critique pour du temps réel

Je ne suis pas daccord. Si cela etait vrai les Systemes embarqués dit "Temp reel" n'écrirait pas leurs noyau en ASM. IL faut garder à l'esprit qu'en ASM on connait le temps d'exectution de chaque instruction (en cycle d'horloge). En ASM on peut prevoir !

[invite936c567e]

... Je peux ajouter que le problème que j'ai indiqué ci-dessus a été résolu en brisant partiellement la structure de boucles imbriquées afin de dupliquer et développer certaines itérations. Le temps gagné en allongeant le programme a été mis à profit pour insérer en parallèle avec les itérations un pré-traitement morcelé des boucles, morceaux recollés dans le faible temps imparti et sans consommer de ressources supplémentaires en utilisant des particularités du µC. Cette partie du code a été globalement rallongée, mais la longueur de code perdue a été regagnée sur d'autres parties du programme.

Pour générer cette routine en C, il aurait fallu écrire un code encore plus long que le code assembleur, utiliser un compilateur particulier (voire en réécrire un avec une passe d'optimisation spécifique) en insérant de nombreuses directives de compilation, et aussi certainement ajouter quelques instructions "goto"... bref, monter une usine à gaz, en subissant tous les inconvénients du C sans tirer partie de ses avantages, et sans vraiment être sûr d'en voir le bout.

En assembleur, cette partie-là a été réglée en moins d'une demi-heure.

[invite40805967]

Bon c'est vrai que pour cadrer parfaitement mon temps je rajoute des nop dans mes programmes en C.Mais tu vois je ne pensais pas qu'une boucle for te ferait perdre plus de temps que prévu au temps pour moi faudrait que je m'intéresse à l'algorithmique des compilateurs si vous avez un site dédié à cela je suis preneur

[Sethy]

Bon c'est vrai que pour cadrer parfaitement mon temps je rajoute des nop dans mes programmes en C.Mais tu vois je ne pensais pas qu'une boucle for te ferait perdre plus de temps que prévu au temps pour moi faudrait que je m'intéresse à l'algorithmique des compilateurs si vous avez un site dédié à cela je suis preneur

Je ne comprends pas bien la logique. Pourquoi s'intéresser aux compilateurs qui sont encore plus complexes que l'étude de l'assembleur (et tout aussi particulier à chaque hardware).

[invite40805967]

L'assembleur n'est pas si difficile que ça personnellement je trouve que JAVA EE est un langage des millions de fois plus dur que l'assembleur.L'intérêt d'étudier un compilateur est justement de voir l'optimisation faite pour la traduction d'un langage de haut niveau vers l' ASM donc voir réellement si l'ASM est encore utile autrement que pour l'insertion d'instruction nop.
L'assembleur était justifié dans ton projet parce que tu avais un cahier des charges définis dans un projet existant (donc un cahier des charges contraignant) je me demande simplement si pour la réalisation d'un projet de a à z l'ASM est encore utile donc voir la performance des algorithme de compilations.

[invite936c567e]

L'assembleur n'est pas si difficile que ça personnellement je trouve que JAVA EE est un langage des millions de fois plus dur que l'assembleur.

Cette remarque tendrait à prouver que tu ne connais pas assez l'assembleur (les assembleurs) et les démarches de développement qui mènent à son utilisation.

Le langage Java est différent, mais néanmoins beaucoup plus simple à manipuler, et infiniment plus limité en ce qui concerne les possibilités de réalisation.

En assembleur, la moindre réalisation demande force réflexion et travail. Mais en contrepartie on peut absolument tout faire. On peut notamment contrôler la taille et le temps d'exécution du code, la taille et la localisation des informations (et pas seulement en mémoire) et les unités matérielles jusque dans leur moindre détail.

En Java on ne contrôle rien de tout cela. On se limite à utiliser ce que les librairies et la machine virtuelle mettent à notre portée. Et il est absolument impossible de développer un logiciel en partant de zéro.

L'intérêt du langage Java réside principalement dans sa capacité à décrire rapidement et simplement des concepts avancés, et à profiter d'un nombre important de librairies déjà développées par la communauté Java ainsi que d'une (relative) portabilité vers d'autres plateformes. C'est bien, mais c'est très insuffisant pour répondre à tous les besoins en terme de développement informatique.

L'intérêt d'étudier un compilateur est justement de voir l'optimisation faite pour la traduction d'un langage de haut niveau vers l' ASM donc voir réellement si l'ASM est encore utile autrement que pour l'insertion d'instruction nop.

Je pense que si tu maîtrisais suffisamment l'assembleur pour pouvoir exprimer le point de vue précédent (que je conteste), tu saurais déjà comment faire les optimisations d'un compilateur C, dont la démarche ne représente finalement qu'une toute petite partie du travail que réalise naturellement le programmeur en assembleur. Et tu n'aurais donc pas posé la question.

L'étude et la pratique approfondies de l'assembleur te seraient infiniment plus profitable que de tenter d'étudier le fonctionnement d'un compilateur performant... dont la justification et la compréhension devront de toute manière passer par une bonne maîtrise préalable de l'assembleur (ou plutôt du langage machine) si tu n'as personne sous la main pour t'expliquer les détails.

L'assembleur était justifié dans ton projet parce que tu avais un cahier des charges définis dans un projet existant (donc un cahier des charges contraignant) je me demande simplement si pour la réalisation d'un projet de a à z l'ASM est encore utile donc voir la performance des algorithme de compilations.

Comme je l'ai indiqué plus haut, le compilateur d'un langage évolué, même parfaitement optimisé, ne remplace en aucune manière l'assembleur.

Et si tu utilises C, Java ou Ada, c'est également parce que le projet l'exige, pour des raisons bien évidemment différentes... ou alors c'est simplement un choix par défaut, résultant du fait que le projet est mené ou réalisé par des gens qui n'ont pas les compétences requises pour juger des moyens optimums ou pour mettre ces derniers en oeuvre (je constate malheureusement que c'est trop souvent le cas).

Les impératifs de performance peuvent justifier le recours à l'assembleur, seul ou en accompagnement d'un langage évolué. Mais c'est loin d'être la seule raison.

Par exemple, la prise en compte des risques liés à la qualité, la pérennité et les possibilités supposées des outils de développement et de la plateforme cible en est une autre. Cela permet d'augmenter la maîtrise du développeur sur son logiciel et réduire l'emprise parfois mortifère que les éditeurs ont sur lui et sur ses clients (c'est d'autant plus vrai que lesdits éditeurs sont économiquement puissants et techniquement peu réactifs, à l'image de Microsoft par exemple).

Et sans même parler des risques dans le projet, bien plus souvent une simple question de faisabilité technique immédiate justifie d'y avoir recours.

[invite40805967]

Ne confond pas java et java EE. Java est un langage beaucoup plus facile que l'assembleur mais java EE est beaucoup plus compliqué à mon sens c'est le langage le plus dur qui soit.
L'assembleur une fois que tu connais les registres c'est pas compliqué c'est toujours les mêmes instructions c'est comme de l'eau à 16 degré le tout c'est de rentrer dedans une fois que tu y es ça passe.

Java EE entre les managed bean les EJB toutes les classes de log de gestion d'exception et la connexion aux bases de données et autre c'est un merdier pas possible c'est quand même franchement plus compliqué que l'assembleur y'a pas photos.

Idem tu confond ceux pourquoi ces langages sont déstinés : l'assembleur c'est de la programmation système, java EE c'est du web.

Je sais très bien programmer en assembleur le truc c'est que je préfère de loin travailler en C qu'en assembleur (j'ai plusieurs gros projet en tête pas envie d'y passer des plombes en développement) d'où ma question de savoir l'algorithme des compilateurs actuels voir si c'est optimisé ou non.

[bobflux]

Toutefois, il serait parfaitement absurde d'opposer par principe les deux langages

Ton exemple est pertinent : on écrit d'abord le programme complet en majorité en C, puis on optimise les points critiques en assembleur, si nécessaire.

Par curiosité quel chose arrive tu à faire en ASM que tu n'arrive pas à faire en C?

Par exemple sur un 8 bits (AVR) doté d'une instruction MUL, si tu veux faire un peu de virgule fixe, comme multiplier un entier de 12 bits avec un entier de 12 bits, l'assembleur est avantageux, en général plus efficace que le C, et l'optimiseur du compilo C ne repère pas les choses qui sont dans ta tête mais pas dans le code, comme "les 2 opérandes font 16 bits mais il n'y a que 12 bits non nuls dedans, donc on a un résultat de 24 bits et non 32, et accessoirement je garde seulement les 16 MSB pour aller plus vite, donc on peut dégager quelques MUL". Une petite fonction en ASM te donne une grosse accélération, par adaptation du code à un cas bien particulier. Ensuite on utilise la fonction en question dans le reste du code, écrit en C.

Évidemment sur un Cortex-M0 qui a un MUL32x32 efficace en hard, ce genre d'acrobatie est inutile (mais il y a toujours des raisons de mettre un peu d'asm).

[invite936c567e]

Ne confond pas java et java EE. Java est un langage beaucoup plus facile que l'assembleur mais java EE est beaucoup plus compliqué à mon sens c'est le langage le plus dur qui soit.

L'assembleur une fois que tu connais les registres c'est pas compliqué c'est toujours les mêmes instructions c'est comme de l'eau à 16 degré le tout c'est de rentrer dedans une fois que tu y es ça passe.

Java EE entre les managed bean les EJB toutes les classes de log de gestion d'exception et la connexion aux bases de données et autre c'est un merdier pas possible c'est quand même franchement plus compliqué que l'assembleur y'a pas photos.

Ce n'est pas parce qu'on est dans la rubrique « Électronique » que l'informatique m'est inconnue, bien au contraire. Si je me permets d'en parler ici, c'est aussi parce que j'exploite et que je maîtrise les langages dont on a parlé, et le développement informatique plus généralement, depuis plusieurs décennies déjà. Java EE en fait partie, et franchement ce n'est pas ce que j'ai rencontré de plus compliqué (si tu avais dû faire ce dont tu parles dans des langages bien moins appropriés, tu serais certainement d'accord avec moi).

Concernant la comparaison, même si j'y ai pensé je n'ai pas vraiment distingué le langage proprement dit (c'est-à-dire la syntaxe, les mots-clés et leurs usages) et les librairies mises à disposition, parce que mon propos reste valable qu'on le fasse ou non.

Mais si tu tiens à parler spécifiquement de Java EE (c'est-à-dire de Java flanqué d'un certain nombre de librairies et de spécifications normalisées), et considérer ainsi que les librairies font partie des éléments du langage plutôt que de sa pratique, alors dans la comparaison il faut également que tu considères qu'on fait aussi la même chose en assembleur.

En effet, une fois que tu connais les registres en assembleur, tu te retrouves encore à des lieues de pouvoir extraire une racine carrée ou déduire un logarithme (surtout si l'ALU ne possède pas d'opérateur de multiplication), effectuer des calculs en virgule flottante IEEE 754, monter une pile TCP/IP, implémenter un protocole logiciel ou matériel, faire travailler des unités en parallèle...

Ce n'est pas parce qu'on peut tout faire en assembleur, qu'il faut chaque fois tout refaire, depuis les specs.

Idem tu confond ceux pourquoi ces langages sont déstinés : l'assembleur c'est de la programmation système, java EE c'est du web.

Je ne confonds pas, et j'ai même pris la peine de rappeler qu'il était absurde d'opposer les langages parce que leur choix dépendait du projet à réaliser.

Cela dit, on peut aussi faire de la programmation système en Java (du moins une partie), et de la programmation web en assembleur (tant du côté serveur que du côté client).

Je sais très bien programmer en assembleur le truc c'est que je préfère de loin travailler en C qu'en assembleur (j'ai plusieurs gros projet en tête pas envie d'y passer des plombes en développement) d'où ma question de savoir l'algorithme des compilateurs actuels voir si c'est optimisé ou non.

Je pense plutôt que tu as appris quelques bases en assembleur, ce qui te donne la fausse impression de savoir programmer.

Malheureusement, comme dans la plupart des métiers, ce n'est qu'après plusieurs années de pratique qu'on acquiert les réflexes, les connaissances, le savoir-faire, bref la maîtrise, qui font toute la différence entre le bricolage de débutant et la pratique réelle d'un art industriel.

Pour une entreprise, embaucher un débutant, c'est avant tout perdre de l'argent, en faisant le pari que les choses s'amélioreront assez rapidement pour faire un retour sur cet investissement positif. Toutefois ça n'est pas toujours le point de vue des SSII, qui gagnent dès la première seconde de travail même si le missionnaire s'avère complètement incapable.


Comme je me tue à le répéter, on ne peut pas sérieusement faire en C ce qu'on fait en assembleur. Et une optimisation automatique d'un langage évolué, ça ne servira jamais plus qu'à faire des améliorations limitées, jamais plus qu'à « rendre mieux que si c'était pire ».

Si vraiment cette question te turlupine, alors contacte directement l'éditeur de ton compilateur afin qu'il te fournisse les spécifications de la passe d'optimisation et un support technique avancé à son sujet (Intel le faisait il y a quelques années pour les entreprises travaillant sur des projets pointus, dans l'aéronautique notamment). Mais attends-toi à devoir casser ta tirelire. Tu pourras ainsi constater par toi-même l'exactitude de mes propos.

[invite936c567e]

Envoyé par PA5CAL
Par curiosité quel chose arrive tu à faire en ASM que tu n'arrive pas à faire en C?

Heu... il y a maldonne. C'est une citation de sin92 .

[invite40805967]

Après ca ne reste que ma vision des choses.(quand je parle de langage je parle de tout le contexte : pour l'assembleur ce sera les registres qui vont avec donc l'architecture du système et concernant java EE comment fonctionne un projet avec tout les beans de session, toutes les librairies, + le html/css/xml + JSF/servlet en fonction de la technologie utilisée + primeface/richface/autres si besoin d'une interface IHM améliorée).Maitriser java EE m'a demander beaucoup plus de temps que l'assembleur.

Concernant les logarithme ou extraire une racine carrée ca relève plus des mathématiques et de ta capacité d'analyse que du langage proprement dit idem pour les fonctions de plus haut niveau (protocoles etc).

Je pourrais programmer en assembleur cependant comme je te l'ai dis mes projets ne nécessite pas une optimisation de malade (je suis en train de concevoir un robot "intelligent" muni d'une caméra et d'autres trucs, un système de détection de présence, un système permettant de retrouver le code source d'un µC) je préfère de loin y gagner en rapidité de développement beaucoup plus éducatif à mon sens.

Mais je reste mitigé j'essaye juste de me faire mon propre avis j'ai eu affaire à deux sortes de gens compétents m'affirmant des choses contradictoires :

- ceux qui disent que l'assembleur est plus rapide que les autres langages, et que donc c'est LE langage quand on veut faire de l'embarqué.
- et ceux qui disent que les compilateurs commencent à devenir plus "intelligents" que la moyenne des programmeurs ASM, et que du coup la différence de rapidité ne se voit même plus et qu'il est par conséquent inutile de développer en ASM.

A vrai dire les deux hypothèses me semblent valable d'où mon idée de voir comment est compilé un code C (par exemple) afin de me faire ma propre opinion sur la chose.Et la pour l'instant c'est vrai que tu possède de bons arguments mais ça ne remplace pas une démonstration complète.

[invitee05a3fcc]

A vrai dire les deux hypothèses me semblent valable d'où mon idée de voir comment est compilé un code C (par exemple) afin de me faire ma propre opinion sur la chose.

Sauf erreur de ma part, les outils de développement permettent de voir en ASM le code machine compilé. Donc, si tu connais bien l'ASM du µC que tu programmes en C, tu peux voir les aberrations du compilateur !

[invite40805967]

Tout à fait je peux voir comment sont compilés mes différentes instructions : while,for,appel de fonctions...C'est d'ailleurs comme ca que j'ai regarder comment étaient traduites les premières briques mais ça me semble trop simple pour un compilateur intelligent.

La ou j'aimerais en savoir un peu plus, c'est pour les gros programmes : le compilateur lit il le code source une première fois pour ensuite optimiser le code?(utilisation d'un minimum de variables, ou bien n'importe quoi par exemple le compilateur voit que la fonction X n'est appeler qu'une seule fois il n'effectue aucun CALL en assembleur).

C'est cette optimisation que je voudrais regarder.

[invite936c567e]

Maitriser java EE m'a demander beaucoup plus de temps que l'assembleur.

Sauf que la question que tu poses prouve à l'évidence que tu es encore très loin de maîtriser la pratique de l'assembleur. Sinon tu aurais déjà tenté au moins une fois de faire de l'optimisation d'un langage évolué, qui est l'une des applications courantes de cet outil.

Par ailleurs je te laisse imaginer le temps qu'il t'aurait fallu pour apprendre à faire en assembleur tout ce que tu as réalisé en Java EE, par exemple parce que le produit réalisé aurait été soumis à un impératif de vitesse ou de compacité, ce qui arrive très souvent dans les domaines industriels.

Concernant les logarithme ou extraire une racine carrée ca relève plus des mathématiques et de ta capacité d'analyse que du langage proprement dit idem pour les fonctions de plus haut niveau (protocoles etc).

Avec un tel point de vue, tu peux tout aussi bien considérer que toute l'informatique relève des mathématiques pures. C'est d'ailleurs le point de vue avancé dans certaines approches qui mène notamment aux langages de spécification formelle.

Mais je parlais bien ici de la seule réalisation des logiciels au travers de librairies de codes existants. La démarche que tu sembles trouver spécifique au Java EE existe également en assembleur. Quand on a un logarithme à calculer, on choisit l'une des librairies assembleur disponibles en fonction de l'adéquation entre d'une part leurs spécifications propres (taille du code, vitesse d'exécution, ressources matérielles utilisées et réservées) et d'autre part les besoins à remplir et les contraintes à respecter. De même quand on implante une couche réseau Ethernet, une pile TCP/IP, un protocole HID USB, un encodeur MPEG 4 ...

Mais je reste mitigé j'essaye juste de me faire mon propre avis j'ai eu affaire à deux sortes de gens compétents m'affirmant des choses contradictoires :
- ceux qui disent que l'assembleur est plus rapide que les autres langages, et que donc c'est LE langage quand on veut faire de l'embarqué.
- et ceux qui disent que les compilateurs commencent à devenir plus "intelligents" que la moyenne des programmeurs ASM, et que du coup la différence de rapidité ne se voit même plus et qu'il est par conséquent inutile de développer en ASM.

Aussi surprenant que cela puisse paraître, les deux ont un peu raison.

C'est un peu comme entendre dire que le feu au carrefour est vert, et aussi entendre dire qu'il est rouge. Ce n'est pas nécessairement antinomique.

En fait la contradiction n'est qu'apparente car elle ne concerne pas les même situations.

L'assembleur reste bien LE langage pour spécifier un code soumis à des impératifs de temps d'exécution, de taille de code et d'utilisation de ressources matérielles, parce qu'aucun autre langage n'est capable d'exprimer ces spécifications. Il est absolument obligatoire pour décrire les couches logicielle les plus basses, celles qui pilotent directement le matériel.

Et on se garde bien de rappeler que le code généré par les compilateurs des langages évolués (directement, au travers des librairies et/ou après quelques passes d'optimisation automatique) a dû préalablement être décrit en assembleur. Ce n'est généralement pas le programmeur qui l'a fait, mais ça a forcément été fait un jour par quelqu'un.


Mais il est inutile de programmer un applicatif ou une couche intermédiaire d'un système en assembleur si les contraintes ne sont exprimées qu'en terme de limites que l'outil de développement et la plateforme cible permettent d'atteindre.

En fait même l'embarqué n'implique pas toujours des contraintes qui imposent le recours à l'assembleur, et l'«intelligence» des compilateurs est souvent largement suffisant pour répondre à ces contraintes.

[invite936c567e]

... Mais dans l'absolu, l'assembleur n'est pas inutile.

L'assembleur n'est pas mort, loin de là. Ceux qui le prétendent n'en ont simplement pas besoin, et oublient qu'ils ne sont pas les seuls sur terre, et que leur travail dépend beaucoup de celui des autres.

Ça me fait penser à une autre discussion à propos de l'électronique numérique, qui aurait soi-disant totalement remplacé l'électronique analogique...

[invite936c567e]

Tout à fait je peux voir comment sont compilés mes différentes instructions : while,for,appel de fonctions...C'est d'ailleurs comme ca que j'ai regarder comment étaient traduites les premières briques mais ça me semble trop simple pour un compilateur intelligent.

La simplicité n'est qu'apparente. Pour y voir une quelconque démarche intelligente, il faudrait par exemple comparer ce qu'un compilateur non optimisé aurait généré comme code, et l'impact de ce dernier sur les différents postes de performances.

La ou j'aimerais en savoir un peu plus, c'est pour les gros programmes : le compilateur lit il le code source une première fois pour ensuite optimiser le code?(utilisation d'un minimum de variables, ou bien n'importe quoi par exemple le compilateur voit que la fonction X n'est appeler qu'une seule fois il n'effectue aucun CALL en assembleur).

Il y a autant de façon de procéder que de compilateurs et de d'objectifs d'optimisation. Parce qu'il n'existe pas qu'UN compilateur, et pas qu'UNE optimisation.

Les compilateurs sérieux génèrent le plus souvent déjà un premier code, ou pseudo-code, déjà partiellement optimisé. Puis ils reprennent une ou plusieurs fois ce code durant les opérations de génération du programme afin d'en améliorer encore certains aspects.

Mais chacune de ces améliorations est réalisée dans un but précis, souvent contrôlé par des options de compilation ou des directives insérées dans le code. En effet, il arrive souvent que les optimisations en terme de taille du code, des ressources réservées et de vitesse d'exécution soient incompatibles, l'amélioration de l'un dégradant l'autre. Il faut donc choisir, et ce choix est soit réalisé a priori par l'éditeur de l'outil, soit par le programmeur qui l'utilise.

Or, le meilleur choix n'est souvent possible qu'en jugeant du détail à des endroits précis du code final, auquel le programmeur de langage évolué est justement censé ne pas accéder... sauf à tenter de programmer en assembleur avec seulement des instructions en langage évolué !

[invite40805967]

Je trouve java EE plus dur que l'assembleur mais le temps de développement d'un programme en assembleur prend infiniment plus de temps (surtout pour du web) .
Ensuite des impératifs de vitesse en web...c'est pas vraiment la question lol c'est plus le nombre de requêtes qu'un serveur peut traiter qui rentre en compte.

Oui on peut faire pas mal d'analogies avec l'analogique/numérique mais par curiosité programme tu systématiquement en ASM ou bien code tu en "haut niveau" avec certains bouts de codes en ASM?

[invite936c567e]

Ensuite des impératifs de vitesse en web...c'est pas vraiment la question lol c'est plus le nombre de requêtes qu'un serveur peut traiter qui rentre en compte.

Ça c'est la réplique typique d'un programmeur habitué aux plateformes sur-dimensionnées !

Des impératifs de vitesse, on en trouve aussi de nombreux dans le domaine du web, tant du côté serveur que du côté client.

Si par exemple tu devais réaliser une caméra IP, un petit routeur DPI ou une alarme vidéo intelligente sur réseau, tu ne dirais certainement pas la même chose.

par curiosité programme tu systématiquement en ASM ou bien code tu en "haut niveau" avec certains bouts de codes en ASM?

Il m'arrive de faire l'un ou l'autre, selon les circonstances, mais toujours après y avoir mûrement réfléchi.

[Sethy]

Pour moi, programmer en assembleur, n'a rien à voir avec penser un programme en C et l'écrire en asm. Pour ça un compilateur fera tout aussi bien.

Ecrire en assembleur, c'est choisir le banc 1 du PIC plutôt que le 0 parce qu'il existe une instruction particulière qui permet en 1 cycle sur le banc 1 d'avoir un autre effet que celui sur le banc 0. Ou qu'au contraire 5 instructions plus loin on aura besoin d'une condition présente sur le banc 0.

[bobflux]

Est-ce que c'est encore rentable d'utiliser des micros dans ce style ?

(je ne parle pas d'une réalisation amateur : dans ce cas il est évident que ce n'est pas rentable du tout, mais d'un produit qui sort de l'usine en grandes quantités).