Desde la perspectiva de software, la computación de 64 bits significa el uso de código con direcciones de memoria virtuales de 64-bits.
En el mundo de la imagen digital, para referirse a imágenes de 48 bits, 16 bits por color = 48 + 16 bit de canal Alpha cuando es utilizado.[cita requerida]
Son más conocidos por haber sido parte de la quinta generación de videoconsolas, junto a los 32 bits.
Aunque una CPU puede ser internamente de 64 bits, su bus de datos o bus de direcciones externos pueden tener un tamaño diferente, más grande o más pequeño y el término se utiliza habitualmente para describir también el tamaño de estos buses. Por ejemplo, muchas máquinas actuales con procesadores de 32 bits usan buses de 64 bits (p.ej. el Pentium original y las CPUs posteriores) y pueden ocasionalmente ser conocidas como "64 bits" por esta razón. El término también se puede referir al tamaño de las instrucciones dentro del conjunto de instrucciones o a cualquier otro elemento de datos (p.ej. las cantidades de 64 bits de coma flotante de doble precisión son comunes). Sin más calificaciones, sin embargo, la arquitectura de las computadoras de 64 bits tiene integrados registros que son de 64 bits, que permite procesar (interna y externamente) datos de 64 bits.
Implicaciones de arquitectura
Los registros en un procesador se dividen generalmente en tres grupos: enteros, coma flotantes ( números decimales ) y otros. En todos los procesadores de propósito general, solo los registros enteros pueden almacenar punteros (una dirección de algún dato en memoria). Los registros que no son de enteros no se pueden utilizar para almacenar punteros para leer o escribir memoria y por tanto no se pueden utilizar para evitar cualesquiera restricciones impuestas por el tamaño de los registros enteros.
Casi todos los procesadores de propósito general (con la notable excepción de muchos ARM e implementaciones MIPS de 32 bits) han integrado hardware de coma flotante, que puede o no utilizar registros de 64 bits para transportar datos con el fin de procesarlos. Por ejemplo, la arquitectura X86 incluye instrucciones de coma flotante del x87 que utiliza 8 registros de 80 bits en una configuración en forma de pila; revisiones posteriores del x86 y la arquitectura x86-64 también incluyen instrucciones SSE que utilizan 8 registros de 128 bits (16 registros en el x86-64). En contraste, el procesador de 64 bits de la familia DEC Alpha define 32 registros de coma flotante de 64 bits además de sus 32 registros de enteros de 64 bits.
Debería notarse que la velocidad no es el único factor por considerar en una comparación de procesadores de 32 bits y 64 bits. Usos como la multitarea, las pruebas de carga y el clustering (para computación de alto rendimiento) pueden ser más idóneos para una arquitectura de 64 bits teniendo en cuenta un desarrollo correcto. Los clusters de 64 bits han sido ampliamente usados en grandes organizaciones como IBM, Vodafone, HP y Microsoft, por esta razón.
Mientras las arquitecturas de 64 bits incontestablemente hacen más sencillo el trabajar con grandes conjuntos de datos en aplicaciones como el vídeo digital, computación científica y grandes bases de datos, ha habido un debate considerable sobre si los modos de compatibilidad con 32 bits serán más rápidos que los sistemas de 32 bits del mismo precio para otras tareas. En las arquitecturas x86-64 (AMD64 y EM64T, IA-32e), la mayoría de los sistemas operativos de 32 bits y aplicaciones pueden ejecutarse sin problemas en el hardware de 64 bits.
Limitaciones de memoria
Los procesadores de 64 bits pueden direccionar teóricamente hasta 16 exabytes de memoria RAM, mientras que los procesadores de 32 bits solo pueden direccionar un máximo de 4 GB de memoria RAM.[1]
Muchas CPU (en 2009) están diseñadas para que los contenidos de un único registro puedan almacenar la dirección de memoria de cualquier dato en la memoria virtual. Por tanto, el número total de direcciones en memoria virtual — la suma total de datos que la computadora puede mantener en su área de trabajo — es determinado por el ancho de estos registros. Empezando en los años 1960 con el IBM S/360, luego (entre muchos otros) la computadora VAX de DEC en los años 1970 y luego con el Intel 80386 a mediados de los años 1980, un consenso de facto instauró que 32 bits era un tamaño conveniente de registro. Un registro de 32 bits significa que se puede referenciar 232 direcciones o 4 gigabytes de RAM. En el momento en que estas arquitecturas fueron concebidas, 4 gigabytes de memoria estaban muy lejos de las cantidades disponibles en instalaciones que se consideraban suficiente "espacio" para direccionamiento. Las direcciones de 4 gigabytes se consideraban un tamaño apropiado con el que trabajar por otra importante razón: 4 mil millones de enteros son suficientes para asignar referencias únicas a la mayoría de cosas físicamente contables en aplicaciones como bases de datos.
No obstante, con el paso del tiempo y las continuas reducciones en el coste de la memoria (véase la Ley de Moore), al comienzo de los años 1990, comenzaron a aparecer instalaciones con cantidades de RAM próximas a los 4 gigabytes, y comenzó a ser deseable el uso de espacios de memoria virtual que superaban el límite de 4 gigabytes para manejar ciertos tipos de problemas. Como respuesta, varias empresas empezaron a lanzar nuevas familias de chips con arquitecturas de 64 bits, inicialmente para supercomputadoras, estaciones de trabajo de grandes prestaciones y servidores. Las computadoras de 64 bits se han ido moviendo hacia la computadora personal, comenzando en 2003 con la innovadora tecnología AMD64 (denominada genéricamente x86-64 por su completa compatibilidad inversa con los sistemas x86), los AMD's K8 (Athlon 64) y la arquitectura PowerPC de Macintosh de Apple Computer con los procesadores PowerPC 970 G5Antares, y a procesadores EM64T en 2006, basadas también en tecnología x86-64, llegando a ser comunes en PC de gama alta. La aparición de la arquitectura de 64 bits efectivamente incrementa el límite a 264 direcciones, equivalente a 17 179 869 184 gigabytes o 16 exabytes de RAM. Para poner esto en perspectiva, en los días en que 4 MB de memoria principal eran comunes, el límite máximo de memoria de 232 direcciones era unas 1000 veces mayor que la configuración típica de memoria. En 2007, cuando 1GB de memoria principal es común, el límite de 264 es unos diez mil millones de veces superior, es decir diez millones de veces más de espacio.
Muchos PC de 64 bits del mercado tienen actualmente un límite artificial en la cantidad de memoria que pueden reconocer, pues las limitaciones físicas hacen muy poco probable que se vaya a necesitar soporte para los 16 exabytes de capacidad total. El Mac Pro de Apple, por ejemplo, puede configurarse físicamente con hasta 768 gigabytes de memoria (2020), y por ello no hay necesidad de soportar más allá de esa cantidad. Un núcleo linux reciente (versión 2.6.16) puede ser compilado con soporte para hasta 64 gigabytes de memoria. Según Apple la nueva versión de su sistema operativo teóricamente direcciona 16 Terabytes de memoria.[2]
Sistemas operativos
En Windows, la más importante diferencia entre las versiones 32 y 64 bits es que el primero admite hasta 4 GB de RAM, de los cuales aprovechará tan solo 3.25 GB. En el caso de los sistemas operativos de 64 bits estos admiten hasta 32 GB. de RAM.[1]
Algo a tener en cuenta es la compatibilidad del software de usuario, es decir los programas, y los controladores encargados de hacer funcionar el hardware. Es sumamente importante que antes de dar el salto estemos bien seguros de que todo nuestro hardware como cámaras, escáneres, impresoras y todo lo demás cuenten con una versión de 64 bits de sus controladores o bien que cuenten con controladores genéricos en dichos sistemas.[1]
Otra cosa que tenemos que tener en cuenta es que si queremos migrar a una arquitectura de 64 bits a partir de una versión de Windows de 32 bits, no se podrá hacer mediante una actualización o parche, tendremos que comprar una versión específica para esa arquitectura. Si utilizamos un sistema operativo libre como Debian o sus derivados como Ubuntu, la migración no será problema.[1]
Arquitecturas de microprocesador de 64 bits actuales
Las arquitecturas de microprocesador de 64 bits (a fecha de 2006) comprenden:
Intel usa ahora el mismo conjunto de instrucciones en los procesadores Pentium 4 y Xeon nuevos y en los procesadores Core 2 Duo, llamándola Intel 64 (previamente conocida como EM64T, originalmente IA-32e). Los fabricantes de software Microsoft y Sun Microsystems llaman a este conjunto de instrucciones "x64".
Las arquitecturas MIPS IV, MIPS V, y MIPS64 de MIPS Technologies
La familia PA-RISC de HP (de 64 bits desde el PA-RISC 2.0)
Muchas arquitecturas de procesador de 64 bits pueden ejecutar nativamente código de la versión de 32 bits de la arquitectura sin ninguna penalización en el rendimiento. Este tipo de soporte se conoce frecuentemente como soporte biarquitectura o más generalmente como soporte multiarquitectura.
Historia
Cronología del procesador de 64 bits
1961: IBM lanzó la supercomputadora IBM 7030 Stretch. Este utilizaba palabras de 64 bits e instrucciones de 32 o 64 bits.
1974: Control Data Corporation lanzó la supercomputadora vectorial CDC Star-100, que utiliza una arquitectura de palabras de 64 bits (los sistemas previos de CDC estaban basados en arquitecturas de 60 bits).
1976: Cray Research lanzó la primera computadora Cray-1. Este estaba basado en una arquitectura de palabras de 64 bits, que sentó las bases para los posteriores supercomputadoras vectoriales de Cray.[3]
1983: Elxsi lanzó la mini supercomputadora Elxsi 6400 paralelo. La arquitectura Elxsi tenía registros de datos de 64 bits pero un espacio de direcciones de 32 bits.
1991: MIPS Technologies produjo el primer microprocesador de 64 bits, como la tercera revisión de la arquitectura RISCMIPS, el R4000. La CPU fue utilizada en las estaciones de trabajo de Silicon Graphics empezando con el IRIS Crimson. Sin embargo, el soporte de 64 bits para el R4000 no se incluyó en el sistema operativoIRIX hasta la versión IRIX 6.2 en 1996.
1993: DEC lanzó los sistemas operativos de 64 bits estilo UNIX Tru64 y el OpenVMS para Sistemas Alpha.
1994: Intel anunció sus planes para la arquitectura IA-64 de 64 bits (desarrollada conjuntamente con HP) como sucesor de su procesador de 32 bits IA-32. SGI lanzó el IRIX 6.0 con soporte de 64 bits para las CPUs R8000.
1995: Sun lanzó un procesador SPARC de 64 bits, el UltraSPARC. HAL Computer Systems propiedad de Fujitsu lanzó estaciones de trabajo basadas en una CPU de 64 bits, HAL independientemente diseñó la primera generación de SPARC64. IBM lanzó los sistemas AS/400 de 64 bits, con la posibilidad de actualizar el sistema operativo, las bases de datos y las aplicaciones. DEC lanzó el OpenVMS Alpha 7.0, la primera versión completa de 64 bits de OpenVMS para Alpha.
1996: HP lanzó una implementación de 64 bits, la versión 2.0 de su arquitectura de procesador PA-RISC, el PA-8000. Nintendo introdujo la consola de videojuegos Nintendo 64, construida con una variante de bajo coste del MIPS R4000.
1997: IBM lanzó su RS64 equipado con procesadores PowerPC de 64 bits.
1998: IBM lanzó su procesador POWER3 completamente de 64 bits de la familia PowerPC/POWER. Sun lanzó Solaris 7, con soporte completo para UltraSPARC de 64 bits.[5]
1999: Intel publicó el conjunto de instrucciones para la arquitectura IA-64. Primera revelación pública del juego de extensiones de 64 bits al IA-32 de AMD (posteriormente renombrado como AMD64).
2000: IBM estrenó su primer mainframe de 64 bits, el z900 y su nuevo sistema operativo, el Z/OS — culminando el mayor desarrollo de la historia de investigación de un procesador de 64 bits e instantáneamente borrando la compatibilidad con las máquinas de 31 bits de sus competidores Fujitsu/Amdahl e Hitachi. Un Linux para zSeries de 64 bits apareció casi inmediatamente.
2001: Intel finalmente lanzó su línea de procesadores de 64-bit, con la marca Itanium, teniendo como objetivo servidores de gama alta. No cumplió las expectativas debido a los repetidos retrasos del lanzamiento del IA-64 al mercado y se convirtió en un fracaso. Linux fue el primer sistema operativo en esta versión de procesador.
2002: Intel introdujo el Itanium 2 como sucesor del Itanium.
2003: AMD sacó a la luz sus líneas de procesadores con arquitectura AMD64 Opteron y Athlon 64. Apple lanzó también sus CPUs PowerPC 970 "G5" de 64 bits por cortesía de IBM, junto con una actualización de su sistema operativo Mac OS X, que añadió soporte parcial para el modo de 64 bits. Se publicaron varias distribucionesLinux con soporte para AMD64. Microsoft anunció que crearía una versión de su sistema operativo Windows para esos chips AMD. Intel sostuvo que sus chips Itanium serían sus únicos procesadores de 64 bits.
2004: Intel, reaccionando al éxito de mercado de AMD, admitió que había estado desarrollando un clon de las extensiones AMD64, al que llamó IA-32e y posteriormente renombró como EM64T. Se lanzaron versiones actualizadas de sus familias de procesadores Xeon y Pentium 4 que soportaban las nuevas instrucciones. Freescale anuncia su núcleo e700, sucesor de su familia PowerPC G4.
2005: El 31 de enero, Sun lanzó Solaris 10 con soporte para los procesadores AMD64 y EM64T. En marzo, Intel anunció que sus primeros procesadores EM64T de doble núcleo se pondrían a la venta en el segundo cuatrimestre de 2005 con la publicación de su Pentium Extreme Edition 840 y los nuevos chips Pentium D. El 30 de abril, Microsoft lanzó públicamente su Windows XP Professional x64 Edition para procesadores AMD64 y EM64T. En mayo, AMD introdujo sus primeros procesadores para servidores Opteron AMD64 de doble núcleo y anunció su versión de escritorio, llamada Athlon 64 X2. Los primeros procesadores Athlon 64 X2 (Toledo) contaban con dos núcleos con una memoria caché L2 de 1MB y consistían de aproximadamente 233,2 millones de transistores. Tenían un tamaño de 199 mm². En julio, IBM anunció sus nuevos procesadores PowerPC 970MP (cuyo nombre en código era Antares) de doble núcleo y 64 bits usados por IBM y Apple. Microsoft lanzó la consola Xbox 360 que usaba el procesador PowerPC de 64 bits Xenon, fabricado por IBM.
2006: Se pusieron en producción los procesadores Itanium 2 Montecito de doble núcleo. Sony, IBM y Toshiba comenzaron a fabricar el procesador Cell para su uso en la PlayStation 3, servidores, estaciones de trabajo y otros dispositivos. Apple incorporó procesadores XeonEM64T de 64 bits en su nuevo Mac Pro y sus computadoras Intel Xserve, y posteriormente actualizó el iMac, el MacBook y el MacBook Pro con procesadores EM64T Intel Core 2 Duo.
2011: ARM Holdings anuncia ARMv8-A, la primera versión de 64 bits de la arquitectura de ARM.[6]
2012: ARM Holdings anunció sus núcleos Cortex-A53 y Cortex-A57, sus primeros núcleos basados en su arquitectura de 64 bits, el 30 de octubre de 2012.[7]
2013: Apple anuncia el iPhone 5S, el primer teléfono inteligente de 64 bits, que utiliza su sistema basado en el A7 ARMv8-A en un chip.
2014: Google anuncia el Nexus 9, el primer dispositivo Android que funciona con un procesador Tegra K1 de 64 bits.[8]
Más allá de los 64 bits
A fecha de 2007, las palabras de 64 bits parecen ser suficientes para la mayoría de usos prácticos. Aun así, debería mencionarse que el System/370 de IBM usa números de coma flotante de 128 bits, y muchos procesadores modernos incluyen registros de coma flotante de 128 bits. Sin embargo, el System/370 era notable, en que también usaba números decimales de longitud variable de hasta 16 bytes de longitud (es decir, de 128 bits).
El cambio de una arquitectura de 32 bits a una de 64 bits es una alteración fundamental, y muchos sistemas operativos tienen que modificarse ostensiblemente para aprovechar las ventajas de la nueva arquitectura. El resto del software también tiene que ser portado para usar las nuevas capacidades; el software antiguo normalmente es soportado a través del modo de hardware compatible (en el que los nuevos procesadores soportan las versiones antiguas del conjunto de instrucciones antiguo de 32 bits, así como las de la versión de 64 bits), a través de emulación software o por la implementación de un núcleo de procesador de 32 bits dentro del procesador de 64 bits (como con los procesadores Itanium de Intel, que incluyen un núcleo de procesador x86 para ejecutar aplicaciones x86 de 32 bits). Los sistemas operativos para estas arquitecturas de 64 bits generalmente soportan aplicaciones de 32 bits y de 64 bits.
Una excepción significativa de esto es el AS/400, cuyo software se ejecuta en un conjunto de instrucciones virtual, llamado TIMI (Technology Independent Machine Interface) que se traduce a código nativo por software de bajo nivel antes de ser ejecutado. El software de bajo nivel es todo lo que ha de ser reescrito para portar todo el SO y el software a una nueva plataforma, como cuando IBM hizo la transición de su línea desde los antiguos juegos de instrucciones de 32/48 ("IMPI") al PowerPC de 64 bits (IMPI no tenía nada que ver con el PowerPC de 32 bits, así que fue incluso una transición mayor que la de un juego de instrucciones de 32 bits a su equivalente de 64 bits).
Las máquinas virtuales de JAVA de 64 bits de Sun son más lentas en el arranque que las de 32 bits porque Sun sigue asumiendo que todas las máquinas de 64 bits son servidores y solo han implementado el compilador de "servidor" (C2) para plataformas de 64 bits. El compilador "cliente" (C1) produce código más lento, pero compila mucho más rápido. Así que aunque un programa Java en una JVM de 64 bits puede funcionar mejor en un periodo grande de tiempo (típico de aplicaciones "servidoras" de ejecución larga), su tiempo de arranque será probablemente mucho mayor. Para aplicaciones de vida corta (como el compilador de Java, javac) el incremento en el tiempo de arranque puede dominar el tiempo de ejecución, haciendo la JVM de 64 bits más lenta en conjunto.
El "Efecto 2038", es un bug producido en programas que usen la representación del tiempo basada en el sistema POSIX, y que afecta a sistemas Unix y basados en Unix.
En la mayoría de los sistemas de 32 bits time_t es un entero de 32 bits con signo, y una vez que el valor llegue a 2.147.483.647 (2038-19-01 03:14:07 UTC) al segundo siguiente saltara al valor -2.147.483.648 (1901-13-12 o 1970-01-01). En cambio, en la mayoría de los sistemas de 64 bits se utilizan enteros de 64 bits en time_t, lo cual soluciona el problema por unos miles de millones de años.
Disponibilidad del Software
Los sistemas de 64 bits algunas veces carecen de software equivalente escrito para arquitecturas de 32 bits. Los problemas más graves son debidos a controladores de dispositivo incompatibles. Aunque gran parte del software puede ejecutarse en modo de compatibilidad con 32 bits (también conocido como un modo emulado, p. ej. la Tecnología Microsoft WoW64), normalmente es imposible ejecutar un controlador de dispositivo o un programa similar, en ese modo ya que habitualmente se ejecuta entre el SO y el hardware, donde no se puede usar la emulación directa. Muchos paquetes de software de código abierto pueden simplemente ser compilados para trabajar en un entorno de 64 bits en sistemas operativos como GNU/Linux. Un software de 32 bits puede funcionar en un procesador de 64 bits, pero incorrectamente; pero un software de 64 bits no puede ejecutarse en un procesador de 32 bits.
Modelos de datos de 64 bits
La conversión de aplicaciones escritas en lenguajes de alto nivel desde una arquitectura de 32 bits a una de 64 bits varía en dificultad. Un problema común recurrente es que algunos programadores asumen que los punteros tienen la misma longitud que otros tipos de datos. Esos programadores asumen que pueden transferir cantidades entre estos tipos de datos sin perder información. Estos supuestos se dan realmente en algunas máquinas de 32 bits (e incluso en algunas de 16 bits), pero no se dan en máquinas de 64 bits. El lenguaje de programación C y su descendiente el C++ hacen particularmente fácil cometer este tipo de errores.
Para evitar este error en C y C++, se puede utilizar el operador sizeof para determinar el tamaño de estos tipos primitivos si se necesitan tomar decisiones basadas en el tamaño en tiempo de ejecución. También la cabecera <limits.h> en el estándar C99 y la clase numeric_limits en la cabecera <limits> en el estándar de C++, dan más información útil; sizeof solo devuelve el tamaño en caracteres, lo que es a veces engañoso, porque el propio tamaño de un carácter (CHAR_BITS) no está definido de la misma manera en todas las implementaciones de C o C++.
Se necesita ser cuidadoso para usar el tipo ptrdiff_t (en la cabecera estándar <stddef.h>) para el resultado de restar dos punteros, demasiado código incorrecto utiliza "int" o "long" en su lugar. Para representar un puntero (más que un puntero diferencia) como un entero, se usa uintptr_t cuando está disponible (solo está definida en C99, pero algunos compiladores anteriores al estándar lo cumplen ofreciéndolo como una extensión).
Ni C ni C++ definen la longitud de un puntero, ni de datos int ni long a un número de bits específicos.
En muchos entornos de programación en máquinas de 32 bits, los punteros, las variables "int" y las variables "long" tienen todos 32 bits de longitud.
Sin embargo, en muchos entornos de programación en máquinas de 64 bits, las variables "int" siguen teniendo 32 bits de longitud y los punteros tienen 64 bits de longitud. Son descritos como poseedores de un modelo de datosLP64. Otra alternativa es el modelo de datos ILP64 en el que los tres tipos de datos tiene 64 bits de longitud. No obstante, en muchos casos las modificaciones necesarias son relativamente menores y sencillas, y muchos programas bien escritos pueden ser simplemente recompilados para el nuevo entorno sin cambios. Otra alternativa es el modelo de datos LLP64 que mantiene la compatibilidad con el código de 32 bits dejando tanto int como long con 32 bits de longitud. "LL" hace referencia al tipo "long long", que tiene al menos 64 bits en todas las plataformas, entornos de 32 bits incluidos.
Muchos compiladores de 64 bits actuales usan el modelo LP64 (incluyendo Solaris, AIX, HP, Linux y los compiladores nativos de MacOS). El compilador VC++ de Microsoft usa el modelo LLP64 que es más compatible retroactivamente.
Advierta que la elección de un modelo de programación se hace al compilar, y varios modelos pueden coexistir en el mismo SO. No obstante, generalmente suele predominar el modelo de programación elegido por la API del sistema operativo como modelo primario.
Otro detalle a tener en cuenta es el modelo de datos usado para los controladores de dispositivos. Los controladores de dispositivos conforman la mayor parte del código del sistema operativo en la mayoría de los sistemas operativos modernos (aunque muchos puedan no ser cargados mientras el sistema operativo se ejecuta). Muchos controladores hacen un frecuente uso de punteros para manipular datos, y en algunos casos han de cargar punteros de un tamaño determinado en el hardware que soportan para realizar DMA. Por ejemplo, un controlador para un dispositivo PCI de 32 bits solicitando al dispositivo transferir datos usando DMA a áreas superiores de la memoria de una máquina de 64 bits podría no satisfacer las peticiones del sistema operativo de cargar datos desde el dispositivo a la memoria por encima de la barrera de los 4 gibibytes, pues los punteros para esas direcciones no cabrían en los registros DMA del dispositivo. Este problema se soluciona haciendo que el sistema operativo tenga en cuenta las restricciones de memoria del dispositivo a la hora de generar peticiones de DMA a los dispositivos, o bien usando una IOMMU.
Ventajas y desventajas
Ventajas
Se pueden usar más registros.
Manejo de más cantidad de memoria RAM.
La asignación en memoria de archivos es menos útil con arquitecturas de 32 bits, especialmente con la introducción de tecnología de grabación de DVD relativamente económica. Un archivo de 8 GB ya no es inusual y tales archivos grandes no pueden ser asignados fácilmente con arquitecturas de 32 bits. Solo se puede asignar una región del archivo en el espacio de direcciones y para acceder al archivo usando asignación de memoria, estas regiones deben ser localizadas dentro y fuera del espacio de direcciones según sea necesario. Esta es una cuestión clave, ya que la asignación de memoria es uno de los métodos más eficientes para transportar datos del disco a la memoria, cuando es correctamente implementado por el SO.
Desventajas
La principal desventaja de las arquitecturas de 64 bits es que, con respecto a las de 32 bits, los mismos datos ocupan ligeramente más espacio en memoria debido al crecimiento de los punteros y posiblemente otros tipos y al relleno para alineamiento (dependiendo del tipo de programa, algunos pueden multiplicar su tamaño). Esto incrementa los requisitos de memoria de un proceso dado y puede tener implicaciones para el uso eficiente de la caché del procesador. Mantener un modelo parcial de 32 bits es una manera de manejar esto y es en general razonablemente efectivo. De hecho, el sistema operativo de altas prestaciones Z/OS ha escogido este enfoque actualmente, requiriendo que el código de programa resida en varios espacios de direcciones de 32 bits mientras que los objetos de datos pueden (opcionalmente) residir en regiones de 64 bits.
Error de RAM en algunos S.O.
Algunos sistemas operativos reservan porciones de espacio de direcciones de procesos para uso del SO, reduciendo el espacio total de direcciones disponible para asignar memoria para programas de usuario. Por ejemplo, las DLLs de Windows XP y los componentes de usuario del SO están asignados en cada espacio de direcciones de proceso, dejando solo entre 2 y 3.75 GB (dependiendo de la configuración) de espacio de direcciones disponible, incluso si la computadora tiene 4 GB de RAM. Esta restricción solo está presente en las versiones de Windows de 32 bits, que no tiene habilitado el PAE.
