Assembleur 68K

[fhtagn]

fhtagn

#213911

Comme tout bon Amigaïste qui se respecte (  ), dés que je peux, j’exporte la bonne parole.

 

Or, j’entend souvent ici et là que l’assembleur 68k est un des plus agréable à utiliser.

 

J’aimerais donc savoir pourquoi, pour ma culture personnelle et pour également pouvoir l’expliquer à ceux qui n’avaient pas la chance d’avoir un Amiga  durant les années bénies du règne de notre machine favorite.

 

Merci à tous.

[Anonyme]

Anonyme

#213931

La syntaxe est agréable à lire et le 68k permet plein de modes d’adressage. Après je pense c’est surtout l’Amiga qui est agréable à utiliser. Car coder du 68k pour un périphérique quelconque c’est tout de suite moins fun 🙂

[b0ris747]

b0ris747

#213932

68k et ARM, c’est lisible. Intel c’est illisible.

La gestion des registres est plus claire en 68k et ARM que Intel.

Pour avoir fait de la retro-conception ARM (déssassemblage puis analyse), je peux te dire que je préfére à Intel. 68k est comme ARM, bien pensé.

D’autres t’en diront plus, moi je suis trop nul, mais j’aurai pas eu les mêmes résultats avec un intel (EAB, EBX… merde quoi….)

35m2 == 35m3 de matos - Membre de l'ART

[Jul]

Jul

#213933

Il y a pire que l’Intel : le PPC. C’est le seul assembleur qui m’ait découragé… Corto ne partagerait sans doute pas mon avis. 🙂

Prédateur Chess | Amiga 500 + ACA500 | Amiga 1200 + ACA1233

[Anonyme]

Anonyme

#213936

Le PPC est très bon aussi. En 1 ligne tu peux faire 2 ou 3 opérations à la fois en seulement quelques cycles. Par exemple avec 1 instruction (je les ai plus en tête), tu pouvais faire 1 move, 1 décalage et masquer. C’était puissant !

 

 

[modulo]

modulo

#213943

Vous en avez marre de l’assembleur au 21ème siècle ? Vous recherchez encore les palpitations et la vie sur le fil de votre jeunesse ?

Pour les amateurs de sensation forte, il y a le C89.

 

[code]

/*copie, incrémentation,test, effets de bord. Prions très fort mes frères.*/

while(*dst++=*src++);

[/code]

Supporté par tous vos compilateurs, essayez dès maintenant !

(n’essayez pas ça à la maison, les enfants).

[Anonyme]

Anonyme

#213944

Je serais curieux de voir le résultat en langage machine…

[modulo]

modulo

#213948

Un désassemblage donne ça, compilé sur un 64 bits «générique» avec le niveau d’optimisation classique de gcc (-O2)

 

%rdx est la source

%rcx la dest

%esi sert pour le test de fin de chaine.

 

[code]

.L2:

addq    $1, %rdx
movzbl  -1(%rdx), %esi
addq    $1, %rcx
testb   %sil, %sil
movb    %sil, -1(%rcx)
jne     .L2

[/code]

À priori, on ne fait plus de «rep stosb» avec les Intel 🙂

Comme le temps passe 🙂

edit: pas de changements avec un -mtune=core2 pour voir un peu si il utilise les possibilités du SSE.

[Jul]

Jul

#213953

@modulo:

tu le sais sans doute, mais si tu as compilé avec les symboles de déboggage tu peux générer un source assembleur très lisible en faisant ça :

> gcc -g -c test.c
> objdump -d -M intel -S test.o

Sinon, tu peux exporter le fichier assembleur intermédiaire directement avec gcc (mais là ce ne sera pas aussi compréhensible qu’avec objdump, paradoxalement 🙂 ) :

> gcc -O2 -S -c test.c

Prédateur Chess | Amiga 500 + ACA500 | Amiga 1200 + ACA1233

[modulo]

modulo

#213958

Merci de l’info Jul, ça peut toujours servir en cas de doute… même si je ne fais pas dans l’exotisme à ce point.

Je générais le source ainsi: gcc -O2 -S test.c

(pas besoin de -c, -S s’arrête après la production du source).

 

Avec ta méthode, on obtient le beaucoup plus lisible:

[code]

while(*dst++=*src++);
20:   48 83 c2 01             add    rdx,0x1
24:   0f b6 72 ff             movzx  esi,BYTE PTR [rdx-0x1]
28:   48 83 c1 01             add    rcx,0x1
2c:   40 84 f6                test   sil,sil
2f:   40 88 71 ff             mov    BYTE PTR [rcx-0x1],sil
33:   75 eb                   jne    20 <main+0x20>

