Bonjour à tous, je me demandais simplement la raison pour laquelle, lors de l'utilisation de "dw" ou "dd" en x86, les deux octets représentants la valeur sont intervertis.

Un exemple dans un cours pour NASM disponible sur le site:

45 avec "dw" donne en binaire: 00101101 00000000 et donc 2D00 en hexadécimal, ce qui est incorrect (2D00 = 11520), l'inverse(00000000 00101101) serait donc plus logique, car 002D = 45...

Le cours en question: http://openclassrooms.com/courses/apprenez-a-programmer-en-assembleur-x86

Merci d'avance pour votre aide.

-
Edité par Medzebaff 8 juillet 2015 à 0:15:56

Wikipedia is your friend.

Quelqu'un ose dire va chercher toi-même sur une question sur l'assembleur oO ?! (quel comble)

Non que ton lien n'est pas intéressent, mais si une personne vient poser une question, c'est que les trucs connus comme bing et wiki ont été déjà utilisés x)

Surtout en asm où un simple lien ne suffit pas à répondre à toutes les questions.

dw = inversement des 2 octets                                    dd = Sens de lecture par l'octet du point faible.

Alors c'est tout simple, car sur proc intel (osef des autres arch), l'architecture est en Little Endian, c'est-à-dire que le proc a besoin de lire les valeurs immédiates (dans le code source) de droite à gauche.

Peut-être est-ce plus rapide pour lui de faire des opérations avec.

Par contre cela ne touche que les valeurs immédiates dans le code source (nbr, label) et non les opcodes des instructions.

Et pas que les définitions dw et dd, mais toutes: http://www.nasm.us/doc/nasmdoc3.html#section-3.2.1

Le mode du CPU n'influe en rien le résultat, c'est aussi bien valable en 16, 32, 64 bits.

-
Edité par Anonyme 8 juillet 2015 à 13:08:30

shaynox a écrit:

Quelqu'un ose dire va chercher toi-même sur une question sur l'assembleur oO ?! (quel comble)

Non que ton lien n'est pas intéressent, mais si une personne vient poser une question, c'est que les trucs connus comme bing et wiki ont été déjà utilisés x)

Eh bien visiblement non, l'auteur n'évoque même pas le mot endianness, je pense donc qu'il ne connaissait pas ce concept.

Sinon un simple lien peut répondre à beaucoup de questions, en assembleur ou non, un exemple ici.

-
Edité par Mad scientist 8 juillet 2015 à 12:43:56

C'est un comble de le faire, sachant que l'asm est plus difficile à aborder plus que tout autres langages.

Pour moi s'en est un, de comble, après  si tu as eu beaucoup de faciliter lors de cet apprentissage, tant mieux pour toi, mais pour beaucoup ont a eu du mal (surtout sans aucune aide, que des fragments de réponse parfois confuse) x)

Ne mets pas l'asm et les autres langages dans le même panier stp

Si on t’a déjà fait ce coup-là, alors tu connais très bien les répercussions psychologiques que ça a, ce genre de réponse incomplète.

Si tu veux aider quelqu'un en asm, alors habille tes wiki links d'autres savoir, comme ça, il va pouvoir faire le lien avec d'autres concepts facilement et ainsi va la compréhension.

"Eh bien visiblement non, l'auteur n'évoque même pas le mot endianness, je pense donc qu'il ne connaissait pas ce concept."

Peut-être que oui, peut-être que non, peut-être voulait-il savoir qu'elle en est vraiment la cause, va savoir.

De toute façon le peu de questions sur l'assembleur qui se pose dans les forums, compare à ça les questionnements sur les autres langages.

Alors ce n'est pas pour envoyer dans les roses le peu de personnes qui ont besoin d'aide en asm, de plus tu dois un peu comprendre cette situation non ? si tu fais de l'asm

-
Edité par Anonyme 8 juillet 2015 à 13:25:10

shaynox a écrit:

C'est un comble de le faire, sachant que l'asm est plus difficile à abordé plus que tout autre langage.

Est-tu certain de ce que tu avance ? Les langages assembleurs sont généralement des langages simples (en eux mêmes, pas au niveau de l'utilisation)… Le seul truc c'est qu'il faut bien connaitre l'architecture cible et les conventions employées…

Ensuite je ne compare pas les assembleurs avec d'autres types de langages, et qu'est-ce qui m'en empecherait ?

-
Edité par Mad scientist 8 juillet 2015 à 13:43:10

"Est-tu certain de ce que tu avance ? Les langages assembleurs sont généralement des langages simples" oO

Ok, depuis combien de temps tu étudies l'asm ? -  que connais-tu en asm ? (petit test)  - As-tu fait des projets full asm ?

Tu m'a l'air bien prétentieux, quel asm tu pratiques ?

Si tu as tant de connaissance et de faciliter, alors pourquoi es-tu sûr que le wiki va suffire à l'OP ?

Sais-tu maitriser toutes les instructions de l'assembleur intel (environ 1300) et toutes les applications concernées par cesdites instructions ?

Désolé, mais si j'avais la même science infuse que toi, j'aurais complétée le savoir du sens de lecture des données raw en RAM par d'autre savoir que les miens.

-
Edité par Anonyme 8 juillet 2015 à 13:52:07

J'ai fait de l'assembleur x86 il y a 2 / 3 ans. J'en connaissait suffisament pour avoir commencé un petit noyau (interruptions, vecteurs d'interruptions, appels systèmes, faire un petit bootloader, passage en mode protégé, gdt, IO…). Je m'était arrété quand il fallait faire un système de fichier. Au final, le projet ne contenait pas énormément d'assembleur d'ailleurs.

Je ne maîtrise pas toutes les instructions de l'assembleur intel. Il existe un document fait pour les expliquer, s'amuser à tout retenir est bien trop coûteux en temps.

