Quel compilateur choisir pour l'assembleur ?

[forthx]

j'assemble de puis pas tres longtemps avec tasm mais je sais pas m'en servir et je me demandais si il existait des compileurs 'facile et puissant'

sinon si vous savez ou je peu trouver de la doc sur tasm (si possible en francais)


enfin sous linux qu'est ce qui existe pour assembler?


merci d'avance!

[2PluS4]

Comme assembleur facile et puissant (et qui marche sous linux) , il existe Nasm:
http://sourceforge.net/projects/nasm/

[Smortex]

Personellement, j'utilise FASM : petit, complet, performant, et l'auteur est très actif : chaque fois que je vais sur le site pour vérifier l'url, il y à une nouvelle version !
http://fasm.sourceforge.net

[forthx]

lut smortex c'est moi deqth apres stx asmed j'ai pris fasm mais ya plein de truc qui son differents de tasm: PROC NEAR il en veu pas, les include je sais pas comment ca marche, l'ecriture directe en mem graphique ca marche pas pareil non plus... si il existe de laide sur fasm (et des exemples ) ce serait surement plus facile de changer!

[Smortex]

Personellement, je le trouve moins ch*** que certains compilos : un programme genre :

  org 100h
  Xor Ax,Ax
  Int 16h
  Ret

Marche Impec ! Pas besoin de trimbaler "Machin:", "END Machin" et autre...

Certe, la doc de FASM est relativement pauvre (Elle n'est pas terminée), mais je ne trouve pas que ca soit un problème car :
- On trouve pas mal d'exemples sur le site de FASM.
- On peut trouver un OS développé entièrement avec FASM.
- Les sources sont fournies avec l'exe.

Généralement, les modifications à apporter à un code sont mineures : Es:[Di] devient [Esi] ; JMP LONG devient JMP FAR, ... Mais ca n'est qu'une question d'habitude.

Le seul défaut que je trouve à se compilateur est au niveau de la recherche des fichiers include : il ne scane pas le dossier du .asm que l'on compile et cela peut poser des problèmes si on compile depuis un autre dossier (Je vais en parler à l'auteur, sauf si cette fonctionnalité à été ajoutée dans la dernière version).

[BuG]

Ya masm aussi un assembleur sous windows, je crois que c'est un Freeware développé par micro$oft allucinant non ?

http://www.protools.cjb.net

Je suis pas sur de l'URL.

Salut @+

[Argh!]

moi j'utilise NASM que je trouve plutot bien :
* Gratuit
* Existe sous Windows et Linux
* pas chiant
* Documenté correctement

[Causa Sui]

Je suis peut-être un mais j'ai toujours du mal avec FASM...
Sinon vu que je ne suis qu'un noob j'utilise encore parfois le debug de windows

[Android317]

Bonjour a tous...

Pour info, vous pourrez trouver tout ce dont vous avez besoin pour MASM32 ici :
http://www.chez.com/asmgges/index.htm
qui integre une IDE, les LIBS, les en-tetes, etc, etc... Plus les excellents "tutoriaux" de Iczelion !

Il existe aussi un autre compilateur pour Win32 qui s'appele SpAsm bien equipe et disponible ici :
http://betov.free.fr/SpAsm.html

NOTA : MASM est base sur la syntaxe INTEL, tandis que SpAsm est comme NASM, c.a.d base sur la syntaxe AT&T

Avantages et inconvenients :
MASM est disponible que sous Win32
Syntaxe plus intuitive
Facilite d'utilisation
En plus la syntaxe utilisee est la meme que lors de l'integration de code ASM sous VC++ (portage code...)

NASM est dispo sous Win32 et Linux
Syntaxe plus precise, mais moins intuitive
Forte communaute de developpeur

Voila c'est tout..

[ovh]

J'utilisais TASM / TASM32, mais récemment je me suis mis à NASM et il m'a séduit ! Certes au début il faut un peu s'habituer à la syntaxe, mais la doc précise tout ce qu'il faut savoir, et d'autre part, la syntaxe est plus simple et plus rigoureuse (plus proche de la machine). Attention toutefois, NASM n'est qu'un assembleur, il te faut en + un linker pour produire du code exécutable. Sous Win32, le couple NASM + ALINK marche très bien, à condition d'avoir également les fichiers win32n.inc et win32.lib (respectivement pour nasm et alink).
Voici un "hello world" version nasm :

; NASM pour win32 : premier test
; Compile: nasmw -fobj prog.asm -p C:\nasm\inc\win32n.inc
;          alink prog.obj -oPE -o prog.exe C:\alink\win32.lib

