No estoy seguro de lo siguiente:
¿Hay o no hay Bennu de 64 bits? Y ¿Es idénticamente estable?
Hablando con Miriam Ruiz me dice que es necesario.
Me da a mi que no.
Para meterlo en los repositorios de Fedora, al menos que yo recuerde, era un requisito también.
Esto, junto con un backend de OpenGL y una librería oficial de red, creo que son los grandes objetivos a conseguir.
No, no hay. Splinter creo que dijo que había algún problema, o que no era un objetivo prioritario.
Lo de OpenGL era lo que seguro que daba problemas por compatibilidad de algún tipo, que habían algunas cosas que no sabía cómo hacerlas con las funciones existentes hoy día.
el problema es que los dcb (actuales o de 32) y las dlls (aunque se compilen en 64bits) no serian compatibles con la version 64bits-
o sea, serian 2 versiones diferentes, y obviamente se necesitarian nuevos tipos de datos 64bits, algunos codigos actuales dejarian de funcionar, y un largo etc de problemas.
Pregunto desde el desconocimiento: ¿No sería factible usar siempre tipos de datos de 32 bits, incluso en la versión de 64?.
Es decir, reemplazar los tipos de datos int por Sint32 en dcbr.c, dcbw.c y similares podría ayudar, ¿no?.
el problema son los identificadores de muchas funciones que en realidad son punteros, tambien estan los punteros en si, que en 64bits no son de 32.
poder se puede, hay que tocar todo, pero no serian compatibles entre si, y aquellos programas.prg que no esten preparados para 64bits no funcionaran, imagino algun sizeof de un dato que ahora es de 64 y antes era de 32, algunos datos pueden seguir siendo de 32, agregar nuevos, pero algunos retornos de modulos van a cambiar a 64, y si por ejemplo, pasamos el int a 64, los sizeof podrian fallar o comportarse diferente y asi por ejemplo, recuperar o guardar datos incorrectamente en archivos, y si dejamos el int a 32 y creamos un nuevo dato de 64bits, entonces aquellos codigos que esperen retornos de funciones en int (y no sean corregidos) fallaran...
o sea, no puede ser compatible, necesita reingenieria completa.
Mmmm... pero aparte de los sizeof y de las funciones de manejo de memoria, ¿sería totalmente compatible?
Quote from: PiXeL on December 10, 2010, 04:22:57 PM
Mmmm... pero aparte de los sizeof y de las funciones de manejo de memoria, ¿sería totalmente compatible?
sin dudarlo...
yo puedo entender lo que dice miriam de que es necesario... porque conozco eso de muchos clientes, pero mas que necesario diria deseable... y los desarrolladores deberiamos darnos cuenta que como todo en la vida, esta lo deseable y lo posible, y no siempre van de la mano...
yo digo que no es imposible, pero no sera compatible...
y virtualizar la memoria no es una opcion, ya que nos apoyamos en no virtualizar memoria para obtener el rendimiento que obtenemos.
No sé si yo llego tarde para hablar sobre esto, pero yo, desde que uso Bennu, siempre lo he estado utilizando en 64Bits, de hecho, no me dí ni cuenta de pérdidas de rendimiento, fallos en la memoria... nada, ninguna diferencia en ningún sitio.
Yo ya sabía que BennuGD solo esataba hecho para 32Bits, pero en mi Ubuntu instalo constantemente aplicaciones de 32Bits, siendo 64Bits...
Incluso hay paquetes que pone que son de 64bits, pero son de 32 bits, gracias a ia32libs, un paquete fácilmente descargable en los repos de Ubuntu que funcionan muy bien.
Lo primero que hay que hacer es instalar dicho paquete, luego descargas el script de Linux y lo abres como Sudo...
Además, te lo instala automaticamente en la carpeta lib32 en /usr/... Es decir, que funciona bien.
Sí, el paquete de 32 bits en 64 debería funcionar bien. Lo que no va bien es coger bennu y recompilarlo como binario de 64bits. Algunas cosas sí que funcionan, pero otras explotan sin más.
¿Y para qué compilarlo para 64bits? Si funciona perfectamente con los binarios de 32bits...
Porque es un requisito necesario para que se incluya en los repositorios oficiales de Linux.
Aunque aun no sé exactamente qué problema hay de recompilarlo en 64 bits, manteniendo los tipos de datos actuales con los tamaños de ahora, y añadir un nuevo tipo de 64 bits, una especie de "double int" (igual que a los INT de ahora al principio se les llamó DWORD). ¿Que las funciones deben devolver un dato? Que sigan devolviendo ints de 32 bits.
Vamos, yo lo digo para no tener que reescribir y sin conocer los pormenores de la conversión a 64 bits. Está bien tratar de pasar todo a 64 bits, pues está pasando lo mismo que con el salto a 32 (periodo que no viví), pero de ahí a forzar que programas más antiguos que los procesadores de 64 deban ser de 64 me parece un poco pasarse. Es como pedir que obligatoriamente todos los programas acepten el multinúcleo, aunque sea el bloc de notas.
Quote from: Drumpi on December 15, 2010, 02:04:30 PM
Porque es un requisito necesario para que se incluya en los repositorios oficiales de Linux.
Aunque aun no sé exactamente qué problema hay de recompilarlo en 64 bits, manteniendo los tipos de datos actuales con los tamaños de ahora, y añadir un nuevo tipo de 64 bits, una especie de "double int" (igual que a los INT de ahora al principio se les llamó DWORD). ¿Que las funciones deben devolver un dato? Que sigan devolviendo ints de 32 bits.
Vamos, yo lo digo para no tener que reescribir y sin conocer los pormenores de la conversión a 64 bits. Está bien tratar de pasar todo a 64 bits, pues está pasando lo mismo que con el salto a 32 (periodo que no viví), pero de ahí a forzar que programas más antiguos que los procesadores de 64 deban ser de 64 me parece un poco pasarse. Es como pedir que obligatoriamente todos los programas acepten el multinúcleo, aunque sea el bloc de notas.
realmente no creo que sea requisito necesario, porque hay productos de 32 que no estan en 64 y estan en los repositorios oficiales.
los problemas ya se comentaron, en este hilo y en muchos otros, por favor, pegale una releida.