Quand je parle de langage simple, il faut bien comprendre ce que je veux dire: la syntaxe est très simple, les instructions sont minimalistes. On n'a pas de librairie standard qui fait 10000 trucs comme Java par exemple, juste des instructions simples qui font des trucs plus ou moins simples. Même si elles impliquent d'avoir compris beaucoup de choses derrière.

Actuellement je n'ai effectivement pas pratiqué depuis un petit moment.

Vu que mon message semble porter à confusion je l'ai un peu édité.

-
Edité par Mad scientist 8 juillet 2015 à 13:59:40

Je rejoins Mad en tout point, je vois pas en quoi l'ASM est différent des autres langages, si ce n'est qu'il est plus proche du langage machine. Le lien vers wiki était bien vu, ça évite d'expliquer le concept du endianness de manière foireuse que des gens on fait d'une meilleure façon, en l’occurrence sur Wikipédia.

que le x86 ? et quid de l'x64 ?

Si je te montre ce code, est-ce que ça te parle ? :

                        ; ymm0 = cos_x    ymm3 = sin_x
                        ; ymm1 = cos_y    ymm4 = sin_y
                        ; ymm2 = cos_z    ymm5 = sin_z

                        ; ymm6 = (1x * cos_y * cos_z)
                            vmulps      ymm6, ymm1, ymm2
                            vmulps      ymm6, ymm6, [.tmp_x]

                        ; ymm7 = (1y * cos_y * sin_z)
                            vmulps      ymm7, ymm1, ymm5
                            vmulps      ymm7, ymm7, [.tmp_y]

                        vmulps      ymm8, ymm4, [.tmp_z]    ; ymm8 = (1z * sin_y)
                        vsubps      ymm6, ymm6, ymm7
                        vsubps      ymm6, ymm6, ymm8

                        vmovups     [temp], ymm6

 Je ne te parle pas de les retenir, je te parle de les maitriser, different x)

