Discussion :

[ToutEnMasm]

Bonjour,

Personnellement, je favoriserais les assembleurs répondant à une syntaxe normalisée comme MASM, TASM, ...
Le C donne l'exemple en se prétendant un langage indépendant des compilateurs (?..!), c'est vrai en partie.
Certains compilateurs Asm donnent franchement dans le particularisme syntaxique (NASM...) ou dans le particularisme fonctionnel (Rosasm).
L'Assembleur mérite mieux que ça.

[Rémi Coquet]

personnellement,je favoriserais les assembleurs répondant a une syntaxe normalisée comme masm,tasm,.....
le c donne l'exemple en se prétendant un langage indépendant des compilateurs (?..!),c'est vrai en partie.
Certains compilateurs asm donnent franchement dans le particularisme syntaxique,nasm... ou dans le particularisme fonctionnel comme rosasm.
L'asm mérite mieux que ça.

Salut,

Je ne comprends pas très bien le sens de ta (tes) réflexion(s) et j'ai besoin de précisions sur ce que tu veux vraiment dire:

- Qu'appelles-tu (considères-tu) syntaxe normalisée (sur quelles bases, pourquoi etc.) ?

- Le c donne l'exemple (de quoi ?)

- En quoi le c est-il un script indépendant des compilateurs ? (Tu veux j'imagine, dire: Indépendant de la machine et/ou de l'OS cible ? Ce qui, comme chacun sait, est un fantasme et non une réalité de travail dans le monde réèl)

Tu sembles critiquer le particularisme syntaxique ou fonctionnel (ce qui n'est pas vraiment la même chose) de certains éditeurs:

- Que trouves-tu gênant, hormis la possibilité de choisir, de définir, ses propres conventions d'écritures, dans ces divers efforts ?

- En quoi de nouvelles fonctionnalités sont-elles de mauvaises choses ?

- Si elles ne sont pas de mauvaises choses elles sont forcément nouvelles, donc non-normalisées (voir de futurs nouvelles normes) ; Peux-tu préciser ?

L'assembleur mérite mieux que cela, bien:

- Quoi ?

Je te remercie par avance pour tes précisions et éclaircissements.

[ToutEnMasm]

Un petit exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
;masm,tasm ,jwasm..++ syntax
 
RIP_INFO	STRUCT
	dwError DWORD ?
	dwType DWORD ?
RIP_INFO		ENDS

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
;nasm syntax
 
STRUC RIP_INFO
.dwError RESD 1
.dwType RESD 1
ENDSTRUC

Pour le c, j'ai bien dit langage indépendant des compilateurs, pas d'autres choses.
La syntaxe fait partie de cette normalisation.

[Rémi Coquet]

Merci pour ta réponse.
Il me manque cependant pas mal d'éléments.

Je te remercie pour l'exemple de déclaration de Datas virtuels sous forme de structures. J'imagine que le 1 indique le nombre de DWORD (ce qui ne serait pas complètement idiot dans de nombreux cas, puisqu'il s'agit de datas virtuels).
Je pense que ce que tu déclares: "Certains compilateurs asm donnent franchement dans le particularisme syntaxique,nasm", est dû au "RESD" au lieu du "DWORD". Je suis d'accord avec toi sur le fait que ce genre de raccourcis n'est pas des plus lisibles. REP DWORD aurait gagné en lisibilité s'il est bien question de cela.

Serais-tu néanmoins prêts à "tolérer":

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
[RIP_INFO:
dwError: DWORD ?
dwType: DWORD ?]

Ou, pour des évocations plus lisibles au sein du source:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
[STRUC.RIP_INFO:
dwError: DWORD ?
dwType: DWORD ?]

J'imagine que la suppression de RIP_INFO ENDS pour un cadre de déclaration [...] reste "digne" d'un l'assembleur ? (Pour les compilateurs, c'est un autre domaine).

