Merci Alex, ça atténue mon point de vue, notamment le rapprochement avec mmap ... mais il reste à voir si c'est bien équivalent et si c'était l'idée motrice. Et ça serait cohérent avec le fait qu'en gros, on en ait besoin pour des applis grosses consommatrices de mémoires (quasiment toujours des portages Linux).

C'est bien, à la lecture de l'article j'avais un gros besoin de debriefer :-)

Je suis preneur de tout pointeur sur des explications sur le pourquoi la gestion de l'adressage multiple est impossible avec AmigaOS. Parce que si on avait ça, chaque processus pourrait avoir 4 Go (virtuels) et ce serait au kernel de gérer une mémoire physique de plus de 4 Go (pas aux applications).

>des explications sur le pourquoi la gestion de l'adressage multiple [...][chaque] processus pourrait avoir 4 Go

Déjà je vois un problème
Admettons l' OS gère 4 GO et ton prog 4 autres GO
et là ton prog fais, par exemple, un Text() d'un message texte dont l'adresse est dans ses 4GO
L'OS reçoit le pointeur 32bits il pourrait le convertir en pointeur 64 bits réel en connaissant le prog appellant et sa plage mémoire ... mais ne pourrais pas s'en servir car l'OS utilise que des pointeur 32 bits dans toutes ses fonctions
Bref tant que l' OS est pas 64 bits ça marchera pas ...

Je la fais plus simple pour tout le monde:
============================
Imaginons un OS qui manipule des adresses sur un digit de 0 à 9 décimal
Et une mémoire sur deux digits de 00 à 99 (100 octets) décimal
( c'est débile c'est un exemple)

Pour l'instant sur AmigaOS on est dans le cas ou l'OS et les progs sont de 0 à 9 et le reste de la memoire perdue

Dans le système Corto:
L' OS est (disons) de 20 à 29
Le prog est (disons) de 50 à 59
Le texte est (disons) à l'adresse 3 (en fait 53) vu du prog
je fais un appel système Text(3)
L'Os reçoit 3 : ou il garde 3 (vu depuis son espace mémoire, en fait 23 ) et c'est faux ou il convertit en 53 et ne peut rien en faire car l'OS ne manipule des adresses si grande (juste sur un digit)

Alain

réécrits => modifiés
Il faut quand même pas tout réécrire, juste les parties qui allouent la mémoire.

Quand ils ont sorti cette idée, j'ai posé la question "est-ce que l'OS ne pourrait pas s'occuper de ça de façon transparente ?". Cela aurait permis que tous les programmes puissent utiliser automatiquement >4Go de mémoire. On ma répondu que ce n'est pas possible. Dommage.

Elwood : J'aurais bien aimé qu'ils donnent plus de détails (ou avoir pu participer aux discussions).

Alain : Je suis d'accord avec le fait que l'OS ne peut pas gérer plus de 4 Go de mémoire physique tant que les adresses dans l'OS ne sont pas 64 bits. A ceci près qu'il existe des moyens pour dépasser ces 4 Go sur une architecture 32 bits, sur ARM ou x86 ... à voir sur PPC. On a récemment évoqué ça ici :
http://www.amiga-ng.org/viewtopic.php?topic=1863&forum=6&ancre=1&start=20#6186326869

Sinon je ne vois pas les choses telles que tu les décris : quand ton processus fait une lecture ou une écriture, l'adresse est sur 32 bits, elle est appelée Effective Address dans le PPC. Elle est étendue en adresse virtuelle (par example sur 52 bits) préfixant en gros le numéro du processus / de l'espace d'adressage. La MMU fait son oeuvre et fait correspondre cette adresse avec une adresse physique.

Donc dans ton exemple, le processus 5 admettons (qui a 10 unités de mémoire, de 50 à 59) écrit à l'adresse qui est pour elle 3. Comme l'OS sait que le processus en cours en le 5, il dit "tiens, j'en fait une adresse virtuelle 53". Puis l'OS regarde dans ses tables de mapping via la MMU et constate que l'adresse physique est par exemple 17 (une adresse qui sera dans ton exemple toujours entre 00 et 99).

Message édité par : Elwood / 24-05-2014 10:22

En créant un tel mécanisme pour quelques applications, est ce que ce mécanisme ne risque pas de compliquer les choses le jour où l'AmigaOS devient réellement 64bit? A moins qu'un AmigaOS4 64bit ne soit pas à l'ordre du jour et du coup ma question n'aurait plus d'intérêt.

C'est bien qu'ils communiquent sur les futures améliorations même si ce n'est pas la gestion par l'OS de plus de 2go que nous attendions.