(la différence est que même si tu sais comment elle fonctionne, cela ne veut pas dire que tu sais la maitriser d'un seul coup)

http://openclassrooms.com/forum/sujet/la-petite-enigme-du-vendredi#message-88937227

Sinon quand tu parles de la syntaxe, évidemment qu'elle est facile à comprendre, après je te parle de maitrise, pas d'apprentissage d'instructions bêtement, mais maitrise de la RAM, maitrise d'instructions, maitriser un squelette de programme en asm, voilà ce dont je parle.

Après si cela justifie encore le fait de faire office de moteur de recherche, je trouve cela un peu dommage de croire que tout n'est dû qu'à de la lecture de documentations.

"ça évite d'expliquer le concept du endianness de manière foireuse "

Si tu parles de la mienne, je t'en pris alors, de dire en quoi mon explication te fait douter.

Bon vu que vous me semblez têtu, celui qui arrive à ne pas avoir de questions sur les sources de mon projet, je le félicite (surtout toi Failure): https://sourceforge.net/projects/hackengine/

Enfin moi je suis d'avis d'attendre que l'OP vienne nous dire quelle est la meilleure explication ou du moins quelle est la plus complète.

Et sinon à votre avis, combien de concept selon vous il y a en asm et comparez-moi ce nombre avec ceux des autres langages.

(indice: http://hackasm.5gb.co/Projects/Computer_Science/courses/tutorials/assembly/fr/index.html)

-
Edité par Anonyme 8 juillet 2015 à 14:32:46

Ce sont des instructions vectorielles. vmulps = multiplication vectorielle de nombres flottants (256 / 32 = 8 à la fois).

En nottant X[0:7] = pour tout les huit flottants simple précision de X

ymm6[0:7] = ymm1[0:7] * ymm2[0:7]

ymm6[0:7] = tmp_x[0:7] * ymm6[0:7]

ymm7[0:7] = ymm1[0:7] * ymm5[0:7]

ymm7[0:7] = tmp_y[0:7] * ymm7[0:7]

ymm8[0:7] = tmp_z[0:7] * ymm4[0:7]

ymm6[0:7] = ymm6[0:7] - ymm7[0:7]

ymm6[0:7] = ymm6[0:7] - ymm8[0:7]

temp = ymm6

L'architecture Intel est complexe. Ses assembleurs restent simples. Ils ont juste plein d'instructions. Effectivement c'est très difficile de toute les maitriser. Mais il y a une référence pour éviter d'avoir à faire ça.

Pour les concepts à maîtriser en assembleur, je dirais qu'il y en a suffisament pour rédiger 3603 pages de documentation. Mais ça c'est pour la compréhension de l'architecture de la machine. Ça ne complexifie pas le langage. Les LANGAGES assembleurs reste simples.

-
Edité par Mad scientist 8 juillet 2015 à 14:39:50

Bravo, je t'applaudis (non ironique x)

Maintenant, on va passer à la vitesse supérieure, pourrais tu me faire le lien entre ces instructions ?

Bon vu que c'est un exo facile, je t'invite à me décrypter ma fonction update_scene dans source.asm et on verra si cela va être facile (bon vu que j'ai mis des commentaires, cela serra un peu du gâteau pour toi)

https://sourceforge.net/projects/hackengine/

-
Edité par Anonyme 8 juillet 2015 à 14:50:11

shaynox a écrit:

Maintenant, on va passer à la vitesse supérieure, pourrais tu me faire le lien entre ces instructions ?

Mouais enfin là tu ne me demande plus de faire de l'assembleur, tu me demande de faire des maths…

Pareil pour ta fonction update_scene. À partir du moment où on sais ce que font les instructions, il ne reste plus que les maths. Mais si ça te tiens à cœur, je ferais tout ça ce soir / tout à l'heure, pour l'instant je dois partir.

Ok, enfin tu m'as l'air expérimenter déjà, ce qui n'est surement pas le cas avec l'OP, donc attend toi à qu'il te pose d'autres questions si tu ne les as pas anticipé au début x)

Entre parenthèses, si l'assembleur était si facile, alors on n’aurait pas autant de trolls anti-asm, ceci est un constat de ce que je vois dans les forums durant toutes ces années à faire de l'asm (2/3 ans comme toi), hurlant que c'est trop compliqué pour leur petite cervelle de moineau.

Et on n’aurait pas autant d'abandons concernant les débutants en asm et qu'après ils deviennent des trolls, théorie peut-être, mais collante à la réalité vue le nombre de questionnements sur le low level, mais aucun agrandissement de notre communauté.

En d'autres termes, la communauté asm en france rivaliserait à l'étranger si c'était le cas, enfin même à l'étranger ce n'est pas suffisant.

Et sinon je vais me répéter, ce sont les concepts en assembleur qui font sa complication et ses instructions, sa complexification.

Si tu mélanges ces deux points-là, alors l'asm est dur à apprendre, de plus si tu compares ses concepts avec ceux d'autres langages, l'asm les bas à tous les niveaux, en même temps c'est un peu logique, vu que l'abstraction est inexistante en asm, mais ce n'est pas aussi qu'une question d'abstraction.

Ce que tu es en train de faire, c'est d'ignorer ces concepts et de ne prendre que les instructions en compte, pour cela que tu dis que c'est facile, alors que c'est un tout

(indice pour voir 1/50 des concepts en assembleur, si ce n'est plus: http://hackasm.5gb.co/Projects/Computer_Science/courses/tutorials/assembly/fr/index.html

-
Edité par Anonyme 8 juillet 2015 à 16:20:23

Re !

shaynox a écrit:

Ok, enfin tu m'as l'air expérimenter déjà, ce qui n'est surement pas le cas avec l'OP, donc attend toi à qu'il te pose d'autres questions si tu ne les as pas anticipé au début x)-

Mouais, après si l'OP avait eu d'autres questions il les aurait posé et on lui aurait répondu.

shaynox a écrit:

Entre parenthèses, si l'assembleur était si facile, alors on n’aurait pas autant de trolls anti-asm, ceci est un constat de ce que je vois dans les forums durant toutes ces années à faire de l'asm (2/3 ans comme toi), hurlant que c'est trop compliqué pour leur petite cervelle de moineau.

En fait c'est peut être moi qui ne suis pas assez explicite: quand je dis que les langages assembleurs sont simples, je ne dis pas qu'il sont simples à utiliser, ni qu'il y a peu de concepts derrière, je dis que les langages en eux mêmes sont simples. Simple dans le sens « il y a des instructions, des opérandes, des directives, des labels, des commentaires, et à part ça, bah il n'y a pas grand chose ». Je parle bien des LANGAGES en eux même.

Toi tu parle de la simplité d'apprentissage / maîtrise.

Sinon je pense qu'on est d'accord pour dire que les processeurs Intel sont très complexes. Mais les langages restent simples.

Après effectivement il y a beaucoup d'instructions, mais elles sont simples et la documentation décrit leur fonctionnement.

-
Edité par Mad scientist 8 juillet 2015 à 18:02:33

 Re,

Certes, mais cela ne veut pas dire de sous-estimer ce langage par sa seule simplicité d'écriture et c'est le risque à prendre quand on code en asm.

Sinon après des années de codage en asm, on peut le dire, mais pas à un débutant, je me souviens d'avoir pris l'assembleur à la légère du simple fait que seul 1 mot (min) suffisait à exécuter une instruction.

Et de ce fait, je me suis un peu reposé sur mes acquis, puis j'ai programmé un OS en dos-like, mais c'était beaucoup trop tôt, car c'est seulement 1/2 ans après l'avoir codé que j'ai acquis une meilleure façon de le faire, plus l'acquisition des dernières technologies sur CPU.

Cela veut dire qu'il faut que je refasse une refonte de mon OS avec ma nouvelle xp x)

Et encore je suis loin d'avoir acquis tous les principes pour que mon style de coding soit de plus en plus robuste/complet/dernière techno et d'avoir un beau code aussi.

Voilà le prix de pensée que c'est facile quand on débute

Sinon ce qui est marrant c'est que je pensais comme toi avant maintenant, mais le fait que je t'ai vu avoir le même discours sur l'assembleur que moi, m'a fait prendre conscience de ce cas précis

-
Edité par Anonyme 8 juillet 2015 à 18:29:36

Merci pour vos réponses, effectivement je ne connaissais par le concept "d'endianness", car je débute en assembleur, merci de me l'avoir fait découvrir.

Il est vrai qu'il est difficile de trouver des cours complets en français 

Encore une fois tu semble ne pas avoir compris le message… Quand je dis que l'assembleur est un langage simple, je parle du langage en lui même, grosso modo ce que tu aurais à implémenter si tu devais créér un assembleur (le programme). Je n'ai jamais dit que l'écriture des codes en langage assembleur était simple… Relis mes messages et essaye de comprendre.

Dans tout les langages que j'ai appris jusqu'à maintenant, j'ai toujours essayé de faire de la manière la plus idiomatique, la plus propre dans la logique du langage, … Et je me suis toujours fixé comme règle absolue de ne jamais penser que je connais tout du langage, des ses concepts et de ses idiomes. Aussi je passe beaucoup par les références officielles (le standard C11 en C, le standard C++14 en C++, la documentation de Python, Hoogle + les Haskell Reports, …) afin de vérifier toutes les clauses / comportements de ce que je compte utiliser.

En assembleur, le langage en lui même n'est pas la partie la plus importante, le nombre d'éléments différents est très limité (instructions, opérandes, label, …), la partie la plus importante est la connaissance de l'architecture cible. Le langage en lui-même est simple comparé à beaucoup d'autres langages. La connaissance / maîtrise de l'architecture est, elle, une chose bien plus complexe, comparé au langage. C'est précisément ça que je veux dire quand je dis que les LANGAGES assembleurs sont simples. Il suffit de comparer la complexité d'un assembleur comme nasm à celle d'un compilateur plus ou moins complet de C++14.

-
Edité par Mad scientist 8 juillet 2015 à 20:02:47

Mad scientist a écrit:

En assembleur, le langage en lui même n'est pas la partie la plus importante, le nombre d'éléments différents est très limité (instructions, opérandes, label, …), la partie la plus importante est la connaissance de l'architecture cible. Le langage en lui-même est simple comparé à beaucoup d'autres langages. La connaissance / maîtrise de l'architecture est, elle, une chose bien plus complexe, comparé au langage. C'est précisément ça que je veux dire quand je dis que les LANGAGES assembleurs sont simples. Il suffit de comparer la complexité d'un assembleur comme nasm à celle d'un compilateur plus ou moins

Désolé mais, dans ce que tu viens de dire, je comprends toujours la même chose, faire:

    ; Point rdi to _start_scene_.object
        mov     rdi, rsi
        sub     rdi, start_scene - _start_scene_

    ; Point rcx to End object
        mov     rcx, rsi
        add     ecx, [rbx + OBJ3D_SIZE]

est simple, pas de tonne de mot-clés, juste ce qu'il faut, rapiditité de compréhension, légèreté en lettre, vocabulaire simpliste, bref que de qualifications qui fait que ce langage est simple.

Voilà ce que j'ai compris, après si ce n'est pas cela, tu peux me donner un exemple de ce que tu trouves facile ?(j'avoue que si c'est le cas, j'ai un peu de mal à visualiser concrètement ce que tu veux dire)

Fin bref, si c'est bien ce que tu veux dire, alors le quiproquo est résolu depuis longtemps

Et donc je redis ceci:

"Et sinon je vais me répéter, ce sont les concepts en assembleur qui font sa complication et ses instructions, sa complexification.

Si tu mélanges ces deux points-là, alors l'asm est dur à apprendre.

Ce que tu es en train de faire, c'est d'ignorer ces concepts et de ne prendre que les instructions en compte, pour cela que tu dis que c'est facile, alors que c'est un tout"

-
Edité par Anonyme 8 juillet 2015 à 21:26:18

Effectivement, il semble que tu aies plutôt compris ce que j'ai voulu dire. Je parle aussi du fait qu'il sont simples à assembler, … Du langage en lui même quoi. Son « noyau » en quelques sortes.

Mais dans ce cas-ci, pourquoi avoir dis ceci dans ton précédent message:

shaynox a écrit:

Certes, mais cela ne veut pas dire de sous-estimer ce langage par sa seule simplicité d'écriture et c'est le risque à prendre quand on code en asm.

[…]

Et de ce fait, je me suis un peu reposé sur mes acquis, puis j'ai programmé un OS en dos-like, mais c'était beaucoup trop tôt, car c'est seulement 1/2 ans après l'avoir codé que j'ai acquis une meilleure façon de le faire, plus l'acquisition des dernières technologies sur CPU.

Alors que je précise bien dans le message qui précède celui-ci précise bien que je ne sous-estime absolument pas la complexité induite par tout les concepts des architectures x86 ? En fait c'est sourtout cette partie qui m'a fait penser que tu avais mal compris.

-
Edité par Mad scientist 8 juillet 2015 à 23:58:17

Pour moi, qui dit simplicité technique, dis faciliter d'apprentissage, j'ai sorti ce paragraphe sur mon expérience, car je me suis reconnue dans tes dires lorsque je débutais en asm.

Et c'est pour cela que je pensais que tu avais la même conclusion que moi (faciliter d'apprentissage) quand tu as fait cette remarque sur cet aspect de l'asm à propos du format des instructions.

Enfin bref, qui dit quiproquo, dis dénouement difficile aussi x)

shaynox a écrit:

Pour moi, qui dit simplicité technique, dis faciliter d'apprentissage

Non. Le C par exemple est techniquement très simple, alors qu'il pose énormément de problèmes aux débutants comparé au Java (Beurk) par exemple, qui est de loin plus complexe. Beaucoup de gens ne comprenent rien aux dérivés de LISP (Scheme, Common Lisp, …) alors que techniquement, ces langages (en particulier Scheme) sont ce qui se fait de plus simple.

Même si personnelement je préfère les langages techniquement simples, force est de constater que les gens ont des difficultées avec une bonne partie d'entre eux.

Ce que tu dis me fait poser cette question: à part l'assembleur x86, connais-tu d'autres langages (pas forcément d'assemblage) ?

-
Edité par Mad scientist 9 juillet 2015 à 2:36:01

C'est sûr, c'est un piège de faire ce lien, mais il est inévitable de tomber dedans quand on débute et même après ^^, enfin c'est ce que je pense.

D'autres langages ? bah je pense qu'avec l'avx, il y a de quoi faire en matière de nouveau langage, enfin faut voir cela comme l'évolution du C en C++ avec une rétrocompatibilité.

Ensuite toujours dans le domaine de l'asm, tu as un puissant langage méconnu du public, le préprocesseur (macro) qui te permet d'ajouter de nouvelles features à l'asm, mot-clés.

Certes c'est limité aux mêmes features qu'a la création de macros, mais assez suffisante pour copier environ 80% d'un compilateur (enfin même ce pourcentage dépend de ce que tu veux faire).

Enfin il suffit juste d'avoir un très bon système de création de macros et là on devient invincible x) toutes les voies sont possibles, donc 100% de copie de trucs utiles au haut niveau.

Par exemple: http://forum.nasm.us/index.php?topic=2076.msg9426#new - http://forum.nasm.us/index.php?topic=2122.0

Voilà ce que peuvent faire les macros, après je suis toujours pour le juste milieu, bien que j'ai créé des macros qui imitent le high-level, je ne les utilise pas toutes, environ que 15%.

Par contre si on veut faire un autre langage, alors l'abusions de macro n'est pas un problème.

Mais cela peut très bien ce faire sur d'autres langages aussi, donc tu évolues ton langage favori a coups de macro au lieu de le tromper avec un autre x)

Comme je le dis, tout compilateur peut se coder qu'avec des macros, donc tout concept de haut niveau.

-
Edité par Anonyme 9 juillet 2015 à 4:32:41

shaynox a écrit:

D'autres langages ? bah je pense qu'avec l'avx, il y a de quoi faire en matière de nouveau langage, enfin faut voir cela comme l'évolution du C en C++ avec une rétrocompatibilité.

La où l'AVX n'est qu'un jeu d'instuctions supplémentaires, le C et le C++ sont des langages complètements différents… Qui ont évolués d'une manière différente, avec des communautés différentes et des logiques différentes.

shaynox a écrit:

Ensuite toujours dans le domaine de l'asm, tu as un puissant langage méconnu du public, le préprocesseur (macro) qui te permet d'ajouter de nouvelles features à l'asm, mot-clés.

Ouais, personne ne connais le préprocesseur, absolument personne qui utilise un langage comme le C ne pourrait se douter que ça existe…

shaynox a écrit:

Certes c'est limité aux mêmes features qu'a la création de macros, mais assez suffisante pour copier environ 80% d'un compilateur (enfin même ce pourcentage dépend de ce que tu veux faire).

What ? Un compilateur ce n'est pas juste du « remplacement », l'analyse de la validité du code, des règles du langage, de sa syntaxe, l'optimisation… Tu en fais quoi ? Et les macros ont quand même de sacrès limites, je veux bien te voir essayer d'implémenter un « compilateur » de Haskell par exemple avec ça…

shaynox a écrit:

Enfin il suffit juste d'avoir un très bon système de création de macros et là on devient invincible x) toutes les voies sont possibles, donc 100% de copie de trucs utiles au haut niveau.

Ouais. Donc tu n'as vraiment fait que de l'assembleur x86 en fait. Parce que l'appel de fonction ce n'est pas un feature haut niveau. Les conditions / while / … non plus. Le C est plus haut niveau que l'assembleur x86 mais ce n'est pas un langage haut niveau du tout. Essaye d'implémenter des trucs de Haskell et tu t'en rendras compte.

Tu devrais au moins essayer d'autres langages de programmation, c'est très enrichissant. Tu te rendrais certainement compte que non, l'assembleur x86 n'est pas le langage le plus complet du monde, que non, il n'est pas adapaé à tout les besoins, et que si, il a ses limites. Tu ne créé absolument pas un compilateur ou un nouveau langage juste en utilisant des macros.

Mad scientist a écrit:

La où l'AVX n'est qu'un jeu d'instuctions supplémentaires, le C et le C++ sont des langages complètements différents… Qui ont évolués d'une manière différente, avec des communautés différentes et des logiques différentes.

Et alors ? il n'en reste pas moi que les nouveaux mot-clés du c++ par rapport au C est le même principe que de nouvelles instructions, tant en c++ qu'en asm.
Tout n'est qu'évolution d'instruction tant au haut niveau qu'en bas niveau.

Mad scientist a écrit:

Ouais, personne ne connais le préprocesseur, absolument personne qui utilise un langage comme le C ne pourrait se douter que ça existe…

Ah ? désolé, mais je ne croise pas beaucoup de macros quand je scrute des codes sources de haut niveau, et en asm, c'est aussi pire x)

Enfin quand je parle de macro, je parle de macros dignes de ce nom x)

Mad scientist a écrit:

What ? Un compilateur ce n'est pas juste du « remplacement », l'analyse de la validité du code, des règles du langage, de sa syntaxe, l'optimisation… Tu en fais quoi ? Et les macros ont quand même de sacrès limites, je veux bien te voir essayer d'implémenter un « compilateur » de Haskell par exemple avec ça…

Tu ne me crois pas ? alors analyse mes macros stp et leurs applications dans les liens que je t'ai déjà donnés

Mad scientist a écrit:

Ouais. Donc tu n'as vraiment fait que de l'assembleur x86 en fait. Parce que l'appel de fonction ce n'est pas un feature haut niveau. Les conditions / while / … non plus. Le C est plus haut niveau que l'assembleur x86 mais ce n'est pas un langage haut niveau du tout. Essaye d'implémenter des trucs de Haskell et tu t'en rendras compte.

Ah ? et ceci c'est de la daube peut-être ?

                jif  eax ,<, CLOCKS_PER_SEC, .no_show_fps
               ;{
                    printf_     "FPS = %d", [.fps_data]

                    mov         [.fps_data], i32(0)
                    clock_      [.fps_data + 4]
               ;}
               .no_show_fps:

LoadImageA_     0, "data\Hackengine_logo.ico", IMAGE_ICON, 0, 0, LR_LOADFROMFILE
system_         "color 0A"
system_         "title HackEngine"
memclr          screen, [ptr_endscreen]
sincosps        xmm1, xmm2, xmm0

            while   rsi ,<, tmp_end_scene_3D
           ;{
                %include 	"1.ASM\HackEngine\Source\show_world\show_pixel.asm"
           ;}
            endwhile    {add  rsi, voxel(2)}
		
        ;==========================================================================
        ; void  manage_keyboard(UINT message, WPARAM state)
        ; Purpose : Manage keyboard
        ; Input   : NONE
        ; Output  : NONE
        ;==========================================================================
        manage_keyboard:
       ;{
            if [message] is i32(WM_KEYDOWN)
            endif

            ; ALT + ²
                if [message] is i32(260)
               ;{
                    if i64 [word_param_msg] is 222, quit_program
                    endif
               ;}
                endif

            if     [message] is i32(WM_CLOSE)  , quit_program
            elseif [message] is i32(WM_DESTROY), quit_program
            endif
       ;}
        end_manage_keyboard:
        ;==========================================================================
        ; / manage_keyboard
        ;==========================================================================



quit_program:
		
		  

		; 1x
			if  xmm0 ,>=, [plimit_x], .end_putpixel
			endif
			if  xmm0 ,<=, [mlimit_x], .end_putpixel
			endif

		vmovss		xmm0, [showpixel_xy + 4]
		; 1y
			if  xmm0 ,>=, [plimit_y], .end_putpixel
			endif
			if  xmm0 ,<=, [mlimit_y], .end_putpixel
			endif

		vmovss		xmm0, [rsi + _1z]
		; 1z
			if  xmm0 ,<=, [_0], .end_putpixel
			endif

               ; ...

    .end_putpixel:

As-tu vraiment lu mes sources ? j'ai un doute.

Et relis attentivement http://forum.nasm.us/index.php?topic=2076.0 stp

Mad scientist a écrit:

Tu devrais au moins essayer d'autres langages de programmation, c'est très enrichissant. Tu te rendrais certainement compte que non, l'assembleur x86 n'est pas le langage le plus complet du monde, que non, il n'est pas adapaé à tout les besoins, et que si, il a ses limites. Tu ne créé absolument pas un compilateur ou un nouveau langage juste en utilisant des macros.

Non merci pour l'offre, j'ai déjà fait mon choix et je ne reviendrais pas dessus, d'ailleurs j'ai un bon bagage de connaissances depuis que je code en asm et pour rien au monde j'arrêterais ma voracité à le remplir de même type de savoir.



Et en ce qui concerne tes block de conditions, je les ais fais evoluer en une seul

JIF macro !!!

http://forum.nasm.us/index.php?topic=2076.msg9415#msg9415

Bref si tu étais bien lu ce que j'ai écrit et allé voir les liens que je t'ai passés, tu n'aurais pas eu cette soudaine attitude

D'ailleurs cela m'étonne que tu sois aussi surpris et cela prouve bien que tu as arrêté l'assembleur, tu connais le HLA ?

http://www.bing.com/search?q=HLA%20asm%20nasm&qs=n&form=QBRE&pq=hla%20asm%20nasm&sc=3-8&sp=-1&sk=&cvid=68d34e4a42c4438c802e668221218b5d

-
Edité par Anonyme 9 juillet 2015 à 15:30:40

shaynox a écrit:

Mad scientist a écrit:

La où l'AVX n'est qu'un jeu d'instuctions supplémentaires, le C et le C++ sont des langages complètements différents… Qui ont évolués d'une manière différente, avec des communautés différentes et des logiques différentes.

Et alors ? il n'en reste pas moi que les nouveaux mot-clés du c++ par rapport au C est le même principe que de nouvelles instructions, tant en c++ qu'en asm.
Tout n'est qu'évolution d'instruction tant au haut niveau qu'en bas niveau.

Non. En C et en C++, l'évolution ne se résume pas à l'ajout de mots-clés. Les définitions évoluent, de nouveaux principes s'ajoutent, de nouvelles formes pour certains instructions / fonctions / …, la prise en compte de certains standards cité dans les anciennes versions qui ont de nouvelles versions, les anciens modèles sont remplacés par de nouveaux (modèle mémoire par exemple), …

shaynox a écrit:

Mad scientist a écrit:

What ? Un compilateur ce n'est pas juste du « remplacement », l'analyse de la validité du code, des règles du langage, de sa syntaxe, l'optimisation… Tu en fais quoi ? Et les macros ont quand même de sacrès limites, je veux bien te voir essayer d'implémenter un « compilateur » de Haskell par exemple avec ça…

Tu ne me crois pas ? alors analyse mes macros stp et leurs applications dans les liens que je t'ai déjà donnés

 Ce n'est pas histoire de te croire ou pas, c'est que ce que tu as créé n'est PAS un compilateur. Tu as juste fait de la métaprogrammation basique.

shaynox a écrit:

Mad scientist a écrit:

Ouais. Donc tu n'as vraiment fait que de l'assembleur x86 en fait. Parce que l'appel de fonction ce n'est pas un feature haut niveau. Les conditions / while / … non plus. Le C est plus haut niveau que l'assembleur x86 mais ce n'est pas un langage haut niveau du tout. Essaye d'implémenter des trucs de Haskell et tu t'en rendras compte.

Ah ? et ceci c'est de la daube peut-être ?

As-tu vraiment lu mes sources ? j'ai un doute.

Et relis attentivement http://forum.nasm.us/index.php?topic=2076.0 stp

Je ne dit pas que tu fais de la daube. Je dis que ce ne sont pas des features de haut niveau.

shaynox a écrit:

Mad scientist a écrit:

Tu devrais au moins essayer d'autres langages de programmation, c'est très enrichissant. Tu te rendrais certainement compte que non, l'assembleur x86 n'est pas le langage le plus complet du monde, que non, il n'est pas adapaé à tout les besoins, et que si, il a ses limites. Tu ne créé absolument pas un compilateur ou un nouveau langage juste en utilisant des macros.

Non merci pour l'offre, j'ai déjà fait mon choix et je ne reviendrais pas dessus, d'ailleurs j'ai un bon bagage de connaissances depuis que je code en asm et pour rien au monde j'arrêterais ma voracité à le remplir de même type de savoir.

C'est bien dommage. La programmation est un univers tout entier que tu peux explorer, et toi reste sur ton asteroïde. Tu te ferme énormément de portes.

shaynox a écrit:

Et en ce qui concerne tes block de conditions, je les ais fais evoluer en une seul JIF macro !!!

Bref si tu étais bien lu ce que j'ai écrit et allé voir les liens que je t'ai passés, tu n'aurais pas eu cette soudaine attitude

D'ailleurs cela m'étonne que tu sois aussi surpris et cela prouve bien que tu as arrêté l'assembleur, tu connais le HLA ?

J'ai lu ce que tu as passé. Globalement ce que tu fais est assez simpa. Mais encore une fois c'est dommage de rester enfermé dans sa zone de confort comme tu le fais.

Sinon ta macro jif ne devrait pas supprimer if et while étant donné que ces deux dernières apportaient un léger gain en structuration / sémantique du code.

Tu n'as rien prouvé quand tu dis que j'ai arreté l'assembleur (je n'ai pas vraiment arreté d'ailleurs, j'ai arreté de pratiquer avec des projets complets. J'en fais toujours un peu de temps en temps et je lis toujours quelques documents sur le sujet), ça je l'ai dit plus tôt:

Mad scientist a écrit:

J'ai fait de l'assembleur x86 il y a 2 / 3 ans.

-
Edité par Mad scientist 9 juillet 2015 à 21:14:23

Euh d'où j'ai dit que j'ai crée un compilateur, je pourrais le faire, mais il me faudrait des features de création de macros un peu plus puissantes http://forum.nasm.us/index.php?topic=2122.0 et désolé, mais connait tu la définition du HLA ? à croire que ta zapper cette partie, bon je vais le faire à ta place.

https://en.wikipedia.org/wiki/High_Level_Assembly

Donc oui que tu le veuilles ou non, c'est du haut niveau dans du bas niveau, tu sais ce qu'est une abstraction ? Ignorer certains éléments de bas niveau dans un concept, dans le cas de mes macro/fonctions, j'ai ignoré le fait de savoir quels registres seraient affectés par mes arguments, tout comme toi avec ton langage de haut niveau.

Sais-tu au moins comment mes macros fonctionnent ? Je n’ai pas le temps de te donner un cours, donc tu devras te contenter de la doc nasm et des mes sources (HackEngine\Headers\source\).

Qu'a tu contre ma macro jif ? elle ta rien fait x) et de quel gain tu parles ? Rien à foutre du gain, car il n'y en a aucun qui valent la peine d'être traitée, surtout qu'un while c'est ma fonction jif mais avec un jmp en prime, donc c'est de la merde.

De plus je te rappelle que je les ai déjà recodés, if et while en macro, mais que je les ai délaisser pour ma jif.

Gentils que tu te soucis de moi à propos de mon anarchement sur l'asm, mais c'est peine perdue, ma conviction est incassable, principalement car je n'aurais jamais acquis tout ce savoir si je codais avec d'autes langages et j'en redemande

Et en prime un autre lien pour le HLA: http://www.plantation-productions.com/Webster/HighLevelAsm/WinDownload.html

Exemple de HLA dans le precedent lien (assez moche je dois dire x) ):

