Peut-on utiliser des pointeurs de taille 4 bits, 8 bits, 16 bits ou 32 bits sur une machine 64 bits ?

Tout d'abord, 3904 Go de mémoire ne nécessitent que 42 bits pour l'adresse . Il se compose uniquement de 3 904 000 000 000 au lieu de ce que vous avez calculé. Il est possible de le vérifier rapidement à l'aide de PowerShell

PS C:\> [math]::Log(3904GB, 2) # GB base 2, or GiB
41.9307373375629
PS C:\> [math]::Log(3904e9, 2) # GB base 10
41.8280901915491

Donc, techniquement, même sur une machine 64 bits, si vous n'utilisez que moins de 4 milliards d'entiers (taille maximale d'un entier de 32 bits), je me demande pourquoi vous ne pouvez pas simplement avoir des pointeurs de 32 bits. De cette façon, les pointeurs sont en 32 bits jusqu'à ce que vous manquiez d'espace, puis vous pouvez commencer à utiliser des pointeurs en 64 bits. On aurait alors un peu plus d'espace pour avoir plus d'objets.

x32 ABI es un ABI x86 64 bits qui utilise des pointeurs 32 bits. Les processus n'ont qu'un espace d'adressage de 32 bits, ce qui signifie qu'ils ne peuvent pas utiliser plus de 4 Go de mémoire (ce qui n'est pas un problème pour la plupart des applications utilisateur), mais qu'ils pourront profiter de l'espace de registre plus grand et plus large. L'espace mémoire global est toujours de 64 bits, puisqu'il est fixé dans le matériel, et le pointeur 32 bits sera donc utilisé comme un décalage par rapport à l'adresse de base du processus au lieu d'un pointeur direct. L'implémentation est simplement la suivante

void* getRealPointer(uintptr_t base_addr, uint32_t ptr)
{
    // value stored in pointer is the offset/distance from base
    return (void*)(base_addr + ptr);
}

Cette technique est également utilisée sur de nombreuses autres architectures RISC 64 bits telles que Sparc ( Pourquoi Linux sur l'architecture sparc64 utilise-t-il des pointeurs 32 bits dans l'espace utilisateur et des pointeurs 64 bits dans l'espace noyau ? ), MIPS ou PowerPC, puisque lors de la transition vers le 64 bits, ils n'ont pas augmenté le nombre de registres comme x86 et ARM, ce qui signifie qu'un processus 32 bits est probablement plus rapide qu'un processus 64 bits, à moins qu'il ne nécessite beaucoup de mathématiques 64 bits ou plus de 2/3/4 Go de RAM.

Sur les processeurs 64 bits comme le G5, Debian PPC utilise un noyau 64 bits avec un espace utilisateur 32 bits. C'est parce que les processeurs PowerPC 64 bits n'ont pas de " mode 32 bits " comme l'architecture Intel 64/AMD64. Par conséquent, les programmes PowerPC 64 bits qui n'ont pas besoin de fonctions mathématiques 64 bits fonctionneront un peu plus lentement que leurs homologues 32 bits, car les pointeurs 64 bits et les entiers longs consomment deux fois plus de mémoire, remplissent le cache du CPU plus rapidement, et nécessitent donc des accès plus fréquents à la mémoire.

Linux sur PowerPC

Néanmoins, vous ne pouvez pas vous contenter d'utiliser des pointeurs 32 bits until you run out of space then start using 64-bit pointers Cela n'a pas de sens. Un type a toujours une taille fixe. Si vous réservez de l'espace pour seulement 32 bits du pointeur, que se passera-t-il lorsque vous devrez utiliser des pointeurs de 64 bits ? Où stockerez-vous la partie haute ?

Ainsi, si nous devions avoir des pointeurs 32 bits pointant vers des morceaux 32 bits dans la mémoire 64 bits, je ne suis pas sûr de savoir à quoi cela ressemblerait ou ce que cela signifierait

C'est ce qu'on appelle mémoire adressable par mot . Au lieu de pointer vers chaque octet, chaque valeur pointe simplement vers un octet différent. mot

• Que signifie "résolution d'adresse au niveau de l'octet" ?
• La mémoire adressable par mot comporte-t-elle plus d'octets que la mémoire adressable par octet ?
• Adressable par octets / mots
• Comment l'architecture d'un ordinateur peut-elle être adressable par mot alors que la mémoire physique n'est adressable que par octet ? Les deux adresses mémoire sont-elles fusionnées ?

Il sera plus facile d'imaginer que la mémoire consiste en une série d'éléments linéaires. cellules qui sont identifiées par des identifiants uniques. Ces identifiants sont ce que nous appelons normalement "adresse" et sont stockés dans les pointeurs. La taille des cellules est généralement de 1 octet sur les systèmes modernes (c'est-à-dire une mémoire adressable par octet). Cependant, les de nombreux systèmes plus anciens, comme Unisys ou PDP, utilisent une mémoire adressable par mot avec une cellule contient un mot (d'une longueur de 36 bits dans le cas de ces architectures). Par conséquent, dans ces systèmes char* serait plus grand que int* puisque vous aurez besoin de quelques bits supplémentaires pour stocker la position de l'octet que vous voulez adresser

Je ne comprends pas très bien votre tableau, mais il est rare que l'on ait besoin d'adresser chaque bit de cette manière, car cela réduit évidemment la mémoire totale que l'on peut adresser. Bien que, pour être juste, il existe quelques architectures avec une mémoire adressable par bit, principalement des systèmes embarqués. On a l'impression que l'on veut les 32 premiers bits d'une valeur de 64 bits lorsqu'on donne une adresse de 32 bits à l'unité centrale, mais ce n'est pas comme ça que ça marche. Pour adresser chaque moitié, vous aurez besoin d'un bit significatif supplémentaire au lieu de la moitié du nombre de bits. Le principe est simple : Si l'on utilise des cellules plus grandes, pour la même quantité de mémoire, il faut moins de cellules, ce qui signifie qu'il faut moins de bits pour l'ID, et vice versa. Au niveau matériel, la taille des cellules est généralement fixe.

Voici un exemple pour les 16 premiers octets de la mémoire

 0000  0001  0010  0011  0100  0101  0110  0111  1000  1001  1010  1011  1100  1101  1110  1111 

 b0    b1    b2    b3    b4    b5    b6    b7    b8    b9    b10   b11   b12   b13   b14   b15  

 w0 000       w1 001       w2 010       w3 011       w4 100       w5 101       w6 110       w7 111      

 dw0 00                     dw1 01                     dw2 10                     dw3 11                    

 o0                                                     o1                                                    

Vous pouvez également consulter l'illustration dans cette réponse

Si nous adressons chaque mot de 2 octets, le Nième mot aura l'adresse de l'octet N*2. Il en va de même pour toutes les autres tailles de blocs, pour lesquelles le décalage réel peut être calculé comme suit offset*sizeof(chunk) . Par conséquent, les 2 bits de poids faible d'une adresse alignée sur 4 octets et les 3 bits de poids faible d'une adresse alignée sur 8 octets sont toujours à zéro. Si vous n'utilisez pas de pointeurs adressables par mot, ces bits de poids faible peut être utilisé pour stocker des données qui est appelé pointeur étiqueté

La JVM 64 bits utilise cette technique avec comprimés Oops . Voir le L'astuce derrière les Oops compressés de la JVM En Java, les objets sont toujours alignés sur 8 octets, de sorte qu'ils peuvent adresser 8*4 = 32 Go de mémoire avec une adresse de 32 bits.

Les pointeurs gérés dans le tas Java pointent vers des objets alignés sur des limites d'adresse de 8 octets. Les oops compressés présentent les pointeurs gérés (dans de nombreux endroits du logiciel de la JVM, mais pas dans tous) comme des décalages d'objets de 32 bits par rapport à l'adresse de base du tas Java de 64 bits. Comme il s'agit de décalages d'objets plutôt que de décalages d'octets, ils peuvent être utilisés pour adresser jusqu'à quatre milliards d'objets (et non d'octets), ou un tas d'une taille maximale d'environ 32 gigaoctets. Pour les utiliser, il faut les mettre à l'échelle par un facteur de 8 et les ajouter à l'adresse de base du tas Java pour trouver l'objet auquel ils se réfèrent. La taille des objets utilisant les oops compressés est comparable à celle du mode ILP32.

https://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#compressedOop

Récemment, Google a également appliqué la même technique à son moteur de rendu V8 et utilise Pointeur 32 bits dans V8 64 bits réduction de l'empreinte mémoire de ~35%

Les instructions de branchement et de chargement/stockage de la plupart des architectures RISC stockent également l'adresse du mot dans la partie immédiate, car il est inutile de gaspiller un espace précieux en sauvegardant ces bits toujours nuls. Par exemple, les instructions de branchement et de chargement/stockage Instructions de branchement et de saut du MIPS : JAL, J, BEQ, BLEZ, BGTZ...