[/code]

 

C’est quand même autre chose que l’horrible syntaxe AT&T 🙂

[AmiDARK]

AmiDARK

#213962

while(*dst++=*src++);

En assembleur 68k ça donnerait un truc comme ça si je me souviens bien :

Lx:

cmpa.l (a0), (a1)
add.l #1, a0
add.l #1, a1
beq Lx
Informations : les 680×0 contiennent 8 registres d’adresses et 8 registres de données ( les FPU 68881/2 et 68040/68060 contiennent aussi 8 registres de variables flottantes).
Intel ne contient je crois que 2 registres données et 1 registre mémoire et oblige à swapper sans arrêt ces registres pour faire des opérations avec …

[Jul]

Jul

#213963

Ohlala, Amidark, c’est complètement faux ! 🙂 C’était en partie vrai avec le 8088, notamment avec son clone Z80, mais c’est complètement faux depuis belle lurette.

http://fr.wikibooks.org/wiki/Programmation_Assembleur_x86/Registres

Et les extensions du x86 (genre MMX et autres…) ont apporté des dizaines de nouveaux registres. 🙂

Prédateur Chess | Amiga 500 + ACA500 | Amiga 1200 + ACA1233

[Jul]

Jul

#213964

Par ailleurs, même si j’aime beaucoup l’asm 68k, j’ai toujours trouvé que l’assembleur x86 (16/32 bits) était vraiment très simple. Plus que le 68k. Je suis le seul ?

Prédateur Chess | Amiga 500 + ACA500 | Amiga 1200 + ACA1233

[modulo]

modulo

#213965

Amidark:

Attention en C, le simple égal est un opérateur d’assignation.

(pour la comparaison, c’est == ).

Les compilos récents préviennent quand on fait des trucs louches dans le genre de mon while. Dans le cas du while, il faudrait au minimum un double parenthésage pour confirmer que l’on veut effectivement tester la condition logique résultant de l’affectation.

Je raconte ça, car j’ai l’impression que ton code fait une comparaison sans affectation.

D’autre part, comme je l’ai dit plus haut, on peut également choisir d’écrire un «stosb» préfixé par un «rep» qui provoque la répétition sur un compteur donné par CX. Les pointeurs sources et destination sont incrémentés après chaque «stosXX» (on peut faire du stosb,stosw,stosd). Ce n’est plus utilisé ni généré par les compilos, car ça fait facile 15 ans que ce n’est plus optimal.

Pour les registres, c’est clair qu’on se traine l’héritage 80×88. Il y a quand même eu pas mal de progrès depuis le 64 bits, avec des registres génériques. La prochaine génération abandonnera sans doute tout l’héritage 80×88 (déjà qu’on parle de souder les procs au cartes mères :/ ). Je ne connais pas l’assembleur moderne Intel, j’ai abandonné après le Pentium MMX.

 

Edit: grilled by Jul (moi aussi je préfère la syntaxe Intel, tout comptes fait. Question d’habitude je suppose, on préfère ce sur quoi on a appris. Il n’empêche que le 68k était beaucoup plus élégant que le 80×88, je pense que nous sommes tous d’accord là dessus).

[AmiDARK]

AmiDARK

#213975

Oui c’est vrai … Et dire que je code en C pour l’AmiDARK Engine … Je crois que c’est de penser “assembleur” qui m’a fait sauter ce détail …

 
<p style=”font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11px; color: rgb(37, 37, 37); line-height: normal; background-color: rgb(255, 255, 221);”>while(*dst++=*src++);</p>
<p style=”font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11px; color: rgb(37, 37, 37); line-height: normal; background-color: rgb(255, 255, 221);”>En assembleur 68k ça donnerait un truc comme ça si je me souviens bien :</p>
<p style=”font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11px; color: rgb(37, 37, 37); line-height: normal; background-color: rgb(255, 255, 221);”>Lx:</p>
<p style=”font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11px; color: rgb(37, 37, 37); line-height: normal; background-color: rgb(255, 255, 221);”>Move.l (a0), (a1)
Cmpa.l (a0), (a1)
add.l #1, a0
add.l #1, a1
Beq.l Lx

Je crois que add.? ne modifie pas les compteurs d’erreurs si il n’y en a pas …</p>
<p style=”font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 11px; color: rgb(37, 37, 37); line-height: normal; background-color: rgb(255, 255, 221);”></p>