program helloworld;
#linker( "comdlg32.lib" ) 
#linker( "comctl32.lib" )

?compileAll		:= true;

?@NoDisplay 	:= true;
?@NoStackAlign	:= true;

#includeOnce( "stdlib.hhf" )

#includeOnce( "howl.hhf" )


const
	applicationName := "Hello World";
	formX			:= w.CW_USEDEFAULT;	// Let Windows position this guy
	formY			:= w.CW_USEDEFAULT;
	formW			:= 600;
	formH			:= 600;


	


// Form declaration.
// We've got an empty form with no widgets, so this is fairly trivial:
	
wForm( mainAppWindow );
endwForm


// Must include the following macro invocation to emit the code that the
// wForm macro generated:

mainAppWindow_implementation();
	

procedure myThread( parm:dword );
begin myThread;

	howl.mainThreadExecute
	( 
		parm, 
		thunk 
		#{
			stdout.put( "In Thunk" nl );
		}# 
	);
	w.ExitThread( 0 );

end myThread;

// The following gets called immediately after the main application
// window is created. It must be provided, even if it does nothing.
		
method mainAppWindow_t.onCreate;
var
	threadID:dword;
begin onCreate;

	w.CreateThread
	(
		NULL,
		2048,
		&myThread,
		this.handle,
		0,
		threadID
	);

