Depende de las arquitecturas a las que te refieras. Aquí tienes algunos ejemplos.
x86
Si ejecutas una aplicación x86 de 32 bits en un x86-64 de 64 bits, la aplicación verá una máquina de 32 bits, ya que el procesador entra en un modo de funcionamiento especial que oculta las extensiones de 64 bits. Las instrucciones se comportarán como si cada uno de los registros enteros escalares tuviera sólo 32 bits. (Digo "entero escalar" para dejar fuera la FPU, MMX, SSE, AVX, etc.)
Cuando el procesador cambia del modo de 32 bits de vuelta al modo de 64 bits (digamos, al hacer una llamada al SO), los 32 bits superiores de cada uno de los registros de 64 bits correspondientes se habrán puesto a cero, si la tarea de 32 bits escribió en esos registros. La forma en que x86-64 se define, una escritura en EAX le da el valor correspondiente en RAX, con los 32 bits superiores a cero.
Varios registros microarquitectónicos ocultos no cambian de comportamiento.
ARMv8
La historia es similar si se ejecuta una aplicación ARM AArch32 en una CPU ARM AArch64. (AArch32 y AArch64 son los nombres de ARM para las variantes de 32 y 64 bits de ARMv8). La plataforma AArch64 tiene un conjunto de registros escalares más grande, y los propios registros son más grandes.
ARM define un mapeo entre los conjuntos de registros de 32 y 64 bits. Este mapeo define cómo fluyen los valores entre el modo de 64 bits y el modo de 32 bits en los registros de la CPU.
SPARCv9
SPARCv9 amplió el conjunto de instrucciones de tal manera que el código de 32 bits no podía decir que se estaba ejecutando en una máquina de 64 bits. Todas las instrucciones se ampliaron de forma transparente de 32 bits a 64 bits.
En la mayoría de los casos, la ampliación de la instrucción no tiene ningún impacto en su comportamiento en los 32 bits inferiores. En los casos en los que sí importa, como los desplazamientos a la derecha y los accesos a la memoria, SPARC añadió nuevos opcodes para proporcionar un comportamiento de 64 bits, con los opcodes existentes limitados a 32 bits.
Así que, en el caso de SPARC, realmente no hay aplicaciones de 32 bits tanto como hay código que ignora la capacidad de 64 bits.
DEC Alpha
Este es un poco extraño, ya que DEC Alpha era una CPU de 64 bits desde el principio. Pero, tenía una característica llamada FX!32 que le permitía ejecutar código x86 de 32 bits de forma eficiente. Es técnicamente una combinación de emulación de software y traducción binaria.
Así que en este escenario, el entorno FX!32 está realmente recompilando código x86 a código Alpha, y no hay un mapeo obvio entre los registros x86 y los registros DEC Alpha.