Un newbies de Plus (^_^) - Page 3

Kevin Kofler a écrit :
Et pas la peine d'optimiser lea en addq, A68k le fera automatiquement pour toi.

Dans le meme genre : Pas la peine de faire de l'asm, un compilateur le fera pour toi (y'a des * Kevin, je te comprends pô !)

-

pour le coup du link, pourquoi ne pas faire move.l a7,a6 et a la fin du prog move.l a6,a7 au lieu d'utiliser des fcts compliquées


et personne ne peut me dire pourquoi
lea (a0,d0.w),a0
revoie "1 undefined reference to 'a0,d0.w' " comme erreur ?

lea.l 0(a0,d0.w),a0

et pis plutot que de faire move.l #666,-(a7) on pourrait meme faire un pea #666 nan ? ce serait pas cool ?

pea.l 666 oui
merci yAro pour le

redhark> merci ca marche

Dans la derniere version de AS j'ai implementé une pseudo-instruction call qui permet d'appeller des ROM CALLs sans trop se fatiguer. Par exemple call ST_helpMsg va générer une instruction 0xF800+ST_helpMsg (F-Line emulator d'AMS) qui appelle ST_helpMsg sans avoir besoin de passer par la table de sauts d'AMS.
C'est bien beau mais ça fait fuire Kevin car ça ne marche qu'avec des versions récentes d'AMS (2.04 et 2.05 il me semble), donc j'ai rajouté aussi la possibilité de traduire call en jsr + table de sauts, qui marche partout, et c'est activable en mettant la directive old_ams (comme c'est le cas dans le header ams_c de CC).

et ya meme po besoin de mettre de .l paske pea cest que avec des dwords nan?

-

orion> vala ce que j'ai compris du fonctionnement du code de sauvegarde de l'ecran :

5:  : ; Sauvegarde ecran
6:  : move.l $c8,a5         ;jump table
7:  : pea.l 3840              ;taille a alouer, elle correspond a la taille de la mem vidéo
8:  : move.l HeapAllocPtr*4(a5),a0
9:  : jsr (a0)                   ;on alloue
10:  : move.l a0,d4         ;on sauve le pointeur dans d4 pour faire un test
11:  : tst.l d4
12:  : beq nomem           ;si =0 c'est que l'allocution a echoué
13:  : move.l #3840,(a7)  ;nombre d'octet a copier  (=taille meme vid.)
14:  : pea.l LCD_MEM        ; source  (mem vid)
15:  : move.l d4,-(a7)      ; destination (zone allouée)
16:  : move.l memcpy*4(a5),a0
17:  : jsr (a0)                  ; on copie donc l'ensemble de la mem vid dans la zone alloué
18:  : lea.l 12(a7),a7        ; on restaure a7



;et la c le contaire :

85:  :pea.l 3840               ; taille a copier          
86:  : move.l d4,-(a7)       ;source
87:  : pea.l LCD_MEM        ;destination
88:  : move.l memcpy*4(a5),a0
89:  : jsr (a0)                   ;copie  (l'ecran est restauré)
90:  : addq.l #8,a7           
91:  : move.l d4,(a7)        ;on place le ptr vers la zone alloué
92:  : move.l HeapFreePtr*4(a5),a0
93:  : jsr (a0)                  ; et on la libère

vala

-

-

-

Si tu commences déjà à optimiser un prog. de cette taille, t'en fini plus

>zdrubal: Parce que addq.l est plus rapide et prend moins de place que lea ( optimisation valable pour des valeurs immédiates inférieures à #8)

Faux: optimisation valable pour des valeurs immédiates inférieures ou égales à #8 (la valeur 0 est impossible - on peut faire add.l #0,..., mais pas addq.l #0,... -, et donc les 8 valeurs possibles sont 1-8).

>PpHd: Et pitie arretez d'utiliser le header de doorsos, il est depasse.

Non, c'est celui donné avec TIGCC et il n'est pas dépassé.
Si tu veux qu'on mette des trucs à jour dedans, dis-nous quoi. Je ne vois pas grand chose à changer. Tout ce qu'il y a dedans fonctionne en tout cas.

>azerty83: je pense que lea <ea>,-(a7) <=> pea <ea> a la taille et a la vitesse pres

Non, c'est que lea <ea>,-(a7) n'existe pas! Mais sinon pea <ea> revient à lea <ea>,-(a7) si ça existait.

>azerty83: lea (a0,d0.w),a0

Le mode d'adressage (an,dn.x) n'existe pas sur Motorola 68000. Mets:
lea 0(a0,d0.w),a0
(C'est sur la liste TODO de A68k d'accepter quand-même (an,dn.x) et de le transformer automatiquement en 0(an,dn.x).)

>Orion:
>en fait, si g bien compris, quand on fait:
>link a6,#0
>sa evite de restaurer la pile a chaque fin de fonction

Oui, c'est ça.

>azerty83: pour le coup du link, pourquoi ne pas faire move.l a7,a6 et a la fin du prog move.l a6,a7 au lieu d'utiliser des fcts compliquées

En effet, c'est possible aussi (et c'est plus optimisé). Mais l'intérêt de link est de pouvoir passer une valeur non nulle, et donc allouer de la place pour des variables locales sur la pile en même temps.


Au fait, voilà une version A68k de call:

call macro
 ifd old_ams
 move.l $c8,a0
 move.l \1*4(a0),a0
 jsr (a0)
 endc
 ifnd old_ams
 dc.w $f800+\1
 endc
 endm

m call macro  ifd old_ams  move.l $c8,a0  move.l 1*4(a0),a0  jsr (a0)  endc  ifnd old_ams  dc.w $f800+1  endc  end

-

Déjà, il y a une clé (du moins il y avait, j'ai l'impression que yAro l'a retirée ).
Ensuite, yAro utilise une protection qui fait que tu ne peux pas émettre un post à partir d'une simple URL (par passage de variables PHP).

-

ben c normal ton floodeur c un truc qui reproduit du manuel.

zrd> la protection existait déjà sur la 1, le referer check

Quelle protection ?
Sur la 1 on pouvait émettre des posts juste à partir d'une URL et maintenant non ...

-

-

ben si a6....

(et la un lea 10(a7),a7 c ptet mieux non ?)

-

C'est inutile. link et unlk sauvegardent et restaurent a6 automatiquement.

Sinon, ton programme détruit d0-d2/a0-a1 à cause du ROM_CALL, mais il a le droit de le faire.

-

<<
move.l #$0000005D,-(a7)
move.l #$00A0005D,-(a7)
>>

Beurk c'est horrible ça !!
1) Utilise pea, c'est plus rapide.
2) Je te conseille quelque chose de beaucoup plus lisible et qui permet de changer les valeurs sans avoir de conversion à faire :
pea (93)+(0)*$10000
pea (93)+(160)*$10000
(Les parenthèses c'est pour la clarté)

-