Salut à Tous,
Je voulais savoir comment et pourquoi vous utilisez ce language de programmation, c'est à dire sous quel OS, pour quel type d'application,etc....
Salut à Tous,
Je voulais savoir comment et pourquoi vous utilisez ce language de programmation, c'est à dire sous quel OS, pour quel type d'application,etc....
Je l'utilise pas mal sous Windows ou sans OS (Pour faire des disquettes bootables). En général, sous Windows, c'est pour faire quelque chose de rapide ou de pas évident en langage évolué.
Ca m'a permi d'optimiser une routine de traitement d'image qui est passé de 30 secondes à une durée presque imperceptible pour le traitement d'une image en 1280x960...
Je n'ai fait qu'un seul vrai programme en asssembleur. Il ne fesait qu'une trantaine de lignes (Un appel a une fonction d'une dll). Bref, Delphi me le fesait en 13 Ko, la version assembleur fesait 1500 octets (Presque 10x moins)... Bon, le porgramme avec delphi fesait juste 5 lignes...
En général, développer une application directement en assembleur, c'est pas vital... Mais ca peut l'être...
Bon développement !
Pour ma part, c'est pour comprendre le fonctionnement de la machine, et savoir créer un programme de A à Z.
Thrystan.
Participez au projet d'entraide Linux : http://parrains.linux.free.fr
Cette question a déja été posée. Moi je programme un émulateur x86 en asm.
moi aussi c'est dans ce sens , comprendre les bases d'un OS etc.... et surtout dominer ce que fait le prog du début à la fin ....sans parler de l'optimisation ... c'est pour ca que je ne vois pas trop l'interet du dev en asm sous windows....Envoyé par Thrystan
Pour moi, le principal intêret est d'éviter la lourdeur et la complexité du C++ ou de Delphi. Et puis ca me rapelle un peu la programmation an BASIC sur Amstrad : la seule limite des programme est ce que l'on veux en faire.moi aussi c'est dans ce sens , comprendre les bases d'un OS etc.... et surtout dominer ce que fait le prog du début à la fin ....sans parler de l'optimisation ... c'est pour ca que je ne vois pas trop l'interet du dev en asm sous windows....
Ce qui est nettement moins le cas en C++(je le prend comme exemple mais c'est valable pour pas mal de HLL), où il faut réussir à comprendre les syntaxes tordues avant de commencer à vraiment programmer.
En fait, moi je ne vois pas trop l'intêret de dev autrement qu'en asm, sous windows
Mais dway, à mon niveau je ne sais pas programmer de programmmes interressants, mais je suis conscient que tu ne peux égaler la rapidité d'un programme en assembleur ni obtenir une si petite taille d'executable avec aucun autre langage. C'est pour ça que ce langage est indispensable dans la programmation système ou graphique.
Thrystan.
Participez au projet d'entraide Linux : http://parrains.linux.free.fr
mouais ...mais sous win t'es hyper dépendant de l'os et ses mutliples librairies donc dans ce cas autant uitiliser un HLL...Envoyé par Plaint
Je n'ai aucune notion de programmation sous Linux, mais étant donné que c'est l'OS qui gère tout le hardware, tu es bien obligé de passer par lui pour écrire une application. Je doute que ce soit si différent de Windows.
Bon en même temps, je n'en sais rien...
Les langages évolué permettent tout dee même ded programmer beacoup de choses sans les compter en heures de travail. Il y a aussi la Programmation Orientée Objet qui fait fureur (bien que je ne l'aprecie moi même guère). L'asm est tout de même affreseument impratique, et il n'y a pas de traduction idrecte d'algorithmes. En asm, on est obligé de décortiquer instruction par instructions alors, que dans les langages évolués, la structure du code immite l'algoritme, ce qui ne donne pas de gymnastique supplémentaire. Et j'aimerais ajouter aussi, qu'avec le compilateur adequat, on peut tout de même creer un executable petit, même si les plus recent ne savent pas creer des exe de moins de 1 mo...
c'est sûr que si l'on regarde d'un point de vue temps, l'assembleur n'est pas du tout rentable. de plus l'intérêt est très limité d'un point de vue applicatif puisque dans de nombreux cas ce n'est pas le langage qui fait les performances mais plutôt les algorithmes mis en oeuvre.
alors pourquoi continuer à programmer en assembleur ?
pour ma part, je veux devenir développeur, et je n'arrive pas à concevoir qu'un développeur n'ai pas fait d'assembleur. ça doit être à cause d'une certaine image (peut-être fausse) que je me fait de la programmation, où un développeur se doit de souffrir et de 'maîtriser la bête'.
et puis, l'assembleur c'est aussi un peu une auto-satisfaction. pour moi franchement je trouve vachement plus 'triquant' de faire un programme assembleur en 100h qu'un programme identique delphi en 10h. c'est quand même plus vibrant que de pauser des composants sur des fiches. ok c'est une perte de temps, mais quel bonheur quand on a fini. c'est incomparable.
et puis c'est également une histoire de passion tout simplement.
Pour ce qui est du coté peu pratique de l'assembleur, a mon avis cela dépends beaucoup du compilateur utilisé, TASM est bien pour faire de l'assembleur inline, mais ce serait fastidieux de l'utiliser pour écrire un programme entier.
Franchement vous trouvez ce code moins lisible que du C++ ?
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29 call 'Kernel32.GetModuleHandleA' 0 | mov D$hInstance eax call 'User32.CreateWindowExA', &WS_EX_CONTEXTHELP, MainWindowClassName, MainWindowCaption, &WS_VISIBLE+&WS_SYSMENU+&WS_BORDER, 0, 0, 400, 500, 0, D$MenuHandle, D$hInstance, 0 mov D$MainWindowHandle eax call 'User32.ShowWindow' D$MainWindowHandle &SW_SHOW call 'User32.UpdateWindow' D$MainWindowHandle jmp L1> While eax != 0 call 'User32.TranslateMessage' CurrentMessage call 'User32.DispatchMessageA' CurrentMessage L1: call 'USER32.GetMessageA' CurrentMessage 0 0 0 End_While call 'Kernel32.ExitProcess' &NULL
Non, et c'est pourtant de l'asm
oui un exe de petite taille .... avec 300 Mo de setup et dll derrier !!!Envoyé par Blustuff
j'suis assez d'accord avec tout ca !Envoyé par executter
mouais encore une fois j'vois pas l'interet de programmer en asm pour appeler des dll....Envoyé par Plaint
Simplement pour ne pas allourdir inutilement le code. Les compilateurs HLL, aussi optimisés soient-ils, ne produiront jamais un code aussi propre.mouais encore une fois j'vois pas l'interet de programmer en asm pour appeler des dll....
Tu vas me dire que certaines parties n'ont pas besoin d'optimisation ?
OK, alors pourquoi utiliser un HLL si on ne perd pas non plus en lisibilité.
Sinon, pour la programmation même. En C++, selon la fonction que l'on appelle (et je ne prends que les pointeurs) on doit utiliser les types de données LPBOOL, LPBYTE, LPCSTR, LPCTSTR, LPCVOID, etc...
Et mieux vaut ne pas se tromper, sinon on a droit à une erreur à la compilation.
En asm, on résume tout ça en un seul type : le DWord.
Franchement, je perds bien plus de temps en C++ qu'en asm à chercher dans la doc quel type utiliser et au lieu de bosser sur le programme lui-même.
La façon dont on programme en asm est assez différente des HLLs mais pas forcément plus difficile...
La propreté est objetive et dépends du langage, ca n'est pas un arguments en faveur de l'asm.
Je peux t'assurer pour avori recodé entièrement un code que j'avais déja ecrit en asm, ca m'a pris a peine une heure, alors qu'en asm, ca m'avait pris un nombre effroyable d'heures, et le résultat était infiniement plus lisible.
Je ne plaisante pas non plus quand je parle de retranscription d'algorithme. Pour faire apparaitre un algorithme complexe en asm, on est obligé d'inserer trois tonnes de commentaires, pour dire ce que l'on fait. Dans un langage évolué, il suffit d'utiliser les structures conditionelles et répetitives judicieusement, ainsi que des noms de variables explicites (le compilateur utilisera les registres généraux), et sans aucun commentaires, on voit d'un seul coup d'oeil l'algorithme retranscrit. C'est utile lorsque l'algorithme est très complexe, car il est beacoup plus facile de l'ecrire avec un langage évolué, et dans tous les cas, une autre personne qui viendrait lire ce programme ne l'ayant jamais vu avant, comprends très vite son fonctionement (oui ca arrive que l'on ne travaille pas seul)
En ce qui concerne, LPBOOL, LPBYTE, LPCSTR, LPCTSTR, LPCVOID, ca ca n'est pas le C++, mais l'API windows. Et rien ne t'oblige a déclarer tes variables LPBOOL. La signication est claire, tu déclare simplement un bool* . Mais si tu passe du temps a lire les docs en C++, pour savoir quoi faire, ca ne change rien en asm .Tu dois appeller la fonction CreateThread() par exemple tu es obligé d'aller voir le nom, le type et la fonction des arguments, pour savoir quoi faire.
Mais il ne faut pas s'arretter sur le code et sa lisibilité. Avec les langages évolué, ce sont des nouveaux principes de programmation. Avec la POO, vous faites une analyse, vous creez vos objets, vos arborescences, et d'après ceux qui la pratiquent, c'est plus rapide que n'importe quelle autre methode.
Dans plus en plus de domaines, c'est la rapidité a programmer qui prime sur la qualité du code (notement sa rapidité). En cela l'asm est disqualifié. Je ne connais personne qui sache faire un programme plus rapidement en asm qu'en langage évolué.
Je pense quand a moi qu il s agit tout simplement de la facon dont laquel on concoit son engouement pour la programmation
pour ma part,je ne suis et ne tient pas a etre ni informaticien ni developpeur, mais cependant je suis assez d accord avec executer ...
programmer en asm c est prendre son pied (lequel je sais pas), mais c est vrai que c est une veritable joie pour son petit ego de pouvoir ecrire un truc tout en asm meme si il ne s agit que d un jeu basique comme le pong par exple!!!
Je ne met en aucun cas en doute ce qui a ete dit sur la difficultée de faire de bon algo en asm de facon rapide en temps de developement ni meme
de la facon de penser que les compilo d aujourd huis pour les langages evolué ,font obtenir du code aussi "rapide "que ce que l on peu faire en matiere d optimisation avec l asm...(pour la taille du code obtenue c est bien moins vrai....)
de meme ecrire une grosse aplication 32bits ou meme un jeu 3d en 16bits sous dos tout en asm semble denude de bon sens...cependant j en reviens a ma premiere facon : tout depend pourquoi l on code ..
l asm 32b avec l api 20 doses est un cas particulier de l utilisation de l asm car surtout pour ceux qui utilise masm,la syntaxe se rapproche du C
et les differences ne sont pas si grande ...pour ma part je prefere utiliser l asm avec les api que le C qui me semble bien plus obscur (meme si c est completemnt en contradiction avec ce que je viens de dire!!)lol*2
cependant il est clair qu un developeur va utiliser les langages evolues pour programmer ses applications car le systeme economique est tel que tout gain de temps parait il fais gagner de l argent ( a mon grand dame car c est pas tout a fait vrai ...)
Pour la lisibiltee je pense que l on peu avoir des choses horriblement dur a lire en C/C++ vu la syntaxe de base et les possibilitées de syntaxe simplifié et je doute que tout le monde ecrive de facon si clair que tout le monde puisse comprendre tres vite de quoi il s agit ...mais je peu me tromper vu que moi le C j en comprends meme pas une ligne lol
voila les quelques banalitees que j avais a poster sur ce sujet
pour finir l important c est de "triquer" heu...enfin de prendre son pied quoi!
Ce problème n'est pas spécifique à l'asm mais est dû aux limitations de la plupart assembleurs.Dans un langage évolué, il suffit d'utiliser les structures conditionelles et répetitives judicieusement, ainsi que des noms de variables explicites
Bien sûr, en asm il n'y a pas de If, While, etc...
Mais dans la plupart des cas on peut traduire ces instructions par une suite de 2 ou 3 instructions asm.
par exemple, si on écrit en C :
SpAsm permet d'écrire la même chose de cette façon :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10 int valeur1 ; if ( (valeur1 > 5) && (valeur1 < 10) ) { // (...) } else if ( (valeur1 == 12) || (valeur1 == 17) ) { // (...) }
Et le code sera retranscrit en :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7 mov eax D$valeur1 If_And eax > 5, eax < 10 ; (...) Else_If_Or eax = 12, eax = 17 ; (...) End_If
On ne peut pas dire qu'un programmeur perde plus de temps à écrire la seconde solution que la première.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18 mov eax D$valeur1 CMP EAX 5 JNA I0> CMP EAX 10 JNB I0> ; (...) JMP I5> I0: CMP EAX 12 JE O0> CMP EAX 17 JE O0> JMP I0> ; (...) O0: IO: I5:
Pourtant la 2e solution reste bien de l'asm puisque ce sont macros qui sont utlisées et qu'aucune vérification ne sera faite.
D'autant plus que le macros ne sont pas prédéfinies.La question que je me pose, c'est pourquoi utiliser un HLL et son compilateur qui va soit alourdir le code, soit au mieux se contenter de doubler la taille du fichier final, si l'asm et un bon système de macros font exactement la même chose, sans ces inconvénients ?
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 [If_And | cmp #1 #3 | jn#2 I0> | #+3] [Else | Jmp I5> | I0:] [Else_If_Or | Else | If_Or #F>L] [End_if | I0: | I5:]
:
On peut faire pareil avec masm et nasm, c'est pas spécifique a spasm. Mais j'ai l'impression de parler a des programmeurs sans experience. En pratique on a pas toujorus a faire a des structures aussi simples, et les ... compliquent très souvent le problème. Et un langage évolué, ce ne sont pas que des structures. Ce sont des opérateurs aussi, un outil très pratique. On peut ecrire a = (3 * x + 12) / (24 * z) - y * y * 18 / 13 + z. En asm c'est beacoup plus lourd. Et encore une fois, certains langages sont orientés objets.
Autre chose, on ne dit pas ecrire un algo en asm, mais transcrire, du fait, que l'algorithme développé& ne dépend pas du langage. Cela implique qu'il n'y a rien faisable en HLL qui ne le soit pas en asm.
[Modération, Alacazam : Désolé, je tronque ici la discussion. Plus trop d'explications après ... merci de vous disputer pas MP ]
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager