|
|
Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.
Mensajes - enterprogramacion
Páginas: [1]
1
« en: Domingo 25 de Enero de 2009, 06:47 »
jejejejeje, hay cada moderador, no tenes mucho idea de un foro, posta te dijo, sin ofender,,,... pero el ADMINISTRADOR DEL FORO, cuando lea el mensaje va a razonar que lo que he dicho es verdad, les puede gustar o no, pero esa firma necesita ser limitada en el ACP, para que no genere dificultad en la lectura de los foros, esa imagen es muy grande, genera trafico (perdida), y espacio en los mensajes. tambien 2 cosas, el MOD que utiliza en foro (Last Posts Titles 1.0.0a), deja el foro con muchos espacios en el comienzo, .. y otra cosas, ya podrian actualizar el foro a 3.0.4. saludos....  (jejeje)
2
« en: Domingo 25 de Enero de 2009, 00:03 »
3
« en: Sábado 24 de Enero de 2009, 18:18 »
¿Y mirar la fecha de los hilos antes de responder? ¿No te parece una buena practica? no tiene nada que ver. espero que modifiquen eso, porque es un HORROR la firma, ocupa la mitad de todo el foro.
4
« en: Sábado 24 de Enero de 2009, 05:51 »
soy programador de vb, contame donde pones ese codigo ? en que parte ? (componente, accion, etc...)..
salu2.
pd: trata de pegar un screenshot del ejercicio que estas haciendo, subi la foro en postimage.org y ponela aca en el foro.
salu2.
5
« en: Sábado 24 de Enero de 2009, 05:50 »
yo uso dattatec.com, pago 54 pesos anuales, y tengo 3 gb de espacio. etc... etc...
es muy bueno por el precio, el servicio es mediocre, pero para la pagina que yo uso, es suficientemente bueno.....
saludos.
tambien esta uno que se llama hosting rentable, tambien es bueno.
6
« en: Sábado 24 de Enero de 2009, 05:48 »
les escribo para comentarles que el usuario " Bicholey ", usa como firma una imagen que desproporciona el foro, osea, la imagen es muy muy grande, les recomiendo que le escriban a dicho usuario pidiendo que rapidamente modifique su tamaño de la imagen de la firma, o bien, en su ACP del foro, ponerle limites a las imagenes de las firmas..
saludos.
7
« en: Sábado 24 de Enero de 2009, 05:46 »
Amigo, es re-facil solucionarlo, con el software " partition magic 8.0 español ", podes en forma grafica administrar tus particiones, (divisiones, union, fat, ntfs, etc.. etc.. ).
con eso, lo vas a solucionar, porque cuando ingresar al partition magic, en forma grafica te daras cuenta las particiones que no estas utilizando, y con el click secundario del mouse, tenes todas las opciones..
fijate.
saludos.
8
« en: Sábado 24 de Enero de 2009, 05:44 »
dos cosas:
1- tenes que configurar en la BIOS del pc, que comienze el boteo con CD-ROM y despues con IDE-0.
2- otro caso, que tengas una version de xp mal copiada, que no incluya boteo ( cosa que no creo, te aseguro que es de bios ).
salu2.
9
« en: Sábado 24 de Enero de 2009, 05:42 »
te puedo ayudar, pero tenes que explicar mejor, que pass ?, que lenguaje ?... contame mas.
salu2.
10
« en: Sábado 24 de Enero de 2009, 05:34 »
Fuente: Wikipedia.
64 bits.
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.
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 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.
Limitaciones de memoria [editar]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 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 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. Según Apple la nueva version de su sistema operativo teóricamente soporta 16 Terobytes 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 [editar]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 [editar]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 [editar]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 entorno 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 [editar]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 [editar]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. 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 (por ejemplo de 128 bits).
11
« en: Sábado 24 de Enero de 2009, 05:26 »
la mejor forma de hacer backup en forma instantanea es usando sistema RAID.
¿Qué es RAID?
El término RAID es un acrónimo del inglés "Redundant Array of Independent Disks". Significa matriz redundante de discos independientes. RAID es un método de combinación de varios discos duros para formar una única unidad lógica en la que se almacenan los datos de forma redundante. Ofrece mayor tolerancia a fallos y más altos niveles de rendimiento que un sólo disco duro o un grupo de discos duros independientes.
Una matriz consta de dos o más discos duros que ante el sistema principal funcionan como un único dispositivo. Un RAID, para el sistema operativo, aparenta ser un sólo disco duro lógico (LUN). Los datos se desglosan en fragmentos que se escriben en varias unidades de forma simultánea. En este método, la información se reparte entre varios discos, usando técnicas como el entrelazado de bloques (RAID nivel 0) o la duplicación de discos (RAID nivel 1) para proporcionar redundancia, reducir el tiempo de acceso, y/o obtener mayor ancho de banda para leer y/o escribir, así como la posibilidad de recuperar un sistema tras la avería de uno de los discos.
La tecnología RAID protege los datos contra el fallo de una unidad de disco duro. Si se produce un fallo, RAID mantiene el servidor activo y en funcionamiento hasta que se sustituya la unidad defectuosa.
La tecnología RAID se utiliza también con mucha frecuencia para mejorar el rendimiento de servidores y estaciones de trabajo. Estos dos objetivos, protección de datos y mejora del rendimiento, no se excluyen entre sí.
RAID ofrece varias opciones, llamadas niveles RAID, cada una de las cuales proporciona un equilibrio distinto entre tolerancia a fallos, rendimiento y coste.
Todos los sistemas RAID suponen la pérdida de parte de la capacidad de almacenamiento de los discos, para conseguir la redundancia o almacenar los datos de paridad.
Los sistemas RAID profesionales deben incluir los elementos críticos por duplicado: fuentes de alimentación y ventiladores redundantes y Hot Swap. De poco sirve disponer de un sistema tolerante al fallo de un disco si después falla por ejemplo una fuente de alimentación que provoca la caída del sistema.
También cada vez es más recomendable, sobre todo en instalaciones de cluster, configuraciones de dos controladoras redundantes y Hot Swap, de manera que en el caso de fallo de una de ellas se puede proceder a su sustitución sin tener que detener el funcionamiento del sistema. Además, esta configuración con controladoras redundantes nos permite conectar el sistema RAID a diferentes servidores simultáneamente.
12
« en: Sábado 24 de Enero de 2009, 05:20 »
muy bueno.
gracias.
13
« en: Miércoles 21 de Enero de 2009, 05:06 »
En resumen, dos pequeñas cuestiones:
1- Donde puedo pedir (por internet) un lector para cambiarsela a la play2. Es que sale mas barato eso que una nueva
2- ¿Como lo cambio?. Soy nuevo en esto y no quiero meter la pata.
Gracias por la ayuda fijate en youtube, hay videostutoriales paso x paso de como cambiar, reparar y mantenimiento de playstation. suerte. es muy facil. saludos.
Páginas: [1]
|
|
|
Mostrar Mensajes
