Attention cache et unité de prédiction de branchement sur les 68060 - Page 1

Je cherches depuis hier soir un bug, bug qui n'existait pas en fin de compte, le cache du 68060 m'a pourri un paquet d'heures et a failli me rendre comme lui et . J'avais des plantages aléatoires avec erreur différentes mais tout le temps sur la meme instruction. Bien sur aucun debugger 68060 n'existe ou alors je suis pas au courant et en mode 68030 tout tournait a merveille. Puis une petite idée, j'ai changé la config de mon cache et au moment ou l'erreur doit se produire voila avec quoi je me suis retrouvé :



Donc amis codeurs sur Falcon CT60, quand vous etes sur que cela vient pas de votre code, changez la config du cache, mais apparement c'est la partie prédiction de branchement qui s'est emballé les pinceaux, j'avais un jsr qui pointait sur un jmp qui executait une instruction puis RTS, cherchez pas pourquoi ce code spaghetti j'ai mes raisons.

Donc tout ceci pour vous prévenir, c'est assez la fete de programmer en assembleur mais quand le matériel y mets du sien ca suffit. Et meme avec un debugger je suis pas sur qu'on aurait pu voir le probleme, car plusieurs instructions aurait été éxécutés et surement cela aurait tout changé.


GT Pas buggé

P.S. : Et je suis quitte pour me taper les 15 pages de doc sur les caches du 68060, enfin merci a Freescale (Motorola) de mettre gratuitement leur doc en ligne

Tu ne ferai pas du code auto-modifié ??
Le code auto-modifié c'est mal

frost :
Tu ne ferai pas du code auto-modifié ??
Le code auto-modifié c'est mal

Meme pas de code auto modifié et pourtant ca m'a tenté (Je me demandes meme si cela aurait pas mieux marché ). Il explique meme dans la doc Moto comment supporter du code auto modifiant, voici un morceau de la doc :


To fully support self-modifying code in any situation, it is imperative that a CPUSHA instruction specifying both caches be executed before the execution of the first self-modified instruction.

Ca peut pas etre mal si le constructeur du CPU explique comment 'setter' les caches pour en faire

GT

Ah oui, c'est vicieux ça !!

Didier Méquignon m'a expliqué le pourquoi du comment et cela ne vient pas de la partie prédiction de branchement mais de collision cache de données et cache d'instructions. Et apparement si vous faites le tour sur le net, je suis pas le seul a avoir manger des dragibus jusqu'a comprendre le pourquoi et le comment.

Pour cela il faut 'flusher' le cache, le moyen le moins contraignant (Pas de passage en superviseur a faire pas de modif de config de cache) est d'utiliser un move16, me demander par pour déplacer quoi, car si vous saviez ce qu'elle déplace chez moi vous seriez pas bien...


GT

Un grand merci a Didier

T'es sûr qu'il n'y a pas la moindre modification de code ?? J'en perd un peu mon latin là.. un ptit bout de code pour comprendre ?

frost :
T'es sûr qu'il n'y a pas la moindre modification de code ?? J'en perd un peu mon latin là.. un ptit bout de code pour comprendre ?

Je n'ai utilisé aucun code automodifiant, c'est un programme GEM, bouge pas j'expliques, c'est pour mon gestionnaire de map, pour les modules externes, ceci sont chargés en ram et je sautes a ces routines avec un jsr (a0), mais voila le pourquoi cela plantait, extrait du mail de Didier :

Le problème est simple si l'on charge du code en mémoire, celui est dans le cache data, donc si l'on lance le programme à la même adresse le cache programme d'ayant pas changé ca ce passe mal au bout de qques lignes de programmes (en fait au moment ou le cache programme va se remplir à nouveau cette fois avec le code chargé.

Les programmes chargeant et lancant des progs externes avec Pexec n'ont pas ce probleme car un flush du cache est fait. Mais j'ai mon format a moi a cause du passage de paramètres et de la vitesse des appels.

Ok, je comprends mieux. Ce n'est pas du code auto-modifié, mais presque. Merci pour l'explication

Et apparement ce genre de problème commence a apparaitre a partir du 68040 car séparation cache de données et d'instructions

Il me semble qu'il y a aussi une séparation des caches données et instructions sur le 030... mais avec 256 octets de cache, tu ne vas pas loin
Le 040, lui, offre 4Ko pour chacun des caches, le 060 offre 8Ko par cache, le risque de dommage collatéral augmente donc sensiblement.

