BOOSTER020 UN 68020 POUR ST Par Jean Conter

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.

Jean Conter nous propose donc son étude du problème, avec les difficultés rencontrées, et les solutions trouvées...


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).
Malgré sa simplicité, cette carte utilise un composant dont le prix élevé (environ 1 500 francs) fait qu'elle s'adresse essen­tiellement à des « bidouilleurs confirmés » n'ayant pas peur de faire trépasser d'un seul coup les 200 000 transistors contenus dans le 68020 !...


POURQUOI PASSER AU 68020?

Rassurez-vous, ce n'est pas unique­ment pour suivre la mode. Le 68020 corri­ge un certain nombre de défauts de «jeu­nesse » du 68000 et apporte une simplification de la programmation. En outre, il est plus rapide. Etudions ces différents points.

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
COPIE: MOVE.L (A0)+,(A1)+ ;taille instruction=1 mot
DBRA DO,COPIE ;taille ins­truction=2 mots

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)


sur 68000

LEA TABLEAU,A0

LSL.W #1,D1 ; multiplie index par 2

MOVE.W 0(A0,D1.W),D0

sur 68020:

MOVE.W (TABLEAU,D1.W*2),D0


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


CMPI.L "MOVE",(A0) ; 4 caractè­res d'un coup

BEQ CODEMOVE ; cas d'un MOVE

CMP  ...

Sur 68000, vous devez comparer ca­ractère par caractère, sauf si vous êtes sûr de la parité de AO (sinon vous déclenchez l'exception d'erreur d'adresse).

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.


POURQUOI PAS UN 68030 OU UN 68040 ?

Rappelons d'abord que le 68030 est un 68020 avec une PMMU et que le 68040 est un 68030 intégrant une FPU (NDLR : c'est évidemment un peu simplifié, il y a d'autres améliorations). La PMMU dont nous parlons n'a que très peu de rapport avec la « MMU » équipant le ST. ll s'agit d'un composant très complexe (presque aussi complexe que le 68020) permettant de garantir la protection des espaces mémoire dans un système multitâche. Le TOS n'étant pas multitâche, il est inutile de payer plus cher pour des fonctionnalités que nous n'aurons pas l'occasion d'exploiter (du moins tant que vous n’implantez pas UNIX sur votre ATARl). De plus, le 68030 met en œuvre un accès en «rafales» (burst mode) qui ne peut s’exploiter correctement qu'avec une mémoire étudiée pour. Toute bonne carte d'extension à base de 68030 devra donc intégrer une mémoire cache externe suffisamment grande et rapide, le prix élevé en résultant dissuadera un bon nombre d'amateurs ! Le 68040 présente l'avantage d'intégrer un coprocesseur flottant (ou plutôt une émulation logicielle d'un coprocesseur flottant !), ce qui est nettement plus intéressant. Le prix, là encore, est dissuasif. Afin de ne rien regretter, sachez simplement que le FPU intégré au 68040 n'est pas aussi complet que le 68881/2, et d'autre part que le 68020 possède des instructions que les 68030 et 68040 ne possèdent pas! Eh oui, voilà une exception flagrante à la compatibilité ascendante. Les «magnifiques» instructions CALLM et RTM (appel et retour de Modules), sortes de super LINK/JSR avec protection d'accès, ont été tout bonnement sacrifiées faute d'avoir été utilisées par les compilateurs, de ce fait leur suppression est passée inaperçue. A quoi cela sert-t-il que les concepteurs de micros se décarcassent si les programmeurs ne connaissent même pas la liste des instructions! D'où l'engouement pour les micros RISC, genre «gros muscles, petit cerveau», devant tout à leur Manager !(RISC= Repose Intégralement Sur le Compilateur).

POURQUOI NE PAS Y AVOIR PENSE AVANT ?

Il n'y a pas qu'un obstacle « hard » au changement de processeur. Par exemple, le 68010 est compatible broche à broche avec le 68000, et pourtant il ne tourne pas tel quel sur un ST. Cela vient de deux modifications intervenues sur les nouveaux processeurs de la série 680x0 :

