encore une chtite question - Page 16

c normal, le signe << n'est pas une instruction valide
dans le contexte, ça voulait dire (IMM2 x $10000) + IMM1

Extrait du "68000 assembler user's manual" de Paul McKee:

 2.3.2  Operators in Expressions 

     The operators allowed in expressions are shown in the fol 
lowing table, in order of decreasing precedence. Within each 
group, the operators are evaluated in left-to-right order (except 
for group 2, which is evaluated right-to-left).


                    Operators in Expressions

     1.  ()  Parenthesized subexpressions
     2.  -   Unary minus (two's complement)
         ~   Bitwise not (one's complement)
     3.  <<  Shift left (x<<y produces x shifted left by
                         y bits and zero filled)
         >>  Shift right
     4.  &   Bitwise and
         !   Bitwise or
     5.  *   Multiplication
         /   Integer division
         \   Modulus (x\y produces the remainder when x
                      is divided by y)
     6.  +   Addition
         -   Subtraction

Ximoon> C'est quoi ces priorités différentes de celles du C ?

Chais pas. Ceci dit le document est très vieux

Voici ma documentation officielle (basée sur direct.txt par Mathieu Lacage, mais j'ai reformulé tout pour que ce soit plus clair et pour respecter ses droits d'auteur):
http://tigcc.ticalc.org/doc/a68k.html#directives
Première entrée: "arithmetic operators".

ma documentation officielle

klr, mdr ^^

C'est moi le mainteneur de A68k pour TIGCC, donc ce que je mets comme documentation est officiel. Et comme il n'y avait aucun mainteneur avant, je me suis permis de m'auto-proclamer mainteneur.

Tiens, d'ailleurs la documentation "officielle" est moins précise que la documentation "obsolète" sur les priorités... C comme en C ou pas?

Regarde les sources. Je n'en ai aucune idée. J'ai dû regarder pas mal les sources pour écrire ce morceau de la documentation (direct.txt était incomplet et parfois même incorrect), mais je n'ai pas vérifié les priorités.

./449 -> ./447 Desole

Flanker
:

Qui pourrait être transformé en addq si N<=8, sans que le programmeur n'ait à s'en soucier.

dans le cas général, sûrement. Mais imagine que le codeur aime bien les trucs assez laids qui modifient l'instruction de temps en temps. Il a donc besoin de connaître la longueur de l'instruction et n'a pas envie qu'elle soit changée dans son dos

tiens ça m'est déjà arrivé ça
j'avais mis une grosse constante pour corriger le pb #huhu#

(m'enfin c'était juste pour tester une routine)

Kevin Kofler :

 __gray3P_continue_cleanup:
-       lea      (__gray3P_L_plane,%pc),%a0  | restore plane pointers to 0x4c00 for sure
-       move.l   #0x04c00,(%a0)+
-       move.l   #0x04c00,(%a0)+
-       move.l   #0x04c00,(%a0)+
-       move.l   #0x04c00,(%a0)
+       lea      (__gray3P_L_plane,%pc),%a0  | restore plane pointers to tios__001c for sure
+       move.l   #tios__001c,(%a0)+
+       move.l   #tios__001c,(%a0)+
+       move.l   #tios__001c,(%a0)+
+       move.l   #tios__001c,(%a0)

Je comprends rien, où bien ton code est très très mal optimisé en taille ?

Albert Instinct
: Je comprends rien, où bien ton code est très très mal optimisé en taille ?

Comme tu peux voir, l'original n'était pas mieux.

Si, il avait 4 relocations de moins

Mais le principe est le même.

Des gamins. Peuh, je fais pareil!

Kevin : c'est le code qui est dans la bibliothèque de TIGCC ?
Alors n'aies plus le culot de dire que tu prônes l'optimisation taille au détriment de la vitesse... honteux

C'est également lent !

Oui, mais lea existe. Ce code n'est pas optimisé du tout, ni en taille, ni en vitesse. Mon but était de porter le code, pas de l'optimiser.

ah bah belle mentalité

Honteux !
Si backtruc est comme ça...
Et si les codes de démarrage de TIGCC sont comme ça...

Albert Instinct
: Si backtruc est comme ça...

Tu veux dire Backgammon? Par passages (routine de sprites par exemple), c'est certainement optimisable. Pour Backgammon, la priorité n°1 était que ça fonctionne et que je ne passe pas trop de temps à le développer. Mais la taille est aussi très raisonnable (moins de 16 KO non compressés, à peu près 8 KO compressés), et la vitesse est largement suffisante (tout a l'air instantané).
Et puis le portage des niveaux de gris pour Fargo fait aussi partie de Backgammon (je n'ai jamais sorti un portage officiel - si je voulais faire ça, je commencerais par porter aussi les 4 niveaux de gris), donc a été fait dans le même esprit (faire le portage le plus rapidement possible, donc ne pas toucher aux routines plus que le strict minimum).

Et si les codes de démarrage de TIGCC sont comme ça...

Pour ceux-là, en revanche, on a fait de notre mieux pour les optimiser en taille.

D'accord.

Le processeur le fait tout seul.