Questions ASM

15 sujets de 31 à 45 (sur un total de 50)

bombseb
23 juin 2014 à 10h33 #213525
Oui c’est ce qu’a expliqué Tcheko : Certains assembleurs fainéants compilent move.l 4, a6 en traitant le « 4 » comme une valeur 32bits, c’est pourquoi il peut être utile de préciser .w pour que cette valeur soit bien considérée comme une valeur 16bits (et donc pour gagner 2 octets)
Mais le résultat à l’exécution est le même
lexomil
23 juin 2014 à 10h57 #213526
L’intérêt de spécifier .w sur ton adresse c’est en gros de gagner 2 octets sur l’opcode (des fois c’est magique 2 octets quand tu veux faire tenir ta routine dans le cache du 020) et aussi de gagner 4 cycles de CPU vue qu’il y’a moins de données à décoder.
Sodapop
23 juin 2014 à 11h33 #213527
Disons que sur ce genre de portion de code, une optimisation de ce type n’a aucun interet… et faire un move.l 4.w,a6 ça revient un peu à dire que l’eau ça mouille… 😉

Dans le cas présent, ça peu embrouiller un débutant… et même Astrofa… 😉
Donc ne pas croire qu’on ne récupère que 16 bits de l’adresse $4 en faisant un move.l $4.w,a6

A500 (1.3 / 2.0 / ACA500+) - A2000 - A1200
lexomil
23 juin 2014 à 11h47 #213528
oui bien sur, ce .w là ne détermine que la taille de l’opérande, pas la taille des données à transférer qui est elle donnée par le .l de la mnémonique.
Mod
Tcheko
23 juin 2014 à 12h49 #213531
Sauver des octets c’est toujours bon. Même pour une portion de code exécuté une fois.

La gourmandise actuelle, c’est un Windows8 qui prends 20Go de disque pour s’installer (j’ai pas le chiffre exact mais la dernière fois que j’ai voulu faire une sauvegarde de réinstallation sur DVD, j’ai abandonné tellement c’était ridicule le nombre de DVD…).
Sodapop
23 juin 2014 à 13h15 #213532
Ouais…. mais on est pas non plus sur Spectrum ! 😉
Ben ça fait une grosse discussion pour un malheureux move.l ! LOL
Avec ça, si Bombseb ne progresse pas…. avec le HRM et La Bible tout devrait s’éclaircir pour ce qui est des custom chips…. tu comprends mieux le fonctionnement de la copper-list plus haut ?

A500 (1.3 / 2.0 / ACA500+) - A2000 - A1200
thellier
23 juin 2014 à 13h34 #213534
@sodapop
>oui, en fait il s’agirait d’un move.l $4.w,a6 qui n’a de toute façon aucune utilité puisque le mot long (.l) est pris en compte quoiqu’il arrive (seul un move.w fonctionnerait)

MAIS NON
justement on te dis que en binaire dans un cas on aura
16 bits du code instruction du Move suivi de
32 bits de la valeur $00000004
————————–
48 bits utilisés
>c’est du 48 bits là !)
Comme tu vois OUI = 16+16+16

et dans l’autre cas
16 bits du code instruction du Move
16 bits de la valeur $0004
————————–
32 bits utilisés
Dans ce cas le cpu « étend » le registre en remplissant les 16 bits manquant avec des 0

Il existe aussi des instructions MOVEQ qui n’ont pas d’opérande
(la valeur de 0 à 7 (cad 3 bits) est contenu directement dans les 16 bits du code instruction du Move)
16 bits du code instruction du MoveQ
————————–
16 bits utilisés

Au final je crois que execbase (à vérifier) est mis dans d0 au démarrage d’un prog amiga
….donc méme sans ce move ça marcherait 😛

Ce genre d’économie a juste son intérêt dans un booblock de disquette ou le « prog » fait juste 1024 (!!) octets