end onCreate;




	
	
///////////////////////////////////////////////////////////////////////////////
//
//
// The following is mostly boilerplate code for all apps (about the only thing
// you would change is the size of the main app's form)
//
//
///////////////////////////////////////////////////////////////////////////////
//	
// When the main application window closes, we need to terminate the 
// application. This overridden method handles that situation.  Notice the
// override declaration for onClose in the wForm declaration given earlier.
// Without that, mainAppWindow_t would default to using the wVisual_t.onClose
// method (which does nothing). 
		
method mainAppWindow_t.onClose;
begin onClose;
	

	// Tell the winmain main program that it's time to terminate.
	// Note that this message will (ultimately) cause the appTerminate
	// procedure to be called.
	
	w.PostQuitMessage( 0 );
	
	
end onClose;

			   
   

			   
   
// When the application begins execution, the following procedure
// is called.  This procedure must create the main
// application window in order to kick off the execution of the
// GUI application:
  
procedure appStart;
begin appStart;

	push( esi );
	
	// Create the main application window:
	
	mainAppWindow.create_mainAppWindow
	(
		applicationName,		// Window title
		w.WS_EX_CONTROLPARENT,	// Need this to support TAB control selection
		w.WS_OVERLAPPEDWINDOW,	// Style 
		NULL,					// No parent window 									
		formX,					// x-coordinate for window. 
		formY,					// y-coordinate for window.
		formW,					// Width
		formH,					// Height
		howl.bkgColor_g,		// Background color
		true					// Make visible on creation 
	);
	mov( esi, pmainAppWindow );	// Save pointer to main window object.
	pop( esi );

