Ce mois-ci, une bidouille un peu particulière, dans le sens où elle n'est pas « finie», ne vous proposant que la partie théorique et vous laissant libre de son exploitation. En effet, l'adaptation à tous les modèles de ST, STE, et Mega (et surtout aux versions du TOS) dépasse largement le cadre de ce magazine, et le coût d'un tel développement en ferait presque nécessairement un produit commercial.

Ces derniers temps, l'on voit apparaître des cartes à base de 68030 pour ST. Dave Small en présente une (ST030), plusieurs sociétés allemandes (Pro-VME, Makro CDE...) en annoncent. Ces cartes sont la suite logique des cartes à base de 68020 (PAK-68 par exemple) disponibles depuis longtemps outre-Rhin, mais peu répan­dues dans nos contrées. Partant de l'hypo­thèse que le prix de ces cartes en a limité la diffusion, je vous propose la réalisation de la carte 68020 la plus simple possible elle ne comporte en effet que deux cir­cuits intégrés et une résistance ! Je la dé­die au DPAC (Domaine Public des Ama­teurs de Concision).

POURQUOI PASSER AU 68020?

GAIN DE PUISSANCE

Plusieurs moyens permettent d'aug­menter la puissance d'un système à mi­croprocesseur

1. Augmenter la fréquence d'horloge, 16 à 50 MHz pour le 68020 contre 8 à 16 MHz pour le 68000. C'est souvent un argument utilisé abusivement par les « commer­ciaux », il ne suffit pas que le processeur soit rapide, il faut aussi que ses « col­lègues » (la mémoire notamment) le soient. Dans le cas du Booster 20, pour des problèmes de compatibilité et de sim­plicité, nous conserverons une horloge de 8 MHz pour cadencer le 68020.
2. Optimiser les instructions, voilà une bonne solution que le 68020 applique par exemple aux décalages : 1 seul cycle hor­loge est suffisant pour décaler un opéran­de de n positions (contre n cycles pour le 68000). Par ailleurs, le cycle machine de base s'effectue en 3 cycles horloge sur 68020 (contre 4 pour le 68000) d'où un gain net de 25 % à fréquence d'horloge égale. Mais attention, cela implique un temps d'accès plus court pour la mémoire !
3. Anticiper la recherche d'instructions (Pre-Fetching). En général, les instructions à exécuter sont rangées à des adresses consécutives, il est donc intéressant d'al­ler chercher ces instructions à l'avance, tout en exécutant l'instruction courante. Cette solution a été mise en œuvre sur le 68010 intégrant une minifile d'instruc­tions de trois mots, cette organisation ac­célère considérablement les boucles, puis­qu'alors l'activité du bus est restreinte aux seuls transferts de données. Par exemple

Le 68010 doit donc favoriser ce type de boucles. Le 68020, lui, réalise un PREFET­CH par paquets de 32 bits (donc deux ins­tructions dans le meilleur des cas), mais surtout il gère une mémoire cache de 64 longs-mots. Cette antémémoire est in­validable par matériel (strap) et logiciel (registre CACR). Elle contient les dernières instructions utilisées (qui ne sont pas né­cessairement en séquence). Cette mémoi­re est située sur la puce 68020 et acces­sible sans « wait-state » sur 32 bits en parallèle. Toute instruction déjà présente dans l'antémémoire (identifiée par son adresse) ne nécessite donc pas d'accès sur le bus externe, ce qui facilite les accès DMA. Lorsque le cache est plein, et qu'une nouvelle instruction doit y être placée, la plus « ancienne » est remplacée par celle-ci. Remarquons que, puisqu'une instruction est repérée par son adresse (et non par son code), il est strictement prohi­bé de modifier une instruction sans invali­der partiellement ou totalement le cache. D'où une partie des problèmes avec la ligne F (qui modifiait dynamiquement un MOVEM) et avec des moniteurs de mise au point. Même lorsque le cache est inva­lidé, la modification dynamique de code ne doit pas affecter le long-mot suivant. Puisque le cache a une taille de 64 longs-mots, on peut y loger au « grand maximum» 128 instructions. Il est assez diffici­le de savoir, à un instant donné, quelles instructions sont présentes dans le cache. L'estimation de la durée d'exécution d'une portion de code est assez difficile à faire (on peut cependant facilement en déterminer un minorant et un majorant, grâce à des tables fournies par Motorola).

     4. Elargir le bus des données. Le bus des données du 68000 a 16 bits de large ; le transfert d'un long-mot nécessite donc deux accès à la mémoire. Sur 68020, le transfert des données peut se faire sur 32 bits en parallèle, d'où une vitesse dou­blée pour ce type d'opérande. Bien enten­du, il faut que le bus mémoire soit sur 32 bits, ce qui n'est pas le cas du ST. Heu­reusement, le 68020 peut également travailler avec des bus plus « étroits » (16 et 8 bits), il suffit de le lui indiquer lors de chaque transfert avec les signaux DSACKO et DSACK1 (qui remplacent le signal DTACK du 68000).