Alain
Sodapop
23 juin 2014 à 13h49 #213536
En fait je crois qu’il y eu une grande confusion entre le codage des instructions et l’état des registres après ces instructions… au départ Bombseb voulait dire que A6 était chargé avec la même valeur que ce soit avec un move.l 4.w,a6 ou un move.l 4,a6 (et suite au post d’Astrofa, il disait: bizarre, pourquoi on n’utilise pas plutôt move.w 4,a6 alors ?). Donc en gros j’expliquais la différence quand à la valeur de A6 dans les différents cas… pas le codage des instructions… mais on a fini par tout embrouiller je crois ! 😉

A500 (1.3 / 2.0 / ACA500+) - A2000 - A1200
thellier
23 juin 2014 à 13h55 #213537
Salut encore

Sur les copperlist, et les registres des customchip en général, je te conseillerai de les définir avec des constantes et de laisser aussi le macro-assembleur faire les calculs à la compil à ta place
Voici un exemple de bout de copperlist écrit (en ASM !) avec devpac

dc.w bplcon0,nbre_Bitplanes*$1000+$200,bplcon1,0,bplcon2,$1b
dc.w bpl1mod,(large-screenlarge-16)/8,bpl2mod,(large-screenlarge-16)/8
dc.w ddfstrt,$038-8,ddfstop,$0d0
dc.w diwstrt,$2c81,diwstop,$2cc1
dc.w dmacon,$8020

Par exemple devpac remplacera (large-screenlarge-16)/8 par la bonne valeur calculée à la compil
bombseb
23 juin 2014 à 22h17 #213550
Ah oui justement je voulais vous demander, s’il y a possibilité de trouver des fichiers à inclure contenant toutes les constantes du système…C’est vrai que je préferre faire comme ca je trouve ca plus propre…

Avec ça, si Bombseb ne progresse pas…. avec le HRM et La Bible tout devrait s’éclaircir pour ce qui est des custom chips…. tu comprends mieux le fonctionnement de la copper-list plus haut ?

Oui oui je comprends mieux maintenant comment ca marche c’est bien expliqué dans le pdf Amiga hardware reference…
Sodapop
23 juin 2014 à 22h37 #213551
Oui bien sûr ça existe, j’ai tout ça fournit avec Devpac, ce sont les fichiers « Include » !
Tu peux les trouver facilement sur le net

Tu as par exemple le fichier « Custom.i » qui possède toutes les valeurs des registres des circuits spécialisés (copper, blitter…), et beaucoup d’autres…

A500 (1.3 / 2.0 / ACA500+) - A2000 - A1200
Anonyme
23 juin 2014 à 22h56 #213553
@bombser a ecrit :

<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.w toto,a0
move.w (toto),a1</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); »>quand je lance mon prog les registres a0 et a1 ont la même valeur…. (j’ai mi toto dc.b $44 un peu plus bas)</p>

Je ne sais pas si qqun a déjà fait la remarque, mais, tu définis une valeur en .b (dc.b) et tu le charges avec un .w (move.w), il y a un risque assez élevé que ton programme plante ou retourne avec un code erreur si l’assembleur bloque l’exception. En effet, l’adresse toto peut éventuellement se trouver à une adresse impaire et le move.w ne peut, lui, charger que des adresses paires.
Anonyme
23 juin 2014 à 22h59 #213555
Bon, mon texte est tout cassé… :/
thellier
24 juin 2014 à 11h17 #213605
Dans devpac tu pouvais aussi définir les appels systèmes avec des macros de ce genre

_OpenScreen: macro
move.l intuitionbase,a6
lea \1,a0
jsr -198(a6)
endm

_OpenWindow: macro
move.l intuitionbase,a6
lea \1,a0
jsr -204(a6)
endm

Puis avoir des progs ASM (!!) avec ce genre de syntaxe propre

_OpenScreen ecran_defs
move.l d0,screen_handle

_OpenWindow fenetre_defs
move.l d0,window_handle
bombseb
24 juin 2014 à 12h02 #213611
Thellier : Ah oui c’est bien pratique les macros aussi… la syntaxe est la même sur ASMOne ?

Sodapop : Ah oui super, j’ai téléchargé Devpac, sur la deuxième disquette il y a tout ce qu’il faut…