Dépend des architectures dont vous parlez. Voici quelques exemples.
x86
Si vous exécutez une application x86 32 bits sur un x86-64 64 bits, l'application verra une machine 32 bits, car le processeur entre dans un mode de fonctionnement spécial qui masque les extensions 64 bits. Les instructions se comporteront comme si chacun des registres entiers scalaires n'avait que 32 bits. (Je dis "entier scalaire" pour laisser de côté le FPU, MMX, SSE, AVX, etc.)
Lorsque le processeur repasse du mode 32 bits au mode 64 bits (par exemple, lors d'un appel au système d'exploitation), les 32 bits supérieurs de chacun des registres 64 bits correspondants auront été mis à zéro, si la tâche 32 bits a écrit dans ces registres. De la manière dont x86-64 est défini, une écriture dans EAX vous donne la valeur correspondante dans RAX, avec les 32 bits supérieurs mis à zéro.
Divers registres microarchitecturaux cachés ne changent pas de comportement.
L'histoire est similaire si vous exécutez une application ARM AArch32 sur un processeur ARM AArch64. (AArch32 et AArch64 sont les noms d'ARM pour les variantes 32 bits et 64 bits d'ARMv8). La plateforme AArch64 possède un jeu de registres scalaires plus important, et les registres eux-mêmes sont plus grands.
ARM définit un mappage entre les jeux de registres 32 bits et 64 bits. Ce mappage définit comment les valeurs circulent entre le mode 64 bits et le mode 32 bits dans les registres du processeur.
SPARCv9
SPARCv9 a étendu le jeu d'instructions de telle sorte que le code 32 bits ne pouvait pas dire qu'il s'exécutait sur une machine 64 bits. Toutes les instructions ont été élargies de manière transparente de 32 bits à 64 bits.
Dans la plupart des cas, l'élargissement de l'instruction n'a aucun impact sur son comportement dans les 32 bits inférieurs. Dans les cas où cela a de l'importance, comme les décalages vers la droite et les accès à la mémoire, SPARC a ajouté de nouveaux opcodes pour fournir un comportement 64 bits, les opcodes existants étant limités à 32 bits.
Donc, dans le cas de SPARC, il n'y a pas vraiment d'applications 32 bits, mais plutôt du code qui ignore la capacité 64 bits.
DEC Alpha
Celle-ci est un peu étrange, car DEC Alpha était un processeur 64 bits dès le début. Mais, il avait une fonctionnalité appelée FX!32 qui lui permettait d'exécuter efficacement du code x86 32 bits. Il s'agit techniquement d'une combinaison d'émulation logicielle et de traduction binaire.
Donc, dans ce scénario, l'environnement FX!32 recompile en fait du code x86 en code Alpha, et il n'y a pas de correspondance évidente entre les registres x86 et les registres DEC Alpha.