J'ai jamais vu de Classic avec plus de 4 Go de mémoire. Ce serait comme une 2CV avec un réservoir de F1 :-)

adore quand il dit que sa peut marcher sur classic :)

Peut-être des éclaircissements via les commentaires d'un des Frieden :
http://www.amigans.net/modules/xforum/viewtopic.php?post_id=91207#forumpost91207

Ok, autrement dit "c'est quasi-impossible" et du coup la solution de ExtMem est pas mal :-)

@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....

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.

@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).

@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.

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

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.