GAIN D'EFFICACITE

Le but est alors de simplifier la pro­grammation. Tout programme écrit pour 68000 doit pouvoir s'exécuter (compatibi­lité ascendante oblige) sur 68020. Mais certaines séquences d'instructions peu­vent être simplifiées. Par exemple : aller chercher le Nième mot d'un tableau (on suppose que le registre D1 contient i=N-1)

On remarque trois choses

• le registre d'index D1 n'a pas été mo­difié,

• on n'a pas besoin de passer par un re­gistre d'adresse, la base du tableau est co­dable directement sur 32 bits,

• on gagne au moins 2 instructions, 4 octets et du temps d'exécution.

Autre exemple, vous écrivez un tra­ducteur et parcourez le texte source jus­qu'à trouver un caractère différent de l'es­pace ($20), l'adresse courante étant dans le registre AO, vous désirez identifier le code mnémonique suivant, avec le 68020, il suffit d'écrire

Dernier exemple, vous écrivez un mo­niteur de mise au point et vous devez re­définir une bonne partie de la table des exceptions. Au lieu de mémoriser tous les anciens vecteurs avant de les remplacer, vous pouvez fabriquer une autre table d'exceptions, située n'importe où en mé­moire, et par une simple affectation du re­gistre VBR (Vector Base Register), activer cette nouvelle table d'exceptions. Ce re­gistre a été introduit à partir du 68010, il est accessible grâce à la nouvelle instruc­tion MOVEC. Bien entendu, ce registre VBR est forcé automatiquement à 0 lors d'un RESET, de façon à maintenir la com­patibilité avec le 68000. Le registre VBR peut également simplifier considérable­ment la programmation des logiciels de type « REVOLVER » ou « TWIST » (swit­chers), et permettre l'implémentation de « machines virtuelles ». La délocalisation de la table des exceptions (dernier exemple), le non-alignement des données (autre exemple), de nouvelles instructions (RTD, BitField, CAS, PACK, MOVEC, EXTB.L, CMP2, MULx.L, etc.), des modes d'adressage nouveaux (facteur d'échelle, indirection, format long, etc.) et plus régu­liers (mode relatif PC pour CMPI et TST, déplacements sur 32 bits pour Bcc, BSR, CHK, LINK), une gestion plus régulière des exceptions (le sommet de la pile pointe toujours sur la sauvegarde de SR, puis PC, puis un mot de format identifiant l'excep­tion par son offset dans la table des excep­tions), et surtout une gestion hardware des échanges avec d'éventuels coproces­seurs (Floating Point Unit FPU = 68881 ou bien Paged Memory Management Unit PMMU= 68851), toutes ces nouvelles dispositions devraient réjouir le programmeur.

 

J'ai utilisé Quick Index pour obtenir une estimation des performances. Le tableau ci-contre résume les résultats. Un résultat doit vous sauter aux yeux. Lorsque le cache est invalidé, les performances sont moindres avec le Booster 20 qu'avec le 68000! Comment se « fait-ce » ? Eh bien il y a deux explications. La première, c'est que certains tests ne mesurent pas vraiment ce qu'ils annoncent, ainsi le test «CPU register» réalise une succession d'instructions sur les registres (MOVE,CLR,ADDQ et SUBQ), dont la durée totale dépend plus du temps d'accès aux instructions que de celui de leur exécution (rassurez-vous, les instructions sur registre sont exécutées plus rapidement sur 68020 que sur 68000). La seconde explication provient de ce que le ST a été conçu pour tirer le maximum du 68000, et non du 68020 qui n'existait pas à l'époque. En effet, j'ai signalé plus haut que le cycle machine du 68000 est constitué de 4 cycles horloge. Un de ces cycles n'étant pas utilisé par le bus, Shiraz Shivji (NDLR : le concepteur du ST) en a profité pour entrelacer des accès à la mémoire par le Shifter (pour rafraîchir l'écran). Le partage de la mémoire entre le Shifter et le 68000 est donc pratiquement réalisé sans conflit, et donc sans ralentissement du processeur central. Malheureusement pour lui, le 68020 est plus rapide (3 cycles horloge par cycle machine, tous utilisés), et donc les télescopages avec le shifter sont fréquents. Résultat, le 68020 est constamment freiné dans son élan par le Shifter, qui lui ne peut pas attendre (sinon votre écran vous ferait irrésistiblement penser à celui d'une chaîne cryptée bien connue). C'est là qu'un cache, même petit, arrange bien les choses. En libérant le bus lorsque les instructions à exécuter sont déjà présentes dans le cache, le shifter et le 68020 travaillent en vrai parallélisme. Résultat, on trouve un facteur 200% lorsque le cache est actif sur la plupart des applications (essayez le routage automatique de PLATINE ST par exemple). Remarque, le conflit d'accès avec le shifter ne se produit que pour des applications tournant dans la RAM. Tout programme en REPROM ou dans l'espace du port cartouche s'exécutera au moins 25 % plus vite, même si le cache est hors fonction.