Uno de los temas que más se comenta cuando se habla de procesadores aparte de sus núcleos y la frecuencia a la que funciona, es el tema de los bits. Este es otro de esos temas en los que creo que hay mucha confusión ya que para algunas personas esto de los bits, gigas y tal les puede resultar un poco abstracto. Las cosas se ponen peor cuando se empiezan a relacionar datos como los bits del procesador con la memoria RAM con la que puede trabajar, la memoria a la que pueden acceder los procesos y demás.
Para no alargarme demasiado en la introducción, voy a explicar un poco por encima qué es esto de los bits de una forma más general. Los bits de un procesador pueden indicar principalmente dos aspectos: El tamaño de los datos que es capaz de manejar y la cantidad de memoria RAM con la que es capaz de trabajar. No tienen por qué ser los dos aspectos los que estén ligados a ese mágico número de los bits de un procesador. De hecho lo normal es que cuando se dice que un procesador es de un número X de bits, solo se haga referencia al tamaño de los datos que maneja y no a la cantidad de la memoria RAM con la que es capaz de trabajar.
Supongamos que trabajamos con un procesador teórico de 32 bits, el cual usa esa cifra tanto para el tamaño de los datos que maneja como para la cantidad de memoria RAM con la que es capaz de trabajar. Esto nos dice que los «trozos» de información con los que trabaja el procesador pueden ser de hasta 32 bits (o 4 octetos, que hay a gente a la que le gusta más manejar bytes) y que la máxima cantidad de memoria con la que puede trabajar es de 2^32 o dicho de una forma más visual, 4 gigas.
En el párrafo anterior he puesto de ejemplo un procesador teórico. Esto es así porque en la realidad la cosa funciona un poco diferente. No es el procesador como tal el que maneja la memoria RAM. Al tener el procesador que manejar muchos procesos, hace años se llegó a la conclusión que era una buena idea abstraer en cierta medida al procesador de lo que pasa realmente en la memoria RAM. Al final da como resultado que el procesador trabaja con direcciones virtuales de memoria (el tema de la memoria virtual da para otro artículo, porque es bastante complejo) y que las direcciones reales de memoria se manejarían fuera de las partes esenciales del procesador. Con esto se consigue que el procesador se despreocupe de la cantidad de memoria RAM que tiene, de si los cachos del proceso que está ejecutando que se encuentran (o no) cargados en la RAM, de la velocidad de ésta…
El módulo intermedio que establece la relación entre las direcciones virtuales que maneja el procesador y las direcciones reales de la memoria RAM es el conocido como MMU o unidad de manejo de memoria.Esta unidad suele tener el apoyo de una memoria caché bastante famosa llamada TLB en donde guarda la correspondencia entre direcciones físicas y direcciones virtuales de las últimas páginas de los procesos con los que ha estado trabajando el procesador.
El número de bits de la MMU es independiente de los bits que marcan la longitud de los datos con los que trabaja un procesador. Puede darse el caso lógicamente de que ambos sean por ejemplo de 32 bits, como en el caso teórico que he puesto antes pero no suele ser lo normal. ¿Qué suele ser lo normal entonces? Pues veamos:
En los procesadores x86 (los de intel y AMD, para que nos entendamos) de 32 bits desde hace unos 20 años la MMU que se incluye es de 36 bits. A esto se le conoce como PAE o Physical Adress Extension. Esto nos da como resultado que estos procesadores pueden trabajar con cantidades de hasta 64 gigas de ram. ¿Por qué entonces en windows la limitación de RAM estaba en 4 gigas? Pues porque a microsoft le salió de las narices, ni más ni menos. Tanto linux como macos en sus versiones de 32 bits pueden llegar a esos 64 gigas de ram.
En los procesadores ARM de 32 bits medianamente modernos (cortex a7, cortex a12, cortex a15 y krait principalmente) se metió una MMU de 40 bits. A este modo los de ARM lo llamaron LPAE, siendo la L de large para hacer referencia que su modo permitía trabajar con más memoria RAM que el x86. Estos procesadores por lo tanto pueden llegar a trabajar con hasta 2^40 o dicho de otro modo, 1 tera de ram.
En los procesadores de 64 bits que se están viendo hoy en día (tanto ARM como x86_64) se ha considerado que meter una MMU de 64 bits era un desperdicio hoy en día ya que faltan muchísimos años hasta que hagan falta manejar cantidades de memoria RAM de exabytes. La MMU que nos encontramos es de 48 bits, lo que nos dice que estos procesadores llegan hasta los 256 teras en vez de los teóricos 16 exabytes si simplemente nos hubiésemos quedado con el 2^64 y no hubiésemos mirado el funcionamiento real del procesador.
¿Tiene alguna limitación que el procesador trabaje con unas longitudes de datos distintas a lo que marca la MMU? Pues las hay, aunque con solución. El procesador internamente sigue trabajando con direcciones virtuales que vienen marcadas por los bits del procesador como tal y no por la MMU. Aunque la MMU sea de 36 o 40 bits, si el procesador es de 32 bits el espacio de direcciones para un proceso concreto sigue estando limitado a 4 gigas. En caso de que un proceso necesitase más de esos 4 gigas, teóricamente no podría tener acceso a ello. En la práctica hay métodos como el Adress Windowing Extension para windows o la función mmap para linux que sí permiten esto.
Así que cuidado a partir de ahora con esos sitios en los que leas que se salta de 32 a 64 bits «porque 4 gigas nosequé y nosecuantos» porque al menos en lo que a memoria RAM respecta, los procesadores actuales de 32 bits son totalmente capaces de manejar mucho más de 4 gigas de ram.
Wooow.. en verdad muy interesante, aún me quedan pocas dudas en lo que se refiere a terminología, pero en verdad muy completo tu post, en verdad gracias.
Si tienes alguna duda no tengas miedo en plantearla aquí. Igual con un poco de suerte te puedo ayudar.
Gracias por compartir esta inf tan importante.
Mi duda es: dices que para los x86 Windows se likita a 32 bits de ram.? Me puedes explocar mas.. en mi caso tengo un window .server 2008 enterprise. Gracias
Bueno, realmente donde microsoft ha limitado la ram a 4 gigas es más bien en los windows de 32 bits de escritorio. Hay algunas versiones de windows (las starter edition) que incluso vienen capadas a 2 gigas de ram en vez de a 4 gigas.
Esto se cree que es por un juego que ha ido haciendo microsoft en el tema de las licencias de sus sistemas operativos. Te dejo aquí un enlace de una persona que en su día lo estudió en profundidad porque creo que te va a resultar interesante:
http://www.geoffchappell.com/notes/windows/license/memory.htm
La propia microsoft tiene algunos windows de 32 bits en su versión para servidores, como creo que es el caso del windows server 2008 que me comentas, que también pueden trabajar con 64 gigas de ram. Esto es algo que se me ha olvidado comentar en mi artículo.
Hola pepone, muy interesante tu post estoy haciendo un trabajo de la escuela y este es el lugar mas completo que encontré. y quería hacerte una pregunta..Internamente, ¿qué tipo de direcciones de memoria maneja la CPU o procesador?.
Hola pepone, muy interesante tu post estoy haciendo un trabajo de la escuela y este es el lugar mas completo que encontré. y quería hacerte una pregunta..Internamente, ¿qué tipo de direcciones de memoria maneja la CPU o procesador?.
La CPU maneja direcciones virtuales de memoria, que son traducidas a direcciones reales por la MMU.
La CPU trabaja únicamente con direcciones virtuales por cuestiones de abstracción de procesos y para que tanto el diseño del procesador como el diseño a nivel de programación y ejecución de los procesos no tengan que depender de la cantidad de memoria RAM física que haya en cada momento, o en cada configuración de hardware, o de la zona de memoria RAM en donde el sistema operativo ha considerado cargar ese proceso para su ejecución.
Ten en cuenta que si manejase direcciones reales de memoria te encontrarías con una limitación importante en la cantidad de memoria RAM que habría disponible para cada proceso en ejecución. Con la memoria virtual en un procesador de 32 bits se le podría dar 4 gigas de ram a cada proceso (esos 4 gigas por proceso se dividen en páginas de un tamaño mucho menor que se irían cargando y descargando de la memoria RAM según hiciese falta en su ejecución para favorecer la capacidad multiproceso del sistema).
Si no hubiese una gestión de la memoria virtual en un procesador teórico de 32 bits tanto de direcciones como de MMU al estilo del ejemplo que puse en el artículo, resulta que estarías limitado a 4 gigas de RAM para todos los procesos en vez de para cada uno y a la vez tendrías una limitación de 4 gigas de ram máximos porque no tendrías una MMU que permitiese ese manejo de cantidades de memoria RAM independientes de los bits del procesador ni tendrías una traducción entre memoria virtual y real que permitiese esas ventajas en la programación y ejecución de procesos que he comentado antes.
En este artículo de la wikipedia ( http://es.wikipedia.org/wiki/Memoria_virtual )creo que podrás encontrar un punto de partida si quieres continuar informándote sobre la memoria virtual, la MMU, la caché TLB que acompaña a la MMU, el manejo de las páginas en la memoria RAM que hace un sistema operativo y otros aspectos derivados de todo esto.
Hola,…. te cuento que sigo con el trabajo y acá tengo otra pregunta que no alcanzo a comprender mucho y es sobre la asignación de direcciones, ¿Qué es el comúnmente llamado «registro frontera»?.
El registro frontera es un registro donde se guarda la dirección de memoria principal que delimita hasta qué dirección de memoria hay partes esenciales del sistema operativo cargadas y a partir de la cual otros procesos un poco más secundarios como los del usuario pueden cargarse en memoria principal.
Así no hay riesgo de que un proceso de usuario pise parte de la memoria ocupada por el sistema operativo.
muchas gracias por contestar, pero no lo entiendo ja es medio confuso lo que pones en la parte que pones (!!delimita hasta qué dirección de memoria hay partes esenciales del sistema)
Voy a intentar ponerte un ejemplo sencillo para ver si así se ve mejor.
Imagina que tienes un sistema con una memoria principal de 20 posiciones. Entonces, decides arrancar ese sistema.
Lo primero que se carga en esa memoria es el sistema operativo que en este caso, pongamos que quiere ocupar las 5 primeras posiciones de memoria. Esto quiere decir que las direcciones de memoria de la 0 a la 4 apuntarían a partes del sistema operativo.
El propio sistema operativo entonces modifica el valor del registro frontera y le mete la dirección de memoria 5 que apunta a la posición de memoria 6 a partir de la cual está todo libre para cargar otros procesos.
Este registro frontera se utiliza como mecanismo de seguridad ya que se utiliza como un operando a la hora de calcular las posiciones de memoria disponibles para el usuario. Por ejemplo, en ese mismo sistema en donde ya tenemos cargado el sistema operativo que he comentado y el registro frontera con el valor que he puesto antes quiere cargarse un proceso que va a ocupar 4 posiciones de memoria. Lógicamente, no sería bueno que se dejase a ese proceso cargarse en las posiciones de memoria que están ya ocupadas por el sistema operativo. Pero el proceso tampoco tiene por qué saber de antemano cuántas posiciones está ocupando el sistema operativo (con tantos sistemas operativos distintos sería una locura programar un proceso que tuviese que ser consciente de eso).
¿Qué pasa entonces?
El registro frontera apuntaba a la dirección de memoria 5. El proceso en su espacio virtual de memoria quiere ocupar sus primeras 4 posiciones de memoria. Dentro de su espacio virtual de memoria por tanto, el proceso quiere trabajar con sus direcciones 0, 1, 2 y 3.
Registro frontera + direcciones del proceso de su espacio virtual = dirección real de memoria principal.
En este caso:
5 + 0 = 5 OK
5 + 1 = 6 OK
5 + 2 = 7 OK
5 + 3 = 8 OK
El proceso se ha cargado en posiciones libres de memoria y seguras para el sistema operativo sin que el propio proceso haya tenido que hacer nada.
Como ves, esto es transparente para el proceso pero además es un aspecto bastante interesante de seguridad en el manejo de la memoria ram.
Buenisimo, amigo mil gracias por contestar me sirvio de mucho tus respuestas abrazo.
HOLA AMIGO COMO ESTAS?? te hago una pregunta,,, para qué se utiliza el bit de paridad en la transmisión de datos?
Es un método de detección de errores. Si durante la transmisión de datos se modifica el valor de algún bit, podrás saberlo con el bit de paridad.
hola gente! quisiera saber si en un disco de 80g que tiene formato fat32 el tamaño del cluster puede se de 2 kb y de ser así si esto es conveniente?
muchas gracias
Hola sabaxis, no importa el tamaño del disco, por lo que entiendo si se puede usar en fat 32 y en fat 16, hasta un tamaño maximo de 32 kb pero no se cuan combeniente es !!