Tu sembles apprécier particulièrement MASM (pas de problème), je comprends donc que tu fasses le rapprochement avec le C et les compilateurs (de scripts). MASM étant en effet un compilateur (créé avant toutes choses dans ce but par Microsoft), utilisable à la manière d'un assembleur, certes, mais cette particularité l'entraîne vers d'autres désavantages et sa syntaxe est loin d'être "normalisée" ou parfaite. Elle est plus proche des scripts (pour des raisons évidentes mentionnées plus haut) et utilise des mots clés inexistants en assembleur, qui ne sont justifiable que dans un compilateur. Le code généré n'est donc pas toujours forcément celui qui est écrit (les encapsulations n'apparaissent pas dans ton source (comme en C donc) mais le code dé-assemblé montre que cette encapsulations à bien lieu, et ce dans le mécanisme de substitution du compilateur.
Il me semble que cela est plus préjudiciable à un véritable "assemblage" qu'une syntaxe (je te l'accorde dans l'exemple cité) plus ou moins pertinente. Je dis cela parque que cela est le corps de ton argumentation.

Il me semble que le but de la syntaxe, est d'augmenter le plus possible la lisibilité du source et donc faciliter sa maintenance.
Quand tu dis: "je favoriserais les assembleurs répondant a une syntaxe normalisée comme masm,tasm"

Vu que TASM est un peu inutilisable au jour d'aujourd'hui, pourrais-tu citer un autre nom à coté de MASM ? Sinon, ton propos semblera vouloir signifier: "Je favoriserais masm que je considère comme la norme" ce qui serait somme-toute un peu excessif, non ?
Il ne serait plus question de favoriser dans ce cas là mais d'imposer, comme normatif, ce qui est très différent et réclame quelques explications.
Je sais que rédiger prend un peu plus de temps mais il serait agréable que tu répondes un peu plus amplement à mes précédentes questions.
Le but étant de mieux comprendre les raisons profondes des (t)ces doléances, que je comprends, elles, fort bien.

[ToutEnMasm]

Je ne crois pas utile de justifier tout l'intérêt présenté par une syntaxe normalisée.
Le genre de détails comme préférer vous une "," içi ou un ";" là sont sans intérêt.
Une syntaxe c'est un peu comme de rouler à gauche ou à droite,il faut faire un choix.
En assembleur,le choix est facile à faire,il n'y pas de droit d'auteurs dessus.
La syntaxe de masm tend à faire la norme,on peut trouver ça excessif,je suis d'accord.Le rôle de microsoft est aussi excessif , je suis d'accord.
M'enfin,je vois mal nasm ou rosasm imposer la leur.

[Rémi Coquet]

Je ne crois pas utile de justifier tout l'intérêt présenté par une syntaxe normalisée.

Ce n'est nul par la question, mais: Qu'est-ce qu'une syntaxe normalisée en assembleur ?
Tu ne réponds donc pas directement mais tu affirmes clairement qu'en dehors de MASM rien n'a de valeur même propositionnelle.

En assembleur,le choix est facile à faire,il n'y pas de droit d'auteurs dessus.
La syntaxe de masm tend à faire la norme...

Un peu capillo-tractée la déclaration mais c'est ton avis, je le prends comme tel (sur les droits, je pense que tu t'égares un peu mais bon...)

M'enfin,je vois mal nasm ou rosasm imposer la leur.

Quels que soient les noms (cela importe peu en fait), tous ces excellents outils ont "imposé" leur syntaxe à tous ceux qui les utilisent, ce qui fait quand-même un très grand nombre de personnes hors normes et "indignes de l'assembleur" !
Je comprends que tu fasses des choix syntaxiques liés à l'outil que tu utilises mais de là à les imposer comme norme, c'est excessif non ?
(Mais non pas MASM ou Microsoft...)

Je regrette un peu le manque d'argumentation construite qui aurait pu amener un peu d'aide aux divers lecteurs.

[ToutEnMasm]

Il ne faut pas mal interpréter mes propos

quand-même un très grand nombre de personnes hors normes et "indignes de l'assembleur" !

[spidermario]

C'est également comme ça que je le comprends.

Si ce n'est pas ce que tu as voulu dire, alors reformule tes pensées.

[ToutEnMasm]

Cela veut dire clairement que le langage asm mérite d'être aussi normalisé que le C.Il n'y a rien a chercher d'autre.

[Rémi Coquet]

Cette forme est nettement plus aimable, effectivement, mais la reformulation et "l'ouverture" était indispensable à la proposition.

Pour ma part je travaille à la rédation d'un assembleur à syntaxe dynamique:

Tu peux ecrires par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
mov registre [contenu de Lp]
mov registre, [contenut de Lp]
mov registre, D$Lp
mov registre D$Lp
 