end appStart;



// appTerminate-
//
//	Called when the application is quitting, giving the app a chance
// to clean up after itself.
//
// Note that this is called *after* the mainAppWindow_t.onClose method
// executes (indeed, mainAppWindow_t.onClose, by posting the quit message,
// is what actually causes the program to begin terminating, which leads
// to the execution of this procedure).

procedure appTerminate;
begin appTerminate;
	
	// Clean up the main application's form.
	// Note that this will recursively clean up all the widgets on the form.
	
	mainAppWindow.destroy();
	
end appTerminate;


// appException-
//
// Gives the application the opportunity to clean up before
// aborting when an unhandled exception comes along:

procedure appException
( 
	theException	:dword in eax;
	raiseAdrs		:dword in ebx;
	filename		:string in ecx;
	userCode		:dword in edx;
	lineNum			:uns32 in edi 
);
begin appException;

	raise( eax );

end appException;



// The main program for a HOWL application must simply
// call the HowlMainApp procedure.

begin helloworld;

	// Set up the background and transparent colors that the
	// form will use when registering the window_t class:
	
	w.GetSysColor( w.COLOR_MENU );
	mov( eax, howl.bkgColor_g );
	or( $FF00_0000, eax );
	mov( eax, howl.transparent_g );
	w.CreateSolidBrush( howl.bkgColor_g );
	mov( eax, howl.bkgBrush_g );

	HowlMainApp();
	
	// Delete the brush we created earlier:
	
	w.DeleteObject( howl.bkgBrush_g );			
				
