Question con - Page 2

parce que c'est plus lent.
Et comme tu dois mettre un rts après, bah ça devient plus gros.

non je parlais de pkoi: bsr n'etait pas optimisé en bsr.s

De toute façon, un bsr.s doit être assez rare, vu la taille de tes fonctions

lol :Þ

...
elles seront largement plus petite qu'il ne le faut

Mais de façon générale, un bsr.s doit être assez rare.

non pas forcement..

JackosKing
: non je parlais de pkoi: bsr n'etait pas optimisé en bsr.s

Quand c'est possible, c'est optimisé.

Et ton problème était que ta fonction n'était pas réentrante à cause de ta variable statique. (On te l'a déjà expliqué, mais sans le terme technique. )

oui j'avais deja corrigé
pourquoi tigcclib n'externalise pas la fonction de recopie de buffer?

Parce qu'elle est inline dans l'interruption de gris.
Tu peux utiliser FastCopyScreen de ExtGraph.

bein oui mais il suffit de mettre a part la fonciton CpyScr, et tu l'appelle dans la routines de grays.. ya pas de problem un pti jsr et ops

Non. Ça ralentirait l'interruption de gris.

chez moi ca marche nikel..

au fait c'est quoi le mieux bs ou jbsr?

tien autre question, exg.w n'est pas supporté par asmGNU?

JackosKing
: tien autre question, exg.w n'est pas supporté par asmGNU?

exg.w n'existe pas.

avec a68k, j'ai essayé, ca compile, est-ce qu'il remet exg ?

en effet

#43: jbsr sera toujours optimisé au plus petit branchement possible vers une subroutine. Si > 32K, c'est jsr, sinon bsr, éventuellement bsr.s.

exg.w n'existe pas, pas plus que btst.w, moveq.w et quelques autres horreurs du même style (toujours supportées par A68k car utilisées par certains programmes, par exemple moveq.w une vieille version de ziplib).

erf dommage cela m'aurait for bien arrangé

jackiechan
: Mais de façon générale, un bsr.s doit être assez rare.

Pourtant la majorité des sauts de GX sont des bcc.s

JackosKing
: au fait c'est quoi le mieux bs ou jbsr?

jbsr. Sinon, GNU as te sortira un bsr.w à tous les coups.

nEUrOO
: avec a68k, j'ai essayé, ca compile, est-ce qu'il remet exg ?

Oui. Et ce n'est pas la seule instruction illégale qu'il accepte sans broncher (et assemble n'importe comment).

XDanger
: exg.w n'existe pas, pas plus que btst.w, moveq.w et quelques autres horreurs du même style (toujours supportées par A68k car utilisées par certains programmes, par exemple moveq.w une vieille version de ziplib).

En effet, voici la raison pour laquelle je n'ai pas renforcé les tests: pas mal de programmes utilisent ces instructions illégales, et ils ont la chance que l'instruction sortie par A68k fonctionne.

Mais movem.w existe (mais est inutilisable pour la sauvegarde des registres parce que ça fait une extension de signe, même avec les registres de données).

Comme instruction invalide, il y a aussi dbxx.s...

#50: tu veux dire BCC (opcode qui existe) ou bxx (terme générique pour désigner les branchements, que je préfère à "bcc" car BCC existe) ?

si il a mis cc en italique c'est qu'il y a une raison

Ah, oui, désolé, je n'avais pas vu que "cc" était en italique...
Pourquoi ne pas utiliser GNU as qui n'accepte pas d'opcodes invalides, et améliore les branchements tout seul si on met jbxx au lieu de bxx ?

Thibaut
:

jackiechan
: Mais de façon générale, un bsr.s doit être assez rare.

Pourtant la majorité des sauts de GX sont des bcc.s

Tous les sauts (saufs quelques-uns plutôt rares) des fonctions d'ExtGraph sont codés sur des bytes. Mais bcc != bsr.

Je parlais aussi de bsr.s. Toi aussi t'es un fana de rigueur ?
Disons, bxx.s comme le suggère XDanger

> "bcc != bsr"

Hum, ça dépend de quel point de vue. Si on définit les bcc comme la ligne 6, c'est faux.

la ligne 6 ?

ligne 6 = $6000..$6FFF

(comme ligne F = $F000..$FFFF - cf ROM CALLs en F-line)