Mov registre [contenu de Lp],
      registre [contenu de Lp],
      registre [contenu de Lp],
      registre registre,
      [contenu LP] constante,
      B$Lp al

etc. (évidement, le mélange des syntaxes au sein d'un même source est déconseillé pour des questions de lisibilité, mais ce n'est pas impossible...)

et une convention de préfixes assez complète pour les déclaration noms de Labels (qui ne tous forcément que des Lp):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
LP.MaVariable ; Ce Lp pointe sur un Lp
DU.MaVariable ; Ce Lp pointe sur un DWORD Unsigned
BS.MaVariable ; Ce Lp pointe sur un BYTE Signed
STR.A.MaChaine ; Ce Lp pointe sur une chaîne ASCII
STR.U.MaChaine ; Ce Lp pointe sur un chaîne UNICODE

Les constantes sont déclarés en MAJUSCULES et acceptent les underscores:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
WM_COMMAND 0_111 (ou 0111 ou 0111hex etc.)
 
BYTE 1
WORD (2*BYTE)
DWORD (2*WORD) etc.
BOTTOM (3*DWORD)

Est-ce que cela te pose des problèmes ?

Lesquels ?

Pourquoi ?

Que proposes-tu (vous)? (hormis de refaire MASM ce qui n'apporterai rien à personne...).

[ToutEnMasm]

Salut,
Il y a un truc que j'aime bien dans le c++ et que je ne retrouve pas dans masm , c'est la distinction entre pointeur , pointeur de pointeur et valeur.
En c++ une adresse * value ,une valeur value (reduction je passe le &).
c++ ** value , fait explicitement référence à une variable contenant une adresse .
Et la on sait comment traiter automatiquement ce type de donnnée.
Il faut au moins trois lignes en assembleur pour retrouver la valeur.

avec ** on sait que l'on rentre dans un type d'adressage style interface.
Et l'on sait comment retrouver le pointeur sur la donnée cité plus haut.

Pour rester dans le sujet , un assembleur devrait aussi proposer une macro pour faire des appels com aussi simples a utiliser qu'un appel d'api.

[Rémi Coquet]

Salut,

Tu as du constaté (j'imagine) que je pars du principe que tout n'est que pointeur ou contenu de pointeur (adresse ou contenu d'adresse) soyons pragmatiques et fidèles à l'assembleur (faute d'être dignes).

Label: <- Lp

[Label1: B$ ?]

[Label2: D$ ?]

[Label3: R$ 0.1]

[Label2] ou D$Label2 W$Label2 B$Label2 F$Label R$Label3 contenus de Lp (+cast)

mov eax Label transmission de Lp
mov eax Taille Label chargement contenu Lp +cast si besoin.

mov eax Taille TYPE.Label

mov al B$DU.Label2
ou
mov al D$DU.Label2+(0*BYTE)
par exemple.

La lecture est sans ambiguité:
Charge dans le LSB d'eax le LSB du contenu DWORD Unsigned du Lp Label2

mov al D$DU.Label2+(2*BYTE)
Charge dans le LSB d'eax le 3 byte du contenu DWORD Unsigned du Lp Label2
(c'est plus compliqué à dire qu'à lire tu remarqueras !).

Cela me semble nettement moins compliqué que les * &, pas très lisibles, déjà utilisés pour d'autres fonctions nettement antérieures et très ancrées dans la mémoire collective des codeurs et surtout, trop liés au C++: Tu ne trouves pas ce genre d'écriture dans le SDK (je ne parle pas des scripts C++ proposés évidement, mais de la syntaxe proposée pour définir les divers éléments d'une structure par exemple.)

Faire de l'objet en assembleur est très aisé, il me semble qu'il n'est pas nécessaire de compliquer ou d'alourdir sa syntaxe pour le plaisir de "copier" un langage de type script qui n'est pas réputé pour sa lisibilité (sinon il faut faire carrément du C++, ce qui n'est pas vraiment "digne" de l'assembleur... non ?).

Par exemple, BYTE, WORD, DWORD QWORD, XWORD Signed/unsigned tout le reste n'est que facéties et les codeurs C++ se mélangent eux-mêmes les pinceaux dans les innombrables noms qui recouvrent les mêmes réalités. C'est le rôle d'un préfixe d'indiquer un type (la fusion taille type est une erreur à mon humble avis).
De plus, l'exemple du C++ est assez mauvais pour ce qui est de la gestion claire et transparente des Lp: la plupart de ses utilisateurs ne savent pas réèllement ce que cela représente ou ce qu'ils manipulent (désolé pour la caricature... le but n'est pas de dénigrer un language mais une volonté de rendre accessible et lisible par une syntaxe simple et sans ambiguité). Quant aux divers cast, l'assembleur permet une souplesse de montages et d'écriture nettement plus sobre et claire.

Pour COM, deux syntaxes différentes et te permettent de faire des appels COM identiques en tous points au SDK. Pour prendre un exemple général et connu, une des syntaxes possibles:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
COMCall IGraphBuilder QueryInterface IID_IMediaControl,
                                     IMediaControl

eax est utilisé en interne mais le développement de la macro permet de visualiser le code réel et de changer cela si besoin est. Je pense que cela s'approche de ce que tu désires (évoques).
Idem pour les CCAll (rétablissement de la pile selon le nombre de paramètres transmis).
Même chose pour les appels 64 bits et drivers via eax edx.

Vos sentiments...?

[Forthman]

Faudrait peut-être arrêter d'épiloguer sur le terme "indigne"

Ce que moi j'en ai compris : l'assembleur n'est pas digne d'être écrit n'importe comment.
Sous entendu il faudrait que TOUS les programmeurs assembleur puissent facilement comprendre le fonctionnement d'un bout de code écrit par d'autres

Sur ce point je suis plutôt d'accord, si l'assembleur était normalisé, je pense
qu'il aurait plus de succès.
Il n'y a qu'à voir le nombre de questions de débutants : "je n'arrive pas à compiler un programme"
Dans 99% des cas, les réponses sont du style :
"ce programme a été écrit pour xxx et tu utilise xxx, il faut donc modifier ...etc..."

a+ François

[Rémi Coquet]

Merci pour la pertinence des précisions dont tu nous fais part et la limpidité des réponses que tu apportes. Je pense que ces quelques lieux communs vont aider, à la fois Yves (qui connaît bien le sujet de la syntaxe à cause de son gros travail sur son éditeur) et plusieurs autres, à tenter de discuter sur les fondements d'une convergence constructive des syntaxes (même si je ne rêve pas encore tout éveillé évidemment ...).
Yves n'est plus un touptinenfant pour avoir besoin d'un traducteur d'intentions et je pense que nous avons encore quelques neurones fonctionnels pour un échange adulte qui tolère le second degré, la boutade ou le recadrage (ce que tu pratiques aussi d'ailleurs… ).

Remettre en cause un propos n'est pas remettre en cause la personne:
Ce que Yves à bien compris, en reformulant les "prétentions" initiales sous une forme acceptable plus facilement pour au moins deux personnes...

Donc, "le vos sentiments ?" N'était pas l'expression d'une demande de vos états d'âme, mais de vos réactions face aux 99.9999% de propositions (largement discutables) que représente mon avant dernier post.
Pour le 0.00001% Je pense que tu faisais allusion au parabolique "fidèles à l'assembleur (faute d'être dignes)". Je suis sincèrement et profondément désolé d'avoir pu te peiner plus que ne semble l'être Yves qui "résiste" bien (apparemment) à la tempête de mes attaques et de mon ton totalement outrance et d'un comique de répétition proche de l'assassinat avec préméditation et objet contondant : Je te prie donc, de bien vouloir recevoir et accepter ma très humble demande de pardon accompagnée des excuses d'une minceur digne de spécial K.

Donc, pour être conséquent avec tes avancées notoires:

Sur ce point je suis plutôt d'accord, si l'assembleur était normalisé, je pense qu'il aurait plus de succès.

L'assembleur est normalisé par le concepteur de l'électronique cible, le problème n'est pas là. Je pense donc que tu fais allusion à la syntaxe.

Il n'y a qu'à voir le nombre de questions de débutants : "je n'arrive pas à compiler un programme"
Dans 99% des cas, les réponses sont du style :
"ce programme a été écrit pour xxx et tu utilise xxx, il faut donc modifier ...etc..."

Les C/C++ (qui sont notablement différents et qui ont été les sujets d'une "guerre" fratricide pendant de longues années), n'ont pas obtenu un meilleur sort. La portabilité des scripts demeure un fantasme plus qu'une réalité quotidienne et les travers auxquels tu fais référence sont légion aussi.

Un des avantages de l'assembleur, c'est qu'il possède un nombre d'instructions relativement réduit (je veux dire que ce que tu utilise journellement est relativement restreint), et qu'il ne gère, finalement, que pointeur et contenu de pointeur. La "forme digne" est donc très variable et sujette à de nombreuses appréciations. Il paraît important qu'un outil permette plusieurs syntaxes simultanées afin de répondre à divers "lieux" et cas de figure: Spaghetti, HLL like, lisibilité de l'architecture etc.

L'assembleur étant tout, sauf rigide, permet plus que tous les scripts pour compilateurs (nous parlons bien d'assembleur) d'obtenir un résultat par un nombre de moyens extraordinaires. La syntaxe doit donc pouvoir éviter les confusions avant toutes choses: Pointeur ou contenu de pointeur ? Byte, Word, Dword, Qword, XWord ? Float/Réel ? LP DWORD ou LP sur un LP ? LP sur une Structure ou une Table ou une Chaîne U/A ?
Permettre aussi d'éviter les erreurs de typo, différencient et lire facilement les constantes d'offsets de déplacement. Pouvoir traiter les structure sous forme objet ou datas initialisées etc.

MASM ne répond pas à ses critères de manière effective et ne permet pas de soutenir plusieurs syntaxes simultanément (à moins de lui adjoindre un pré-parsher spécialisé). S'il est largement répandu (pour des raisons historiques tout aussi largement discutables et dans lesquelles je ne désire pas entrer) il n'a pas été conçu pour cela. La licence Microsoft ne permettant pas de le modifier directement, il utilise donc des éditeurs de textes (et non pas des éditeurs de sources) pour générer de véritables scripts pour compilateur. Yves, très au fait de la question, peu donc corriger, reprendre tout cela sans problème, c'est une discussion, qui j'espère, et souhaite, tournera autour de la syntaxe plus qu'autour d'un unique nom ou d'une sacro-sainte forme "digne(s)".

[ToutEnMasm]

les choses sont dites,je vais me permettre de recentrer la question.
Beaucoup de choses seraient utiles à l'assembleur, a vous de compléter.

[Rémi Coquet]

Version recentrée personnelle, puisqu'il est question de syntaxe uniquement (le sujet ne serait autrement qu'une très vaste surface à troll (ce qui peut être amusant, si les gens on un minimum d'humour, sinon les humeurs prennent le pas)):

Il serait bon que les fichiers textes (.asm) exportés par les divers éditeurs utilisés pour faire de l'assembleur, répondent à une syntaxe normalisée.
Le C et le C++ tentent de donner l'exemple en prétendant que leurs scripts sont indépendants des compilateurs, ce n'est qu'en petite partie vraie.
Les divers codeurs et les divers outils n'en souffriraient pas forcément !

La loi du PE (Pire Emmerdement) veut qu'une virgule soit toujours mal placée, comme tout fil coupé à la bonne longueur, toujours trop court.

La virgule, prend souvent un rôle qui n'est pas le sien: Celui de séparateur.
(Utiliser | serait alors plus judicieux clair et conventionnel.)

Le sens de la virgule est celui de la continuation d'un objet syntaxique, d'un raisonnement lié, ou, utilisée par pair, d'une incise.
Bien que l'utilisation du mot langage pour l'assembleur soit tirée de "langage machine", c'est une dérive de sens: Le langage est une abstraction de haut niveau contenant des concepts et des implicites interprétés. C'est le cas des scripts comme les C, C++, C# etc. Le but d'un script est de s'adresser à un compilateur qui à une grande liberté d'interprétation pour générer du code machine. J'utilise sciemment le mot code à la place de langage pour pouvoir développer la suite du principe mis en œuvre.

--------------

Une remarque (qui n'est que le fracassement de portes béantes), en forme de préambule, afin de limiter tant que possible les trolls amusants et incontournables (certains, pour ne pas se ridiculiser publiquement préfèrent les MP mais cela revient au même sur le fond):

- Un script donc, n'est pas du (trans)code mais un ensemble d'implicites soumis aux interprétations non contextuelles d'un compilateur dédié (plus vulgairement: Le compilateur ne connaît ni le sens ni l'intention de l'initiateur, il produit donc un code générique d'une manière "magique" totalement indépendante de la volonté initiale ce qui entraîne des lieux communs comme: Bien connaître son compilateur...

- L'assembleur (qui est le terme utilisé pour cette partie du forum…) n'effectue (normalement) aucune traduction, interprétation ou substitution:
Les mnémoniques ne sont qu'une version humaine des opcodes. Il n'est donc pas question de langage ici, mais de transcodage comme, par exemple, l'ASCII dans le cadre d'une déclaration de chaîne -> Une représentation absolument exacte du contenu.

--------------

La virgule donc:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
mov eax, [Lp]

Pour prendre un exemple des plus communs. Non seulement la frappe des [] n'est pas aisé (j'y reviendrais dans un autre article) mais, dans le cadre présent, la virgule n'est pas utilisée comme une continuation: C'est un séparateur inutile pour un assembleur, nécessaire seulement pour un compilateur (comme le ; en fin d'ensemble fonctionnel des scripts). Je sais que la force de l'habitude fera hausser les épaules de plusieurs, certes, mais soyons fous, optimisons la lecture, les erreurs de typos et facilitons la maintenance du code.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
mov eax [Lp]
mov eax edx
or a b etc.

Reste la virgule...
Imaginons que nous voulions documenter le code de deux manières, sans pour autant limiter ou compliquer les phases de développement et de maintenance.
La documentation en fin de ligne présente le désavantage de ne pas être forcément liée au contexte direct. La documentation sur la ligne précédente est souvent trop générique et donne des informations sur un ensemble de travail cohérent.
Par exemple, dans le cas d'un appel d'api d'OS Windows, le SDK correspondant indique:

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
 
HWND CreateWindowEx( 
       DWORD dwExStyle,
       LPCTSTR lpClassName,
       LPCTSTR lpWindowName,
       DWORD dwStyle,
       int x,
       int y,
       int nWidth,
       int nHeight,
       HWND hWndParent,
       HMENU hMenu,
       HINSTANCE hInstance,
       LPVOID lpParam
);

Le format syntaxique utilisé est celui du C par convention afin de faciliter le copier/coller pour le plus grand nombre de développeurs.
"Le sens de la virgule est celui de la continuation d'un objet syntaxique, d'un raisonnement lié.."
Ici, nous constatons que c'est le cas, que la forme est lisible, quoi que surchargée par les types (répétés deux fois).
En assembleur, et sous forme "générique"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
push lpParam
push hInstance
push hMenu
push hWndParent
push nHeight
push nWidth
push y
push x
push dwStyle
push LpWindowName
push LpClassName
push dwExStyle
Call CreateWindowEx 'NOM.DE.MODULE.NomApi'

Ce qui, bien que correcte, est assez difficile à maintenir à cause de l'inversion des arguments sur la pile. Imaginons une macro de restitution, qui ne change pas le code écrit pas le codeur mais sert de "conformateur" syntaxique:
Toujours sous forme "générique" avec de commentaires d'une qualité exceptionnelle:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
; Création de la Main Windows de mon application géniale
Call CreateWindowEx 'NomApi'  dwExStyle, ;Constantes
                                         lpClassName, ; LP CHAR
                                         lpWindowName, ; LP CHAR
                                         dwStyle, ; Constantes
                                         x,; Constante ou contenu de LP
                                         y,; Constante ou contenu de LP
                                         nWidth,; Constante ou contenu de LP
                                         nHeight,; Constante ou contenu de LP
                                         hWndParent,; Contenu de LP
                                         hMenu,; Contenu de LP ou NULL
                                         hInstance,; Contenu de
                                         lpParam ; Constante ou contenu de LP

Nettement plus lisible, de maintenance aisée, copier coller largement facilité. Nous verrons que l'ajout du nom de module avant le nom de l'API, permettrait de savoir dans quelle dll se trouve l'Api invoquée (imports etc.)
Il est possible d'étendre cela à d'autres opcodes (précédemment call devenu Call).

Imaginons un mov devenu Mov (vous l'aurez compris, la première lettre possède une casse différente afin d'indiquer qu'il est question ici d'une macro et non d'une mnémonique (imaginons qu'il est possible afficher son contenu réel en cliquant dessus par exemple, afin de voir le code réellement exporté par le moyen du fichier texte .asm).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
Mov  eax edx,
       [Lp] eax,
       ecx MAX_PATH,
       edi...

ou (en utilisant les propositions d'un post précédent pour l'indication des tailles) pour l'initialisation d'une structure WNDCLASS en datas globales

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
; Initialisation de la classe globale de la MainWindow
Mov  D$style CS_DBLCLKS+CS_BYTEALIGNCLIENT+CS_BYTEALIGNWINDOW,
       D$lpfnWndProc LP.MainWindowProc,
       D$cbClsExtra NULL,
       D$cbWndExtra NULL,
       eax D$H.Instance D$hInstance eax, ; opération liée
       D$hIcon NULL, ; il est attribué dynamiquement par la suite
       D$hCursor IDC_ARROW, 
       D$hbrBackground COLOR_WINDOW+1, ; CF SDK
       D$lpszMenuName NULL,
       D$lpszClassName STR.A.NomDeMaWindowClass

La lecture est liée à la chronologie du SDK et, là aussi, le copier/coller est largement facilité.

[Forthman]

Bonjour Rémi,

Là tu compares la syntaxe assembleur à celle des langages "humains"
Même si ce choix n'est pas très "logique" il a le mérite d'être facilement identifiable, et rapide à taper (ou alors il faudrait que le | devienne une touche directe)

A choisir l'espace comme séparateur, pourquoi ne pas remplacer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
mov al,cl

par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
cl mov al

Le problème de cette solution (cl mov al) étant à mon avis un problème
d'alignement lors de l'écriture, qui ne va pas simplifier la lecture
ou alors il faut centrer l'écriture à l'écran

a+ François

[Rémi Coquet]

Bonjour François,

Là tu compares la syntaxe assembleur à celle des langages "humains"
Même si ce choix n'est pas très "logique" il a le mérite d'être facilement identifiable, et rapide à taper

Désolé pour mon manque de clarté car ce n'est vraiment pas mon intention: Je considère, en effet, la gestion des mnémoniques comme de la gestion DIRECTE du code -> C'est un présupposé non-négociable, sur lequel je repose l'assembleur et la syntaxe de son éditeur de code.

Là où je te rejoins complètement, c'est sur le sens commun des divers éléments de syntaxe utilisés par les écritures européennes. Certains implicites facilitent nettement la lisibilité du sens, de l'intention, du contexte, sans être forcément analysés consciemment par le codeur et deviennent de facto des explicites.

-------
Le but de tout cela étant de donner à l'édition du code l'apparence d'un HLL tout en continuant à organiser directement le flux du code. C'est donc "la forme" qui change en ne touchant surtout pas au fond. C'est là que plusieurs éditeurs de texte, et non de code, échouent de manière très dommageable.
J'espère avoir clarifié ma démarche textuelle et son contexte afin de limiter les prétextes.
-------

ou alors il faudrait que le | devienne une touche directe

Effectivement, un simple échange "in-place", serait bienvenu pour assurer une interface plus ergonomique. Je te rejoins là aussi pleinement. Même punition pour les substitutions § des claviers QWERTY et le $ des claviers AZERTY.

Cependant, le sens de | est plutôt celui de segmentation logique que continuation de l'action ou simple séparateur.

Exemple ambigu:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
; Pour faire l'action ou le segment de traitement cohérent
Je fais d'abord ceci | puis cela | et enfin je termine par la résolution 
push D$lParam | pop W$MousePosX | pop W$MousePosY

Ou:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
push D$lParam
pop W$MousePosX,
W$MousePosY

Exemple basique:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
; Y = a*x+b
Fld F$F.FloatA | fmul R$R.ReelX | fiadd D$DS.DwordSignedA | fstp R$R.ReelY

A choisir l'espace comme séparateur, pourquoi ne pas remplacer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
mov al,cl

par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
cl mov al

Là, le problème est plutôt celui des rapports de forces des implicites culturels:

"Dupliquer cl dans al ou al dans cl ?". Le problème n'est pas posé par la syntaxe que tu proposes mais mis en avant, souligné à nouveau par elle. Nous avons l'habitude, en tant que Français, de commencer par la source (sujet) plus que par son attribut (cible).
Encre bleue pour Blue ink: En Glish, tout est assez illogique pour nous… Mais, en l'état des modes de colonisation actuels, il est difficile de ne pas confondre, lier intrinsèquement, syntaxe et langue (implicite culturel) comme tu le faisais remarquer dans ton préambule.

Le problème de cette solution (cl mov al) étant à mon avis un problème d'alignement lors de l'écriture, qui ne va pas simplifier la lecture
ou alors il faut centrer l'écriture à l'écran

Il est possible de d'écrire: cl = al dans la syntaxe que je propose mais je pense que la symbolique véhiculée n'est pas celle d'une duplication mais d'un constat ou d'une conséquence:

[Lp] = Call 'Module.Nomapi' Arguments...
a == b par exemple qui est un vrai casse-tête culturel.

De plus, les substitutions des mnémoniques de traitements conditionnels, comme nous allons le voir, auront besoin de ces "signes" plus liés aux constats et aux divers tests des mécanismes logiques:
>= s=> s>= etc. combinable avec la double négation ou pas (la double négation étant un domaine logique des plus pénible à suivre, il s'en trouvera largement plus utilisé et simplifié).

"Ne me faites pas dire ce que je ne désire pas ne pas vous dire"

pour:

"Vous me prêtez de propos que je désire vous tenir"

voir:

"Ta bouche je t'ennuie"

jbe / jnbe

pour

jump si <= non signé / jump si > non signé

Il est donc possible, par une même représentation substitutive, de traiter deux cas:

Le mécanisme de substitution étant déclaré sous une forme proche de: > be

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
 
Sub eax ecx
 
If eax > edx
 
    Call LpCodeTraitement
 
Qui est en fait:
 
Sub eax ecx 
 
Cmp eax edx | j> S1> ; j + ssubstitution
 
    Call LpCodeTraitement
 
S1:

Et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
 
Sub eax ecx | JmpIf > LpCodeTraitement
 
Qui est en fait:
 
Sub eax ecx | Jn> LpCodeTraitement ; j + négation + substitution

L'intention et la logique sont plus lisibles, sans la perte de control de l'assemblage ni aucune substitution opaque.
Je rappelle, que le code réel est toujours visible par simple affichage de la substitution afin de vérifier que l'assemblage est conforme à la volonté initiale du codeur.

Nous n'en sommes pas encore à l'assemblage contextuel ou conditionnel mais nous verrons que cela peut être très puissant sans la perte de la souplesse et de la puissance liées à l'encodage directe et contrôlé de l'assembleur.

[Rémi Coquet]

Juste pour préciser le cadre d'une syntaxe liée à l'assembleur:
Puisqu'il est question de "formes" syntaxiques, de "portabilité" des sources sur une même plate-forme (vous aurez lu "échange de sources entre différents assembleurs tournants sous un même OS ), je voudrais revenir sur un des problèmes de fond de cette forme:

Au début de cette discussion, une affirmation un peu péremptoire, proposait de définir comme norme syntaxique un compilateur comme Masm ; la quantité d'utilisateurs étant alors définie comme normative…

Mais voilà, justement, le problème: Masm, malgré certaines qualités, n'est pas à proprement parler un assembleur mais la partie basse d'un compilateur utilisable à la manière d'un assembleur avec quelques différences cependant.

Celui-ci ne se borne pas à proposer une simple substitution de ce qu'écrit le codeur mais il adapte les contenus, voir les modifie carrément. Il n'est pas rare de constater que le code final, une fois dé-assemblé, n'est pas le code écrit pas le codeur (API ré-encapsulées etc.). Plus évident encore, sa syntaxe oblige certaines utilisations obfsucantes: Invoke (pour prendre la plus simple) et autres macros non accessibles et non contrôlables dans leurs contenus. Une "portabilité", dans ce cas, forcerait les autres assembleurs à devenir, de manière contaminant, des compilateurs ou plus directement, de simples clones de Masm ce qui signifierait leurs disparitions à moyens termes.
Le jour ou Masm, ou plutôt les détenant de sa licence (Microsoft pour ne pas les nommer) seront capables de fournir une sortie fichier "brut", l'échange deviendra de facto possible sans contamination. Un assembleur ne pouvant pas partager un code "managé" par principe.

L'utilisation de plusieurs formes syntaxiques dans un même source, présente l'avantage de conserver les habitudes d'écriture propre à chacun, tout en garantissant un assemblage transparent, sans compilation, sans management.

La syntaxe étant avant tout un confort lié à la lisibilité, afin d'optimiser la rapidité de compréhension du code et de la maintenance de celui-ci, elle ne doit donc pas, et en aucun cas, être liée à un éditeur de logiciel ou un groupe de taille quelconque.