En attendant comme dit le chef avec sa diplomatie habituelle :

"Documentation will be provided on the wiki and via the SDK.
Until then, there is not much to discuss yet because you can't even use the feature."


http://forum.hyperion-entertainment.biz/viewtopic.php?f=26&t=2490#p27881

@Sergius,

ce n'est pas à l'ordre du jour puisque c'est un énorme travail. A vu de nez il faudrait genre 2 ans de boulot à 2 développeurs à plein temps.
Parmis les développeurs, certains pensent qu'il n'y a aucun gain de performance à utiliser un OS 64 bits. Donc est-ce que ça vaudrait le coup/coût ? A voir.

@Corto

C'est un peu l'idée que j'avais. Si la MMU "voit passer" une adresse >4Go, elle peut très bien "faire le boulot" à la place du programme qui a demandé l'allocation mémoire comme si la MMU faisait "convertisseur" d'adresses entre l'adresse virtuelle et l'adresse physique.

@Elwood

Si, si il faut tout réécrire, toutes nos structures systèmes possèdent des pointeurs, si on passe à l'adressage 64 bits il faut agrandir ces structures pour voir accueillir 32 bits supplémentaires (par pointeur).
Et là je ne parle pas des structures TagItem qui sont utilisées par beaucoup de composants du système (y compris Reaction) et qui sont très typées 32bits (on passe des entiers longs 32bits qui parfois représentent des adresses mémoire).
Les API actuelles d'AmigaOS supposent que ce qu'un processus alloue sera accessible par d'autres processus, notamment lorsque l'on passe des paramètres à des fonctions systèmes : le programme appelant alloue la structure puis passe l'adresse à la fonction système (c'est le cas des Messages Exec qui sont alloués par un programme puis son adresse est déposé dans le port de Message de l'application destinatrice du message). Quand c'est exécuté dans le contexte de l'application pas de problème on reste dans le même espace d'adressage, par contre quand c'est, par exemple, exécuté dans le contexte de l'input.device bein ça coince : l'input.device étant un processus à part entière il aurait un espace d'adressage à lui...
Et même en imaginant qu'on le fasse on perdrait automatiquement la compatibilité avec tout ce qui se faisait auparavant : la compatibilité 68k évidemment, mais aussi la compatibilité PPC de tout ce qui aurait été écrit avant passage au 64 bits (ben oui un exemple tout bête : la structure Exec "List" n'aurait plus la même taille du coup le programme s'attendrait à avoir X octets mais n'en recevrait que Y (ou l'inverse) et ce serait catastrophique il lirait ou écrirait au delà de la zone mémoire et c'est le crash.

Concernant l'adressage privé ce serait tout à fait possible (et désirable) c'est la protection mémoire, chaque processus pourrait avoir 4Go virtuels à sa disposition, la seule contrainte c'est qu'il faudrait qu'à tout instant seulement 4Go physiques soient utilisés. Je verrais bien ça comme du swap mémoire, mais au lieu que cela se fasse sur disque on le ferait dans une zone mémoire étendue (ExtMem).

Elwood : Je ne suis pas sûr qu'en général, un OS 64 bits aille plus vite mais il faudrait rechercher et / ou mesurer.

Alex : Merci pour les infos. Je me demande toutefois si il y aurait ces problèmes si le kernel était 64 bits et le reste 32 bits. Ou même, il faudrait "juste" qu'il sache composer avec des adresses physiques 64 bits, dans la partie concernant la gestion mémoire.

Dans le cas des messages Exec, on pourrait tout à fait envisager des zones mémoire partagées, non ? Même dans le cas d'un espace d'adressage multiple.
De la même manière, une bibliothèque utilisée par 2 processus aurait une seule instance en mémoire physique, ce qui ne l'empêcherait pas d'être utilisée par ces 2 processus ... qui pourraient même la voir à 2 adresses (virtuelles) différentes.

@Corto

En effet un OS 64 bits est meme en général un peu moins rapide car il doit charger plus de données (64 bits au lieu de 32).

Concernant la question noyau 64bits seulement, cela revient à faire de la mémoire protégée avec un espace mémoire de 4Go par processus : chaque processus travaille dans un espace d'adressage 32bits qui lui est propre, c'est le système qui mappe les données comme il faut.
Le seul bémol dans ce cas là c'est qu'il faut que le système puisse savoir quels sont les adresses qui sont partageables, et pour ça il faudrait que tous les programmes se conforment aux nouvelles règles d'allocation d'objet système (appel à AllocSysObject ou AllocDosObject) et n'allouent plus des objets statiquement sur leur pile. On perdrait bien entendu la compatibilité avec tous les anciens programmes en faisant ça....