	OPTIMISATION EN ASSEMBLEUR (Part II): La TT Ram


	J'en tais rest la dernire fois sur une question trange: une
routine tournant soudain plus vite en ST Ram qu'en TT Ram... (ST Mag 118,
p 55). Voici la solution.

	La TT ram est une mmoire 32 bits, c'est  dire que l'information
la plus petite qu'elle soit capable de traiter tient sur 4 octets. C'est
ainsi que si vous demandez un octet en TT Ram, 4 octets voyagent et le
processeur n'en retient qu'un pour finir.

	La ST Ram est une mmoire 16 bits, elle traite au minimum deux
octets, jamais moins.

	Ceux qui travaillent avec leurs tables des temps d'excution des
instructions 68000 doivent avoir remarqu que les accs mots (16 bits)
sont aussi longs que les accs octets (8 bits) puisqu'en fait la Ram
envoit 2 octets de toutes faons!

	Revenons  notre TT ram, elle contient donc des cases de 4 octets:
la case 0, la case 4, la case 8, la case 12, etc...
	Si je demande un entier long  la case 8, tout est parfait, 4
octets voyagent directement vers le processeur, mais, si je demande un
entier long  l'adresse 6, tout se complique, car cet entier long recouvre
deux cases physiques (deux octets dans la case 4 et deux autres dans la
case 8).
	La mmoire envoit donc la case 4 ET la case 8 (en tout 64 bits) et
le processeur ne reoit que les morceaux utiles pour former l'entier long
demand. C'est exactement ce qui s'est pass dans ma routine, tous les
accs en mots longs taient  cheval sur deux cases physiques, de ce fait,
le bus traitait deux fois plus de donnes que ce qui tait utile!

La solution
-----------

	Comment viter cela? Tout simplement en s'arrangeant pour que les
adresses utilises soient des multiples de 4!

	move.l a6,d0
	addq.l #3,d0
	and.b #$fc,d0
	move.l d0,a6

	Ces quatre lignes arrondissent a6 au multiple de 4 immdiatement
suprieur (ou  A6 si il est dj multiple de 4). Ainsi, si A6 est bien
align, tous les autres accs par (a6)+ le seront puisque l'incrmentation
est de 4  chaque fois pour un entier long. De mme pour le registre A5
qui tait utilis.

	Le mieux est de prvoir dans vos allocations de mmoire, 4 octets
de plus que ncessaire et d'arrondir vos adresses comme expliqu plus
haut, ainsi, tout machine disposant de TT Ram donnera le meilleur de cette
mmoire rapide et permettra des gains de vitesse non ngligeables. Pour
des questions de chargement dans le cache, je conseillerai mme d'arrondir
l'adresse  un multiple de 16 octets: le cache travaille par paquets de 16
octets!


Les rsultats
-------------

	Avec cette petite modification (et l'optimisation de l'article
prcdent), ma routine tourne ENFIN plus vite en TT Ram qu'en ST Ram, les
rsultats sont d'ailleurs ceux-ci, toujours avec le cache actif:

	* en ST Ram: temps -25%, donc vitesse +33%
	* en TT Ram: temps -37%, donc vitesse +59% (waow!!)

	J'ai utilis toutes ces techniques dans VIDINOVA qui pilote la
cartouche VIDI_ST12 sur une carte NOVA en 32768 couleurs, rsultat: je
suis pass d'une digitalisation de 5/6 images  12.5 images par seconde en
320x240x16 gris. Je peux maintenant faire de la vido anime  l'aide de
mon seul Atari.

Le rsum
---------
	Pour amliorer un code:
	- tenter de rduire les boucles pour qu'elles tiennent dans le
	cache de 256 octets
	- sparer les oprations de lecture entre-elles
	- sparer la lecture dans un registre de l'utilisation du registre
	- sparer les oprations d'criture entre-elles
	- faire des accs mots longs en TT Ram  des adresses multiples de
	4 ou 16 (hem... ce que j'avais oubli de faire!).

	Vos questions ou vos ractions sont les bienvenues,

	Guillaume Tello
	gtello@wanadoo.fr