1) L'instruction MOVE SR,<ea> est devenue «privilégiée» (elle ne peut plus s'exécuter en mode utilisateur, comme sur le 68000).
2) Lors d'une exception, un mot de format est empilé avant le PC et le SR. D'autre part, les erreurs de bus et d'adresse provoquent une sauvegarde plus complète et plus homogène que sur le 68000. Il faut donc une modification logicielle pour tenir compte de ces changements.

 D'où la nécessité d'un TOS adapté à ces nouveaux processeurs. Un autre problème se pose. Jusqu'au TOS 1.4 (y compris), Atari utilise la ligne F (instructions dont le code commence par F en hexadécimal, inutilisées sur le 68000) pour optimiser les appels/retours des routines Gemdos. Or, sur 68020 et plus, cette ligne F est réservée strictement à la gestion des coprocesseurs. Une solution consiste à recoder les lignes F en ligne A (en préservant les codes A000 à AO0F utilisés pour les primitives graphiques de très bas niveau du TOS). C'est ce que j'ai fait avec un vieux TOS 1.0, mais cela représente plusieurs milliers de patches! L'idéal, c'est de récrire le TOS en libérant l'émulation F et en identifiant le processeur central pour adapter la gestion de la pile en conséquence. C'est ce qui a été fait dans le TOS 1.6 équipant le STE. Dans ce TOS 1.6, une variable système ($59E) contient $0000 pour un processeur de type 68000 et $OOFF sinon (en fait, cette variable a pour but d'indiquer le format des « stack frames », c'est—à-dire des informations stockées sur la pile lors d'une exception). Si vous voulez précisément connaître le processeur, le Cookie _CPU (voyez le Coin du Programmeur de STMag n°52) contient sur un long-mot le suffixe du processeur central (O, $A, $14 ou $1E respectivement pour 68000, 68010, 68020 et 68030). Voilà donc la grande nouveauté du TOS 1.6. Il supporte n'importe quel processeur 680x0 (sans toutefois gérer le(s) cache(s) et la PMMU). Il est étonnant de constater que cette différence fondamentale n'ait même pas été évoquée dans un livre récent consacré aux TOS 1.4 et 1.6. Enfin, il faut signaler un dernier obstacle «tout bête». Le TOS 1.6 est logé dans des ROMs, dont le temps d'accès est trop grand pour être utilisable avec un 68020... Comme il a été indiqué plus haut, la réduction du cycle-machine à 3 cycles-horloge implique un temps d'accès plus court à la mémoire (200 ns maximum). Il faudra donc nécessairement recopier le TOS 1.6 dans des REPROMs rapides pour pouvoir tourner avec 68020. Voilà donc suffisamment de raisons pour lesquelles le passage de l'idée à la réalisation concrète n'était pas immédiat.

LA CARTE BOOSTER020

Un premier constat, le 68020 ayant beaucoup plus de broches que le 68000 (voir le brochage figurant dans les environs), vous ne le trouverez donc pas en boîtier DIL64 (STF) ou en PLCC68 (STE), et par conséquent n'espérez pas le substituer directement au 68000. Second constat, certains signaux du 68000 ont disparu (E, VMA, VPA, UDS, LDS). D'autres se sont «enrichis» : DTACK est remplacé par DSACKO et DSACK1. ll faut donc refabriquer les signaux manquants. Nous utiliserons une PAL «musclée» pour cela. Par exemple, UDS et LDS servent à sélectionner respectivement |’octet de poids fort et |’octet de poids faible d'un bus de 16 bits. Le 68020 ayant un bus de 8, 16 ou 32 bits, on utilise 4 signaux (A0, A1, SIZO et SIZ1) pour activer les octets correspondants. Je ne décrirai pas ici la programmation interne de la PAL. Il va de soi que la simplicité du montage repose sur cet unique composant et sur des astuces internes. Pour en savoir plus, je vous conseille de faire l'ENSEEIHT, département Informatique (NDLR : c'était une pub gratuite) ! Vous remarquerez, sur le schéma de câblage ci-contre, que les  données du bus ATARI sont reliées aux broches D16 à D31 du 68020 et non aux broches D0 à D15. C'est normal, même si c'est bizarre (s'adresser à Motorola en cas de contestation!) Vous remarquerez également un connecteur sur lequel s'enfiche éventuellement un cavalier. Si le cavalier est placé, vous invalidez physiquement le cache d'instructions, cela peut être utile pour certains programmes modifiant dynamiquement des instructions (espèce de programmes en voie de disparition, et c'est tant mieux !). Si le cavalier est enlevé (c'est le mode normal), vous permettez au cache de fonctionner (à condition qu'il soit activé par logiciel). Le programme suivant (exécuté en mode superviseur) active le cache:

$7009        MOVEQ #%1001,D0 ; bit#3=clear cache    bit#0=enable cache
$4E7B0002    MOVEC D0,CACR



N.B. : le bit#3 (clear cache) peut être laissé à « 0 » dans la mesure où le contenu du cache est correct. Pour  invalider le cache, il suffit d'écrire un « 0 » en position 0 du registre CACR. ll est donc trivial d'écrire un accessoire de bureau mettant en hors service le cache afin de mesurer les différences de performances.

 

INSTALLATION D'UNE CARTE BOOSTER 20

Nous nous contenterons de donner quelques indications générales car la carte Booster 20 idéale n'est pas encore disponible. Celle étant représentée sur la photo correspond à un prototype vieux d'il y a trois ans, et destiné à un STF première génération (68000 le long du drive). Cette carte comprenait une logique supplémentaire, aujourd'hui inutilisée, permettant de la faire fonctionner à 16 MHz. Cette carte est enfichée sur un support DIL64 monté à la place du 68000 d'origine. Elle fonctionne avec un vieux TOS 1.0 patché. J'ai pu vérifier que cette carte fonctionnait bien sur un STE, en recopiant le TOS 1.6 dans des REPROMs rapides et en utilisant un adaptateur PLCC68 vers DIL64 (chose toute bête coûtant une vraie fortune). Le Booster 20 étant placé dans le Domaine Public, vous pouvez réaliser un circuit imprimé sur mesure pour votre ST, à partir du schéma de principe ci-joint. Afin de ne pas dupliquer les efforts, il serait intéressant de fabriquer une carte «idéale», mais celle-ci devrait être produite en un nombre suffisant d'exemplaires afin d'en réduire le prix de revient. Il faudrait dans ce cas préciser le modèle de ST sur lequel vous désirez faire l'adaptation (68000 en DIL64 ou en PLCC68, et surtout sa localisation sur la carte mère), et également indiquer si vous pensez ultérieurement utiliser un coprocesseur flottant 68881/2, auquel cas il faudrait prévoir le support correspondant (type PLCC68 pour réduire le coût). Je vous conseille donc de transmettre vos souhaits à la bonne fée qui centralisera les demandes et verra ce qu'elle peut faire (n'oubliez pas le timbre pour la réponse, car les fées d'aujourd'hui ne bénéficient plus de la franchise postale...). Adresse de la fée : AUTOMATIC 2000 2, barrière de Bayonne, 31300 Toulouse Par la magie du sort, c'est également auprès de cette bonne fée que vous pourrez trouver, pour une bouchée de pain et un baril de pétrole, la petite PAL nécessaire au Booster 20. Avant de vous procurer un 68020 (fréquence indifférente) chez votre revendeur préféré, vérifiez que vous êtes bien en mesure de réaliser par vos propres moyens (ou ceux d'un bon copain...) le circuit imprimé nécessaire, car le circuit «idéal» que vous avez demandé à la bonne fée ne sera peut-être jamais réalisé, faute de demandes en nombre suffisant. Pensez également à vous procurer une cartouche de diagnostic, la solution la plus efficace consiste à programmer une cartouche PRAM (voir ST Mag n°42) au moyen d'un second ST. Cette cartouche vous sera peut-être utile pour identifier certains problèmes de timing sur des versions exotiques de ST. je le répète, il s'agit d'une manip pour « habitué(e)s », et qui ne sera en aucun cas prise en charge par la sécurité sociale, et encore moins par la garantie Atari. Vous resterez responsable de votre « bidouille».