end helloworld;
 

Si tu n'as pas arrêté l'asm, alors tu sais très bien que tu ne maitrises pas tous les points en asm, tout comme moi et le pouvoir des macros/parser de texte n'est pas à sous-estimer. 

Sinon on devrait continuer cette discussion en mp si cela te chante, car là pour du off-topic, on est en plein dedans.

Et c'est assez bizarre qu'il n'y ait pas eu de modo pour nous remettre à l'ordre x)

-
Edité par Anonyme 9 juillet 2015 à 22:23:56

shaynox a écrit:

Euh d'ou j'ai dit que j'ai crée un compilateur, je pourrais le faire, mais il me faudrait des features de création de macros un peu plus puissantes http://forum.nasm.us/index.php?topic=2122.0 et désolé, mais connait tu la définition du HLA ? à croire que ta zapper cette partie, bon je vais le faire à ta place.

https://en.wikipedia.org/wiki/High_Level_Assembly

Donc oui que tu le veuilles ou non, c'est du haut niveau dans du bas niveau, tu sais ce qu'est une abstraction ? Ignorer certains éléments de bas niveau dans un concept, dans le cas de mes macro/fonctions, j'ai ignoré le fait de savoir quels registres seraient affectés par mes arguments, tout comme toi avec ton langage de haut niveau.