frost :
Il me semble qu'il y a aussi une séparation des caches données et instructions sur le 030... mais avec 256 octets de cache, tu ne vas pas loin

On m'a proposé de remplir les caches du 68060 avec des nops.....

frost :
le risque de dommage collatéral augmente donc sensiblement.

Joli expression

GT: oui lo, à chaque fois que tu charges un module, tu exécutes 8Ko de nops

frost :
GT: oui lo, à chaque fois que tu charges un module, tu exécutes 8Ko de nops

Et attend j'ai encore une phase de boot pour certain module.

On m'a meme proposé de cacher une image de c.. dans le prog

Avec un prog qui fait 38 Kilos, 8 kilos ca ferait grossir 1/5 du prog, et le pire c'est que pour eviter de faire grossir le programme, il y aura génération des nops avec les emm.... qui iront avec


GT

Je ne comprends pas pourquoi tu (gt turbo) est surpris de ce problème. Il existe depuis que les CPU ont des caches.

La fonction Pexec() du TOS fait de même pour invalider les données du cache chargées du fichier exécutable avant d'exécuter le programme. Evidemment, Atari n'a pas prévu de fonction dans le TOS pour invalider le cache, donc tous les programmes utilisant des plugins souffrent du même problème (gemview, tous les softs m&e, etc...), sauf s'ils utilisent Pexec() bien sûr. En plus, la gestion du cache est différente entre les 020/030/040/060, donc il faut une routine spécifique à chaque CPU.

Au fait, le cache concerné est le cache instruction (celui dans lequel le CPU pioche les instructions à exécuter), pas besoin d'invalider le cache de données. A ce propos, il est rare que l'on lise la RAM vidéo, généralement, on se contente d'écrire dedans. Il serait donc très utile de faire en sorte de ne pas placer dans le cache de données les infos lues/écrites de la RAM vidéo. Cela se fait par la PMMU, pour ceux qui sont intéressés (on définit les pages de mémoire comme non cacheable).

pmandin :
Je ne comprends pas pourquoi tu (gt turbo) est surpris de ce problème. Il existe depuis que les CPU ont des caches.

C'est la première fois que je me fais prendre la tete par un cache en plus dans la doc du 060 tu vois très régulierement, des phrases dans le genre ' nous avons tout fait pour garder une certaine cohérences dans les données du cache' alors ca fait mal au derrière en plus comme tu l'a écrit, la gestion est différente, donc n'ayant pas d'assembleur 68060 tu assembles certains instructions a la main et tu fais tes essais.
Après plusieures heures et paquet de dragibus, un oeil sur le net et te voila dans une rubrique Amiga / Mac et tu t'apercois que tu arrives a trouver une solution chez eux.

pmandin :
A ce propos, il est rare que l'on lise la RAM vidéo, généralement, on se contente d'écrire dedans. Il serait donc très utile de faire en sorte de ne pas placer dans le cache de données les infos lues/écrites de la RAM vidéo. Cela se fait par la PMMU, pour ceux qui sont intéressés (on définit les pages de mémoire comme non cacheable).

Si c'est par rapport a mes modules, ceci ne font aucun accès direct dans la ram vidéo, c'est un prog GEM express pour garder la compatibilité (C'est sur qu'avec l'histoire du cache...), j'ai failli passer par la case MMU pour justement passer certaines pages en non cachables, mais bon rien que passer en superviseur dans un prog GEM, c'est pas très apprécié surtout par l'AES, enfin bon mon problème est résolu et surtout c'est mon baptème de l'air en ce qui concerne la gestion des caches et je parles meme pas de la PMMU.

GT Heureux

Apparement si on a une fonction pour le cache implémenté dans le TOS :

http://atari.mbernstein.de/prog/tos/041102.htm

Je comprends pas trop la langue de nos camarades teuton mais je crois que cela est dispo seulement a partir des Milans et de la CT60 avec un XBIOS version 0.98



GT

pmandin :
tous les programmes utilisant des plugins souffrent du même problème (gemview, tous les softs m&e, etc...), sauf s'ils utilisent Pexec() bien sûr.

oups! ça me rappelle mon chargement de module dans Animator ... il doit pas être super 060 friendly celui-là...

GT Turbo :
Apparement si on a une fonction pour le cache implémenté dans le TOS :
http://atari.mbernstein.de/prog/tos/041102.htm

Je connaissais pas ce site, la quantité d'infos est hallucinante !! ça va être utile pour WikiPendium miam!