Discussion :

[JORDYTAZ]

Bonjour,

J'ai eu programmer en assembleur il y a quelques décennies de cela à l'époque du Borland C++ 2.0.... c'est dire. Je suis donc un peu has been.

Mais il y a-t-il du développement en assembleur encore? n'y voyer pas de médisances bien au contraire. Si oui, est-ce uniquement pour des drivers? ou existent-ils des "battles" de codage en assembleur (dites-moi oui, pour le plaisir de savoir que l'on taquine encore les microprocesseur de cette façon).

Merci EQU "merci à tous".

Serge

[droggo]

Bonjour,

Oui, on en fait encore.

Mais il faut l'avouer, de moins en moins, et uniquement pour ce que les compilateurs des autres langages ne savent pas faire.

En exemple, il est à peu près inutile de l'utiliser pour essayer d'optimiser, les compilateurs nous battent les doigts dans le nez pour ce boulot.

Mais pour du calcul multi précision, assembleur obligatoire, sinon grosse perte de vitesse due au compilateur qui ne sait pas faire ce genre de truc de manière efficace.

J'espère que ça te fait plaisir ...

J'ai également fait du Borland au tout début, et j'ai même programmé les simples cartes sur lesquelles il n'y avait qu'un clavier 16 touches + 1 [Enter]) et 2 afficheurs 7 segments, et sur lesquelles on pianotait le code exécutable en hexa, code qu'il fallait avoir "compilé" à la main.
Mais au moins, après ça, on sait ce qu'est un processeur.

[Kannagi]

Je programme souvent en assembleur niveau hobbie , je trouve peu d’intérêt de coder de l'asm sur PC parce que comme dit avant les compilo sur cette plateforme sont très efficace (après personnellement j'ai jamais aimé le x86 ).

Je change d'assembleur comme de chemise , je programme pas mal sur la Super Nes ( un 65816 , un dérivé 8/16 bits du 6502 , en gros le même que la Nes ou Apple II !).
Je programme sur la Neo Geo en C/ASM , bref du M68000 comme on les aime dans les années 80/90 (donc le même que l'Atari St et l'Amiga etc etc).
Et sur Dreamcast/PS2 (SH4 et un MIPS + les VU qui sont un asm particulier) aussi pour le rendu 3D (et faire de l'asm + 3D c'est sportif, surtout que ce sont des processeurs moderne in order donc bien plus complexe à optimiser que sur un x86).
Mais j'ai programmer sur pas mal d'autre machine/proc du Z80 (bidouiller sur Master system et Game boy), la PC engine et la Nes (du 6502) , un peu Atari ST,de la mega drive (M68000).
Et de la PS1 (du MIPS encore) , et de la GameCube/Wii (du PowerPC).
Et quelque foisde ARM (Raspi et GBA).

Si vous voulez voir quelque rendu :
SNES:

Neo Geo:

PS2:

[Guesset]

Bonjour,

Effectivement les compilateurs font du bon travail, d'autant meilleur que les algorithmes sont bien conçus et bien implémentés. Mais, il n'utilisent qu'une partie des codes op du CPU. Si nous sommes dans un cas où leur usage est adapté et que le besoin de performances est non satisfait, l'assembleur est utile voire indispensable.

Les microcontrôleurs, avec leur faibles ressources (même si c'est de moins en moins vrai) et leurs possibilités d'accès direct à celles-ci, sont un terrain d'excellence pour l'assembleur et les langages de bas niveau.

En fait, il est très rare qu'une nouvelle technique remplace intégralement une ancienne. Elle s'y ajoute et offre un plus grand choix de solutions. Bien sûr cela diminue mécaniquement le recours aux technologies du passé. Mais cela doit être le fruit des choix raisonnés d'une solution optimale et non la peur de faire archaïque ou démodé. C'est vrai pour l'assembleur comme pour d'autres techniques.

C'était mon 1/4 d'heure philosophique .

Salutations

[droggo]

Bonjour,

Pour Kannagi : joli boulot, bravo.

[chrtophe]

Effectivement les compilateurs font du bon travail, d'autant meilleur que les algorithmes sont bien conçus et bien implémentés. Mais, il n'utilisent qu'une partie des codes op du CPU. Si nous sommes dans un cas où leur usage est adapté et que le besoin de performances est non satisfait, l'assembleur est utile voire indispensable.

Si tu prends par exemple l'opcode loop, il prend plus de temps que jcxz. Le compilateur ne l'utilisera donc pas. Le compilateur va essayer d'utiliser le code le plus efficace selon le contexte, il ne codera donc peut-être pas comme toi tu l'aurais fait.

L'assembleur sera effectivement indispensable dans certains cas, comme changer la pagination, sur Intel accéder aux registres MSR, debug, CRx, etc.

[Kannagi]

Bonjour,

Pour Kannagi : joli boulot, bravo.

Merci , juste pour montrer que l'asm ça permet de faire des trucs cool quelque fois

[Guesset]

Bonjour chrtophe,

Si tu prends par exemple l'opcode loop, il prend plus de temps que jcxz. Le compilateur ne l'utilisera donc pas. Le compilateur va essayer d'utiliser le code le plus efficace selon le contexte, il ne codera donc peut-être pas comme toi tu l'aurais fait.

Pour compléter le propos, la plupart des développeurs écrirons for(int i = 0; i <= iMax; i++) même si l'ordre de la boucle n'a pas d'intérêt. Mais je ne suis pas sûr que la plupart des compilateurs inversera l'ordre pour bénéficier d'une comparaison à 0. Aussi il vaut mieux, me semble t-il, inverser l'ordre des boucles quand c'est possible.

Ceci étant, il me semble qu'il faudrait comparer loop et jecxz + jmp car loop boucle tant que ecx est différent de 0 alors que jecxz est une sortie de la boucle à 0 (il faut donc qu'un jmp assume la boucle en cas normal). Mais je tatillonne car même ainsi la solution loop reste plus lente (de très peu cependant).

Salutations