zut je viens de perdre une heure a taper un mail et IE me l’a foiré. pas grave je recommence.
Hier soir j’ai pris vingt minutes pour parcourir exec.doc et ses .h Et je trouve que des choses évidentes apparaissent.
Rappel: exec a du être fait vers 1985 par sassenrath et à cette époque UNIX avait dejà la mémoire protégée. de plus
il est evident qu’amigaOS s’inspire d’UNIX dans son noyau. en 85, les 68000 n’avaient pas de MMU. il était évident que les 68000 évolueraient vers du MMU.
Partout on a la notion de « fabrique » (au sens des design pattern, gestionnaire encapsulé qui crée et détruit des objet.) comme dans un systeme protégé. Par exemple, pour créer un écran, tu donnes à OpenScreen() une description (taglist) privée, et on te renvoie un pointeur vers une mémoire publique, dont la logique
est d’etre en lecture seule pour la tâche. et on a une fonction de destruction: CloseScreen()
Je me suis interessé aux messages que tu dis si sensible: dans exec, on a CreateMsgPort() et DeleteMsgPort() pour créer des ports de gestion de message. On manipule juste leurs pointeurs: gestion encapsulé en public,et justement
les messages pointent ces ports. Et exec.doc nous met en garde de pas bricoler son port soit meme,comme par hazard.
Je me suis ensuite interessé a PutMsg() qui permet d’envoyer des messages alloués sois-meme en privée, donc qui
pourrait poser probléme. Je me suis d’abord aperçu qu’en 6 ans de prog systeme je ne l’ai jamais utilisé ! et pour cause
on utilise énormément GetMsg() mais PutMsg() est plutot utilisé en privé par le systéme. J’ai donc fait une
recherche sur des codes utilisant PutMsg( ) dans le conference developerCD (réputé bancal), pour ma culture: dans la moitié des cas, les messages créée le sont par des factory (Create/DeleteRexxMsg,…) Mais dans l’autre moitié, ok, c’est une alloc privée, puis une obligation
de remplir une struct message, puis un PutMsg(). Mais voilà, dans cette struct il faut forcément remplir nm_Length,
qui contient la taille de la structure. Cela permet potentiellement à l’OS de la copier vers une struct publique a l’execution de PutMsg().
En résumé, l’AmigaOS que vous connaissez n’est pas adapté à une quelconque protection de la mémoire, par construction.
Pourquoi les concepteurs amiga aurait spécifié de remplir ce champs depuis 1985 alors qu’il est inutile dans une contexte non protégé ? Parce qu’ils avaient prévu de basculer tout amigaOS en protection mémoire c’est évident. Tout les exemple utilisant PutMsg remplissent ce champ.
Le problème principal est que ce système (recopier des msg) impose d’incessantes recopies de données lors
des communications entre tâches et accessoirement entre une tâche et l’OS (si nécessaire). C’est synonyme de ralentissement au niveau des API de communication inter-processus, et c’est la raison principale qui fait que l’AmigaOS et ses dérivés sont plus réactifs que les OS « protégés »
je ne suis pas d’accord du tout, tu résonnes en 68000,un cpu sans cache, ou meme le code executé devait passer systematiquement par le bus lors de l’execution, ou la moindre lecture/ecriture passait du cpu a la ram. Si les autres OS ne sont pas réactif, c’est à cause de leurs politiques de memoire virtuelle qui va meme cacher de la memoire video, avec des notions de priorité pas applicables (windows).
Dans le cas de recopie de message: On a UNE SEULE COPIE DE STRUCTURE PAR CREATION DE MESSAGE vers une mem publique, pas plus !!, et ces structs sont de taille minimale ! le PowerPC quand il switche de contexte de tache ( un nombre important de fois par seconde,meme sans protection) doit empiler/depiler 384 octet de regsitres, et au moins la moitié a chaque saut de fonctions !!
ainsi Les flux mémoires du au simple fonctionnement du PPC sont énormément plus volumineux et fréquent qu’une copie de struct de temps en temps. et considérez ceci:
dans un systeme non protégé PowerPC, la lecture d’une struct en cache prend un certain temps (lecture).
La recopie de la méme struct vers une plage publique peut se faire avec dcbz (en interne): dans ce cas, la copie
prend PRESQUE AUTANT de temps que la lecture seule de la struct du message !!!
La protection mémoire n’est pas l’ennemie de la réactivité !!! faut arreter de penser 68000 !!! La protection mémoire sous AMigaOS est possible et on l’aura !
) d’une part, et par la façon dont le système (le coeur) est conçus d’autre part. (et j’ai des doutes aussi sur la façon dont les fonctions sont générées dans le code).
Admin 