extern MessageBoxA
extern ExitProcess


section .data use32
  titre db 'Premier test',0
  msg   db 'Voilà ça marche NASM ;)',0


section .text use32

..start                   ; entry point
  push	0
  push	titre
  push	msg
  push	0
  call	MessageBoxA
  
  push	0
  call	ExitProcess

[Android317]

Tres juste OVH, il te faut en effet un linker pour creer un PE. ALINK est un excellent choix
Ceci dit, si tu commence a Start Adress 0100h, et que tu fais un *.com tu n'en a pas besoin

[ovh]

Effectivement, et tu me fais penser que nasm permet de créer facilement aussi des secteurs de boot par exemple, mais aussi d'inclure des fichiers binaires dans le source etc. Bref, nasm c'est du tout bon

[Blustuff]

Je ne vois pas en quoi la syntaxe est plus rigoureuse ou plus logique, ni même plus proche de la machine

[Causa Sui]

Je me posais une question sur lec ompilateurs... est-ce que ils sont compatible avec les prcocesseurs les plus avancés, je veux dire: signalent-ils comme faux les intructions de 3DNow! d'AMD, par exemple, ou supportent-ils les intructions basées sur des reg64?

[TangiX]

cela depend des compilateurs certains propose les instructions tel que sse 3DNow! ect.
sinon il bloque puisqu'il ne connait pas l'instruction
il est toutefois possible de coder toutes les instructions en langage machine :
db 90h = Nop

[ovh]

Envoyé par Blustuff

Je ne vois pas en quoi la syntaxe est plus rigoureuse ou plus logique, ni même plus proche de la machine

Parce que NASM ne s'encombre pas de pseudo-code comme les "proc" de TASM par exemple. Au niveau des adresses effectives, même chose : le mot-clé "offset" est inutile, et la syntaxe de nasm impose de mettre toute l'adresse entre crochets. Pas moyen donc de mettre mov ax, es:[bx] mais il faudra mettre mov ax, [es:bx]. Et c'est comme ça que ça apparaît dans un déboggueur --> plus proche de la machine.

Plus de détails ici :
http://194.65.3.199/win32asm/tutorial/gij.html

[Blustuff]

- La directive PROC permet de definir une convention d'appel et de générer des codes prologues/epilogues. Je ne vois pas en quoi elle est inutile.

- Le mot clé offset a son utilité. Ces deux assembleurs on choisi d'opter pour la convention d'ecriture dans laquelle un nom de variable designe son contenu. Ansi après la déclaration :

Variable dd ?

'Variable' designe le contenu de la mémoire. D'où dans se modèle l'utilité du mot clé offset. Maintenant ce qui justufue ce choix, est la compatibilité avec les langafges de haut niveau. Il est absurded de programmer entièrement en asm c'est important. En C après la déclaration :

  int Variable;

'Variable' designe bien le contenu de la variable, et &Variable son adresse. En cela cette syntaxe est très coherente.

- Dans le débuguerur que j'utilise la syntaxe es:[bx] est utilisée.

[le mage tophinus]

- Pour être utilisateur de TASM, je n'utilise jamais les PROC, donc même dans TASM ça peut être oublié s'il le faut

- Je suis d'accord avec Blustuff que l'offset est important. Il y a une différence énorme entre :

mov ax,variable

et

mov ax,offset variable

Le premier est codé par A1h et met dans AX le contenu de 'variable'. Dans le deuxième cas (codé B8h), on met dans AX l'adresse (offset) de où se situe 'variable '. Y'a quand même une énorme différence qui apporte souvent des erreurs de programmation

- Au niveau du debugger, moi aussi je n'ai que des es:[bx] et pas de [es:bx]. Mais je pense que c normal car on doit avoir les mêmes debuggers avec Blustuff. Par contre, dans toute la litérature que j'ai lu, tout le monde adressé de la manière es:[bx] et pas de la manière [es:bx]. A se demander si ce n'est pas une "norme" ?

[AznOod]

L'équivalent avec NASM serait:

        mov        ax,[variable]        ; Place le contenu de variable dans AX

        mov        ax,variable          ; Place l'adresse de variable dans AX

Il n'y a pas d'ambiguités possibles.

[le mage tophinus]

je préfèrerais quand même un compilateur avec comme notation :

mov ax,[variable]
mov ax,offset variable

Comme ça, il n'y aurait pas d'ambiguité, surtout pour les débutants