Ma technique du jour - Page 1

Edited_3660

Le GCC de TIGCC est capable (enfin, à une époque, il l'a été, je n'ai pas vérifié récemment) de réutiliser (sp) au lieu d'utiliser -(sp), à partir du deuxième appel à une fonction stkparm (si assez de données ont été empilées lors du premier appel, naturellement)

addq.l #8,%sp |et voilà ! deux octets et encore des cycles grapillés !

Deux octets gaspillés par rapport à lea 8(sp), sp - mais aucun cycle.

non, c'est plus lent de lire un char ou un long sur un 68000 que de lire un short car le bus de donnée est... sur 16bits

Pour l'octet c'est non dans un cas, si l'octet est a une valeur impaire, tu as un décalage a faire (enfin pas toi, le cpu)

oui je suis sur, meme que sur certain révision du 68000 lire un octet sur une @ impaire est impossible directement

faudrait que j'aille chercher ma doc sur le 68000

mais si tu regarde le bus A du 68000 il n'y a pas de A0 (bon il est possible de "l'émuler" via d'autre signaux, mais bon)

Un accès .b prend le même temps que l'adresse soit paire ou impaire.

C'est que le 68k qu'on a en est capable

pourquoi ce serait différent sur d'autres versions du 68k?
a mon avis le shifter doit être en hard sur le bus quand on doit lire un byte sur d8-d15 avec /UDS, nan?

Si tu veux vraiment optimiser http://www.atari-forum.com/wiki/index.php/Earxtutchap7

squalyl (./13) :
pourquoi ce serait différent sur d'autres versions du 68k?
a mon avis le shifter doit être en hard sur le bus quand on doit lire un byte sur d8-d15 avec /UDS, nan?

parce qu'entre les premiers sortit et les derniers sortit le coeur a evolué meme en restant compatible. Je prendrais comme exemple le 6502 qui entre les premieres et dernieres version (le 65C02, la version CMOS) il y a de legere différence au niveau du nombre de cycles, mais surtout des instructions en plus, pourtant ce sont des 6502

tout ça pour dire que quelque a moins que le 68000 a chercher directement a une adresse impaire la valeur, il faut, pour un octet, forcement un shift, alors que quand l'octet est a une adresse pair, le shift n'est pas utile, donc ça rajoute forcement du temps de calcul, meme si c'est juste un simple cycle en plus

D'après les timings des tables du 68000 User's Manual de Motorola, ça n'a pas l'air de faire de différence entre byte et word ?

La seule particularité du 68000 (qui ne se traduit peut-être pas sur les processeurs suivants de la famille, je ne sais pas) avec la gestion des bytes/words que je connaisse, est le shift rapide à gauche de 8 rangs:

move.b <ea>, -(sp)
move.w (sp)+, dn move.b <ea>, (sp)+

à la place de

move.b <ea>, dn
lsl.w #8, dn move.b <ea>, dn

(même taille, plus lent).
La routine de décompression ttunpack fait grand usage de cette optimisation.

./1: Connu. J'ai du l'utiliser quelque part çà (dans PedroM ou genlib)

GCC le fait
GTC je ne sais pas.

Godzil (./10) :
oui je suis sur, meme que sur certain révision du 68000 lire un octet sur une @ impaire est impossible directement

Je veux bien te croire, mais ça paraît quand même énorme. Ça casserait la compatibilité avec énormément de code, et c'est franchement pénible de ne pas avoir d'accès byte, en particulier pour les écritures (qui ne sont plus atomiques, du coup).

Godzil (./16) :
tout ça pour dire que quelque a moins que le 68000 a chercher directement a une adresse impaire la valeur, il faut, pour un octet, forcement un shift, alors que quand l'octet est a une adresse pair, le shift n'est pas utile, donc ça rajoute forcement du temps de calcul, meme si c'est juste un simple cycle en plus

Euh, je suis de l'avis de squalyl, y'a de fortes chances que ce soit implémenté sous la forme d'un multiplexeur et pas d'un shift, et dans ce cas le temps de traitement c'est pas de l'ordre du cycle, mais du temps de propagation dans les éléments logiques

9 ns pour la logique TTL si mes souvenirs sont bons. Pour le MOS, c'est combien ?

Ça dépend du process de fabrication

[cite] Zerosquare (./22) :

Godzil (./10) :
oui je suis sur, meme que sur certain révision du 68000 lire un octet sur une @ impaire est impossible directement

Je veux bien te croire, mais ça paraît quand même énorme. Ça casserait la compatibilité avec énormément de code, et c'est franchement pénible de ne pas avoir d'accès byte, en particulier pour les écritures (qui ne sont plus atomiques, du coup).

quand tu n'a pas de ligne 0 sur le bus d'addresse il faut bien faire avec !

Faudrait que je retrouve mes infos la dessus, mais je me souviens d'une carte 68000 ou accéder en 8bit était plus que déconseillé...

Il me semble que, dans la doc présentée par martial sur le forum assembleur, on parle de deus lignes appelées UDS et LDS, qui permettent de lire soit la mémoire impaire, soit la mémoire paire, ou les deux... Si j'ai bien compris, le processeur 68000 peut donc lire sur un octet impair, un octet pair, ou les deux à la fois...

oui mais utiliser UDS/LDS pour cabler la mémoire n'est pas indispensable (et oui)

Et quand tu changes ton code, tu ne comprendras pas pourquoi tu as un Address Error ou une Illegal Instruction...