Vampire: un pas vers la MMU

15 sujets de 1 à 15 (sur un total de 17)

seg
5 septembre 2016 à 10h02 #267578
L’équipe Apollo 68080 est en train de communiquer sur une nouvelle fonctionnalité du prochain coeur: le MPU.

Sur Amiga, on n’est pas trop familiarisé avec les systèmes intégrés de gestion mémoire. Ils ne sont pas indispensables pour un usage courant, et le système s’en bat les…

Pourtant, avant la chute de commodore, les concepteurs étaient en train d’apporter une petite couche de protection mémoire sur le système. On a donc vu les “enforcer” naître.

Moi, perso, je m’en sers tout le temps pour détecter à minima les accès illégaux en mémoire. Mais, sans MMU, l’usage de l’apollo core était restreint au système amiga.

Le FPU étant dans le pipe, la MMU aussi, on peut estimer que, bientôt, l’apollo core sera ouvert à tous les systèmes. Ca valait le coup de le partager ici.

Source: http://www.apollo-core.com/knowledge.php?b=1&note=2258&z=zOafBK
Anonyme
5 septembre 2016 à 10h24 #267580
genial

comme ça, stop aux speculateurs vendant des cartes ppc ou 68k à des prix délirants..
goodchip
5 septembre 2016 à 12h22 #267588
Excellente nouvelle, une pierre de plus à l’édifice !

Bien hâte de me prendre une Vampire 500 ou future 1200 🙂

Sylvain aka goodchip
leo
5 septembre 2016 à 15h02 #267592
C’est une bonne nouvelle!

Par contre, si j’ai bien compris, cette unité ne sera pas compatible avec les unités MMU existantes ?
Eggman
5 septembre 2016 à 17h29 #267615
@leo
Source ?

« Les cons ça ose tout, c’est même à ça qu’on les reconnaît » (Michel Audiard)
seg
5 septembre 2016 à 21h52 #267662
@leo

Gunnar souhaitant une compatibilité à 100% avec le 68040, il serait étonnant qu’il soit parti sur une autre implémentation.

Pour info, de mémoire, la MMU du 060 est identique à celle du 040. en revanche, il y a cassure avec le 030.

En dehors de ça, je me pose la question des problématiques que rencontre Gunnar pour implémenter une full MMU.

Je me suis toujours demandé si la translation d’adresse n’allait pas détériorer les perfs actuelles du cpu (en dehors des cycles consommés par l’algorithme de pagination).
leo
5 septembre 2016 à 23h51 #267683
@Eggman: c’est ce que j’ai compris, il n’y a pas de source.

On ne mentionne nulle part une compatibilité avec la MMU des 68x, et pour l’instant on parle seulement d’une “MPU”. De plus, des outils semblent en cours d’écriture: si c’était compatible il serait possible d’utiliser ceux qui existent, non ?

Après, si c’est compatible, tant mieux 🙂
seg
6 septembre 2016 à 9h27 #267701
@leo

Très bonne remarque.
flype
6 septembre 2016 à 10h50 #267718
Salut,

Voilà un sujet qui retient votre attention dites moi 🙂

Le titre du thread est plutôt bien choisi, et me fait penser que Rome ne s’est pas faite en un jour !

Le MPU (Memory Protection Unit) est en effet un composant se rapprochant d’une MMU (Memory Management Unit) sans en être un. Voyons voir ce qu’on peut en dire :

– Le MPU n’est pas compatible avec les MMU originaux, pour l’heure.

– Le MPU ne fait pas de mappage, translation d’adresses comme le fait un MMU. C’est la principale différence.

– Le MPU peut détecter des accès mémoires invalides en écriture, en lecture, ou en exécution (PC). L’écriture est protégée! Les plages d’adresses valides sont par exemple (la vraie table est plus complète) :
```
00E0 0000 - 00E7 FFFF : read/execute (ROM #2 512KB)
00F8 0000 - 00FF FFFF : read/execute (ROM #1 512KB)
0800 0000 - 0FEF FFFF : read/write/execute (FASTRAM 127MB)
0FF0 0000 - FFFF FFFF : forbidden  (Unused)
```
– Le MPU peut également détecter des accès invalides sur une adresse mémoire donnée pour l’utilisateur (Watchdog feature). Par exemple, on peut surveiller les accès à des null-pointers en lui demandant de surveiller l’adresse ‘0000 0000’.

– La détection / protection mémoire est activable/désactivable dynamiquement en modifiant un registre. Les 3 types de protection (Lecture, Ecriture, Execution) sont activables indépendamment.

– L’activation du MPU ne ralenti pas le core.

– Le MPU a été ajouté pour aider les testeurs de la carte à éprouver le core et les développeurs qui ont besoin d’un outil de type ‘enforcer’, au même titre que les BKPT/STOP/TRACE sont des instructions essentielles pour tracer un programme pas à pas…

Conclusion:

Ce n’est pas un vrai MMU, mais au moins en l’état les développeurs auront un outil suffisamment puissant pour répondre au besoin direct de tracer des accès mémoires illégaux.

A noter également que le core est compatible avec un autre outil déjà existant ‘COP’ http://aminet.net/package/dev/debug/cop qui permet de tracer l’exécution depuis un PC (via cable).

Notre enforcer-like en cours de dev :

Vous noterez la présence des registres B0 à B7 qui sont un deuxième jeu de registres mémoire.

A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.
Anonyme
6 septembre 2016 à 11h01 #267720
Nice, va falloir que je me decide a flasher ma Vampire!

Du coup pour le FPU c est remis a la prochaine release ou pour le moment c est mis de coté?
flype
6 septembre 2016 à 13h42 #267737
Le FPU n’est pas mis de coté. Le GOLD a mis le focus sur le CPU. D’autres cores suivront au même rythme qu’avant.

A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.
thellier
6 septembre 2016 à 16h34 #267753
Hello

Si je résume Seg :
Apparemment le MPU apporte juste une fonction de protection memoire comme Enforcer le fait sur les Amiga avec MMU
Par contre une vraie MMU ferait aussi la translation d’adresses memoire virtuelle -> réelle

A propos mais Enforcer quel bon programme ! Comment peut on programmer sérieusement sur os3 sans avoir Enforcer de présent pour vérifier que son prog déconne pas
J’ai mis Enforcer dans mon WinUAE de développment et je l’enléve plus

Alain
seg
1 novembre 2016 à 10h39 #272617
Ca se confirme: la future MMU ne sera pas compatible avec les 040/060: ici

Il va donc falloir que l’auteur de la mmu.library se remette au code.

S’il y a une distrib linux qui fonctionne sur 040/060, il va falloir l’adapter.

Et pour les Ataristes tous contents de pouvoir bientôt profiter d’une “bête de course”, il faudra revoir tout ce qui repose sur la MMU de leur côté.

C’est peut-être dommage, mais attendons de voir ce qui va être proposé à la place.
Lion
1 novembre 2016 à 18h52 #272651
sans compter l’adjonction des instructions AMMX compatibles avec celles d’Intel et le MMX !
lolof
1 novembre 2016 à 21h39 #272688
D’après ce que j’ai pu comprendre, l’auteur de MMU-Lib n’adaptera pas son code pour la vampire. Ce qu’il attend, comme d’autres, c’est que le MMU de la vampire soit compatible avec ses outils, ce qui semble assez logique….