Code optimisation (III)

Voici une autre vieille routine que j'ai retrouvée suite au précédent article concernant le code 'déroulé', appelé aussi par les anglophones 'unrolled'.

Cette technique était utilisée sur des CPUs sans code cache L1 ou L2 (68000 et 68010), qui rappelons-le est une mémoire rapide au sein même du processeur qui conserve le code afin de minimiser les échanges beaucoup plus lents entre le 68k et la fastram.

La routine ici a été codé par les ingénieurs de Commodore dans les années 1983/84/85 (Kickstart 1.2), donc pour le 68000. Ce sont les vecteurs d'interruptions, les autovec de l'exec.library. Ils n'ont par la suite pas été retravaillé dans le Kickstart 3.1 et même dans le 3.9 :

Or, à partir du 68020, Motorola ajoute à ces nouveaux CPUs ce fameux code cache, mais hélas sans son compagnon le branch cache. Ce dernier n'arrive en effet que sur le 68060. Le branch cache est une nouvelle astuce qui permet d'éviter des cycles de branchements, indispensable pour maximiser encore l'efficience les boucles (loops) présentes dans le code cache. Peu importe de toutes façons, il n'y a aujourd'hui plus aucun intérêt à optimiser pour tout ce qui est en dessous du 68060.

Pour donc utiliser au mieux toutes les spécificités du 68060, il n'y a pas d'autres solutions que de tout reprogrammer, avec bien en tête l'architecture du 060.

Les six routines autovec font au total 544 octets. Il faut bien se souvenir que :

1. Les accès fastram sont lents sur nos Amiga Classic, c'est à dire que le temps de transfère du code contenu de la mémoire pour traitement dans le CPU est élevé,
2. Lorsque le CPU demande du contenu fastram, il attends de la recevoir de la mémoire.

Bref, pour ce genre de routine, plus le code est court et plus rapide c'est pour un CPU comme le 68060.

Avec donc une autre technique de programmation utilisant le moins possible le code avec des boucles, le résultat final ne nous donne plus que 134 octets !

Pour chaque autovec, un longword informatif est envoyé dans d1, contenant :

1. Le nombre de décalage de bits (.b),
2. Le décalage initial (.b),
3. L'offset ($54 pour IntVec0) (.w).

Le registre d1 est ensuite utilisé par la boucle pour tester les bits relatifs aux six autovec :

Voilà donc 134 octets 68060 qui donnent un résultat identique aux 544 initiaux 68000 : c'est quatre fois moins. Notez qu'ici, ce nouveau code est totalement compatible avec le 68000, mais peut-être légèrement plus lent pour lui.

Une cerise est encore belle et bien présente ici : le gain de place dans le Kickstart, 410 octets de sauvés pour cet exemple. Commodore avait bourré au maximum toutes ses roms, et il n'y avait plus de disponibilité pour des commandes très utiles comme par exemple la 'dir'... En économisant donc le plus d'octets possibles, il sera tout à fait possible de rajouter ces routines quasi-indispensables pour les utilisateurs ! Qui n'a pas pesté ici au moins mille fois pour un 'dir' à charger d'abord par une disquette ou sur disque dur pour obtenir un directory ?

Pour finir, sachez que tous les CPUs ont des points forts et des points faibles. Ici pour ce qui concerne le 060, sa plus grande faiblesse est qu'il nécessite du code bien réfléchi et bien ordonné pour donner le meilleur de lui-même !

Monsieur le 68060 se régale avec du code bien optimisé pour sa personne !!