Sais-tu au moins comment mes macros fonctionnent ? Je n’ai pas le temps de te donner un cours, donc tu devras te contenter de la doc nasm.

Qu'a tu contre ma macro jif ? elle ta rien fait x) et de quel gain tu parles ? Rien à foutre du gain, car il n'y en a aucun qui valent la peine d'être traitée, surtout qu'un while c'est ma fonction jif mais avec un jmp en prime, donc c'est de la merde.

Les sources de mes macros sont dans HackEngine\Headers\source\

Gentils que tu te soucis de moi à propos de mon anarchement sur l'asm, mais c'est peine perdue, ma conviction est incassable.

Et on devrait continuer cette discussion en mp si cela te chante, car là pour du off-topic, on est en plein dedans.

Le HLA n'est pas réélement un langage de haut niveau, le « High Level » est ici relatif à la plupart des autres assembleurs.

Ça fait bizarre quand quelqu'un qui ne fait que de l'assembleur te demande si tu sais ce qu'est une abstraction… C'est un peu le monde à l'envers en fait. Encore une fois ce n'est pas parce que tu as créé des macros pour des structures de contrôles comme if / while / … que tu as créé un langage de haut niveau.

Ça, par exemple c'est de la programmation haut-niveau (une abstraction du concept de calcul, au sens large). if / while / … ce sont juste des structures de contrôle basiques. Tu dois toujours gérer toi même la mémoire. Les abstraction sont toujours faibles / inexistantes. Tu reste toujours dépendant / proche de l'architecture, …

Pour le gain, je te parle du gain en sémantique / structuration, c'est marqué juste en haut. Ta macro jif est correcte mais if / while donnent plus de sens au code.

shaynox a écrit:

surtout qu'un while c'est ma fonction jif mais avec un jmp en prime, donc c'est de la merde.

Ouais c'est vrai on n'essaye jamais de simplifier en programmation… Non, mais sérieusement, if et while sont des choses qui reviennent en permanence, il y avait donc un intérêt à créér des macros pour, m'enfin bref…

Effectivement, il tes convictions semblent incassables. Je te laisse donc continuer dans tes erreurs. Il n'y a aucune raison de discuter avec quelqu'un qui n'écoute pas ce qu'on lui dit et qui refuse d'apprendre des autres. Ce n'est pas parce que tu te bouche les oreilles et que tu parle plus fort que tu as raison.

Enfin je te donne un dernier conseil, ouvre ton esprit. Être fermé d'esprit est certainement ta plus grande erreur.

-
Edité par Mad scientist 9 juillet 2015 à 22:31:00

Je ne vais même pas prendre la peine de te contre dire tellement que tu m'énerves et que tu restes enfermer à toute évolution de l'asm. (et aussi, car cela va être les mêmes arguments, car tu bloques toujours sur ce point-là: macro)

Bon vent.

(Dommage pour toi, car étant donné que tu m'as lancé un autre défi en te retranchant vers la spécialité de ton Haskell, j'allais justement t'en parler des structures de mémoire et des opérateurs de haut niveau que je gère très bien avec de simples macros asm, même si ce n'est que très rudimentaire pour l'instant, mais ce n’est pas mon but de copier à 100% un compilo et la faute au manqué de features complète au système de création de macro dans nasm comme je te les déjà dis, mais bon trop tard x) enfin, tu peux toujours regarder mes sources avant de crier au loup)

-
Edité par Anonyme 9 juillet 2015 à 23:58:55