duda sobre 64bits
Mauricio José Adonis Carrasco
mike.alfa.2007 en gmail.com
Jue Jun 12 19:50:39 BST 2008
El jue, 12-06-2008 a las 10:28 -0400, aliciaorizondo en infomed.sld.cu
escribió:
>
> tengo una duda el ubuntu o kubuntu de 64bits funcionan mas rapido o mas lento,y si en
> estos sistemas de 64 bits pueden correr las aplicaciones comunes que tenemos en el
> repositorio ,es decir si pueden correr las aplicaciones de 32 bits en estos sistemas de
> 64bits
> gracias de antemano un saludo rhandy
>
> ------------------------------
> Infomed - Red de Salud de Cuba
> http://www.sld.cu/
>
>
Hola Alicia, como info general te sugiero que leas este artículo de la
wiki...
http://es.wikipedia.org/wiki/64_bits
Si tienes algún problema para acceder al contenido, te lo pego aquí
mismo
------------------------------------------------------------------------
64 bits
De Wikipedia, la enciclopedia libre
Saltar a navegación, búsqueda
En arquitectura de ordenadores, 64 bits es un adjetivo usado para
describir enteros, direcciones de memoria u otras unidades de datos que
comprenden hasta 64 bits (8 octetos) de ancho, o para referirse a una
arquitectura de CPU y ALU basadas en registros, bus de direcciones o bus
de datos de ese ancho.
Los microprocesadores de 64 bits han existido en los superordenadores
desde 1960 y en servidores y estaciones de trabajo basadas en RISC desde
mediados de los años 1990. En 2003 empezaron a ser introducidos
masivamente en los ordenadores personales (previamente de 32 bits) con
las arquitecturas x86-64 y los procesadores PowerPC G5.
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 los ordenadores de 64 bits tiene integrados registros
que son de 64 bits, que permite soportar (interna y externamente) datos
de 64 bits.
Tabla de contenidos
* 1 Implicaciones de arquitectura
* 2 Limitaciones de memoria
* 3 Cronología del procesador de 64 bits
* 4 32 bits contra 64 bits
* 5 Pros y contras
* 5.1 Disponibilidad del Software
* 6 Modelos de datos de 64 bits
* 7 Arquitecturas de microprocesador de 64 bits actuales
* 8 Más allá de los 64 bits
* 9 Imágenes
* 10 Véase también
* 11 Referencias
* 12 Enlaces externos
Implicaciones de arquitectura
Los registros en un procesador se dividen generalmente en tres grupos:
enteros, coma flotante y otros. En todos los procesadores de propósito
general, sólo 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 cualquier
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.
Limitaciones de memoria
Muchas CPUs están actualmente (en 2008) 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 el ordenador
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) el miniordenador 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 superordenadores, estaciones de trabajo de grandes
prestaciones y servidores. Las computadoras de 64 bits se han ido
moviendo hacia el ordenador personal, con algunos modelos de las líneas
Macintosh de Apple Computer cambiando a procesadores PowerPC 970
(llamados "G5" por Apple) en 2003 y a procesadores EM64T de 64 bits en
2006, y con procesadores x86-64 llegando a ser comunes en PCs 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 PCs 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 32 gigabytes de
memoria, 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.[1]
Cronología del procesador de 64 bits [editar]
* 1961: IBM lanzó el superordenador IBM 7030 Stretch. Este
utilizaba palabras de 64 bits e instrucciones de 32 ó 64 bits.
* 1974: Control Data Corporation lanzó el superordenador 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ó el primer ordenador Cray-1. Este
estaba basado en una arquitectura de palabras de 64 bits, que
sentó las bases para los posteriores superordenadores
vectoriales de Cray.
* 1983: Elxsi lanzó el minisuperordenador 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 RISC MIPS, 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
operativo IRIX hasta la versión IRIX 6.2 en 1996.
* 1992: Digital Equipment Corporation (DEC) introdujo el Alpha con
una arquitectura pura de 64 bits que nació del proyecto PRISM.
* 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.
* 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
distribuciones Linux 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.
Freescane 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 mm2. 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 Xeon EM64T de 64 bits en su nuevo Mac Pro
y sus ordenadores Intel Xserve, y posteriormente actualizó el
iMac, el MacBook y el MacBook Pro con procesadores EM64T Intel
Core 2 Duo.
32 bits contra 64 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).
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.
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 sólo 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.
Debería notarse que la velocidad no es el único factor a 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.
Pros y contras
Un error común es, que las arquitecturas de 64 bits no son mejores que
las de 32 bits a menos que el ordenador tenga más de 4 GB de memoria.
Esto no es completamente cierto:
* Algunos sistemas operativos reservan porciones de espacio de
direcciones de procesos para uso del SO, reduciendo el espacio
total de direcciones disponible para mapear memoria para
programas de usuario. Por ejemplo, las DLLs de Windows XP y los
componentes de usuario del SO están mapeados en cada espacio de
direcciones de proceso, dejando sólo entre 2 y 3.8 GB
(dependiendo de la configuración) de espacio de direcciones
disponible, incluso si el ordenador tiene 4 GB de RAM. Esta
restricción no está presente en el Windows de 64 bits.
* El mapeado 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 barata. Un archivo
de 4 GB ya no es inusual y tales archivos grandes no pueden ser
mapeados fácilmente con arquitecturas de 32 bits; sólo se puede
mapear una región del archivo en el espacio de direcciones y
para acceder al archivo usando mapeado de memoria, estas
regiones tendrán que mapearse dentro y fuera del espacio de
direcciones según sea necesario. Esta es una cuestión clave, ya
que el mapeado 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.
La principal desventaja de las arquitecturas de 64 bits es que, con
respecto a las arquitecturas 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).
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.
Actualmente, muchos programas comerciales están construidos como código
de 32 bits, no de 64 bits, así que no pueden obtener ventajas de los
grandes espacios de direcciones de 64 bits o de registros de 64 bits más
anchos y las rutas de datos en procesadores de 64 bits o, en
procesadores x86, de los registros adicionales en el modo de 64 bits.
Sin embargo, los usuarios de sistemas operativos libres o de código
abierto han podido utilizar entornos exclusivos de 64 bits durante años.
No todas las aplicaciones necesitan un gran espacio de direcciones o
manipular elementos de 64 bits, así que no se beneficiarían de los
grandes espacios de direcciones o de los registros más anchos y las
rutas de datos; el principal beneficio para las aplicaciones de 64 bits
que no se beneficiarían de nada de esto sería que las versiones x86
podrían usar más registros.
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 driver (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 desde
las fuentes para trabajar en un entrono de 64 bits en sistemas
operativos como Linux. Todo lo que se necesitaría en este caso es un
compilador (normalmente GCC) para la máquina de 64 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. Los
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 sólo devuelve el tamaño en carácteres, 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 (sólo 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 datos LP64. 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.
Arquitecturas de microprocesador de 64 bits actuales
Las arquitecturas de microprocesador de 64 bits (a fecha de 2006)
comprenden:
* La arquitectura DEC Alpha (véase la cronología de Digital Alpha)
* La arquitectura IA-64 de Intel (usada en las CPUs Itanium de
Intel)
* La arquitectura AMD64 de AMD (previamente conocida como x86-64),
una versión de 64 bits de la arquitectura x86 (usada en las CPUs
Athlon 64, Opteron, Sempron y Turion 64).
* 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 llaman a
este conjunto de instrucciones "x64".
* La arquitectura SPARC (de 64 bits desde SPARC V9)
* La arquitectura UltraSPARC de Sun
* La arquitectura SPARC64 de Fujitsu
* La arquitectura POWER de IBM (de 64 bits desde POWER3 y las
variantes RS64)
* La arquitectura PowerPC de IBM/Motorola (el PowerPC 620 de 64
bits y las variantes PowerPC 970)
* La arquitectura z/Architecture de IBM, usada por los mainframes
zSeries y System z9, una versión de 64 bits de la arquitectura
ESA/390
* 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.
Más allá de los 64 bits [editar]
A fecha de 2007, las palabras de 64 bits parecen ser suficientes para la
mayoría de usos prácticos. Aún 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 (por
ejemplo de 128 bits).
Saludos.
--
Mauricio José Adonis Carrasco <mike.alfa.2007 en gmail.com>
Más información sobre la lista de distribución ubuntu-es