ET MAINTENANT QUELLES PERFORMANCES POUR VOTRE NOUVEL ATARI ?

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.

ET LA COMPATIBILITE AVEC LES LOGICIELS EXISTANTS ?

La plupart des programmes écrits pour 68000 fonctionnent avec la carte Booster 20. On peut cependant trouver quelques petits problèmes se recoupant d'ailleurs avec ceux rencontrés sur le TT :

— Les programmes utilisant des boucles de temporisation pour gérer des sons, par exemple, vont tourner plus vite et engendrer des sons plus aigus. La bonne solution consiste à utiliser des Timers programmables fournissant une référence de temps absolue, indépendante de la charge et de la vitesse du processeur central.

— Les programmes (heureusement assez rares) modifiant dynamiquement leur code ne fonctionneront plus lorsque le cache est activé. ll faut dans ce cas invalider le cache.
- Les programmes utilisant des MOVE SR,<ea> auront quelques difficultés avec le TOS 1.6 du STE, car l'émulation du MOVE SR y est trop sommaire. Une solution envisageable consiste à récrire la routine d'exception de viol de privilège, et à l'implanter par exemple dans la cartouche PRAM référencée précédemment.
— Le TOS 1.6 du STE ne gérant pas le cache d'instruction (la routine correspondante existe mais n'est jamais appelée !), le lancement de certaines applications sera difficile (Quick Index par exemple).Une solution consiste en la validation logicielle permanente du cache et en son invalidation matérielle (par STRAP ou par un signal ad hoc) dans les sections critiques.
— Enfin, les programmes de mise au point interprétant les informations situées dans la pile après une erreur BUS fourniront de mauvaises indications, puisque la sauvegarde de l'état interne est différente sur 68020. Ainsi K-Seka fonctionnera bien tant que l'on ne provoquera pas d'erreur de bus ou d'adresse. A-Debog devra également faire une petite cure de récriture pour tourner sur Booster 20 ainsi que sur le TT (dernière minute, il paraît que cela a été fait).

CONCLUSION

Le Booster 20 n'a pas pour ambition principale d'accélérer la vitesse d'exécution de vos applications (même s'il le fait quand même). Il va vous permettre, en attendant que le TT vaille moins de 5000 F, de goûter les joies de la programmation en 68020 sur votre machine préférée. Couplé à un FPU 68881/2 (un article ultérieur vous précisera comment), vous constaterez comme il devient facile de faire des calculs en virgule flottante tout en programmant en assembleur. Vous pourrez travailler en précision étendue (80 bits), et imbriquer vos calculs entiers et flottants (ce que ne savent pas faire les compilateurs actuels) pour maximiser le parallélisme d'exécution sur CPU et FPU. Les performances obtenues vous surprendront.

VOUS AVEZ AIMÉ LE 68000, VOUS ADOREREZ LE 68020 !

A ce propos, je serais heureux de recevoir des nouvelles des développements que vous n'allez pas manquer de faire sur votre ATARI équipé du Booster 20. D'avance, merci.

JEAN CONTER