Hace unos días decidí cambiar el sistema operativo a Ubuntu de 64 bits. A fin de cuentas es el futuro, y cualquier día lo necesitaré por cuestiones de memoria, así que mejor ir comenzando ahora. Al principio pensaba que iba a tener problemas con algún programa en concreto, pero la verdad es que hasta ahora todo está funcionando como la seda:

• MPlayer y Mencoder funcionan perfectamente y reproducen todos los formatos que necesito (entre ellos H.264, DivX, WMV y RealMedia); y ni siquiera he necesitado instalar los plugins privativos para que me funcionen incluso los vídeos en formato WMV9 (que utiliza VC-1).
• Eclipse funciona perfectamente con la máquina virtual de Java de 64 bits, aunque tuve que borrar la carpeta .eclipse de mi directorio personal y reinstalar los plugins para lenguaje C y Python.
• Y tampoco tengo problema alguno con Flash de 64 bits, aunque sea aún una prerelease y no una versión estable.

Un detalle que me preocupaba mucho es ¿cuan problemático es portar código C a 64 bits? En general debería funcionar, salvo si el tamaño de algún tipo fundamental cambia a 64 bits y en el código asumimos que es de 32 bits. Y de hecho había algunas posibilidades de que ocurriese, pues hay tres posibles modelos para C en 64 bits: LP64, ILP64 y LLP64. En el primero, que es el que utiliza Linux/GCC o MacOS X, int es de 32 bits, mientras que long int es de 64 bits. En el segundo, en cambio, los dos tipos miden 64 bits. En el último caso, el más compatible (y además utilizado por el compilador VirtualC++ de Microsoft), miden todos 32 bits, siendo long long int la única manera de conseguir un tipo de 64 bits. ¿Cual es mejor? Bajo mi punto de vista, LP64, porque permite fácilmente mantener total compatibilidad hacia atrás si se escribe el código con una pizca de cuidado, además de permitir, con el mismo código, acceder a toda la memoria disponible mediante aritmética de punteros, tanto en 32 como en 64 bits. Para conseguir todo esto, en concreto, hay que asegurarse de utilizar long int para aquellas variables que se utilicen en aritmética de punteros (porque, de esa forma, siempre tendrán el mismo tamaño que un puntero y se podrá direccionar toda la memoria sin problemas), así como para aquellas que no importe si son de 32 o 64 bits, utilizar int para aquellas que tengan que ser forzosamente de 32 bits, o cuando se quiera ahorrar en tamaño, y long long int para aquellas que tengan que ser necesariamente de 64 bits.

Mi miedo venía por FBZX. Sin embargo, tras probarlo, funcionó correctamente… aunque hay que decir que de milagro, porque hay un punto en que sí utilicé un long int en lugar de int a secas: justo en la función que pinta cada pixel, cuando estamos en un modo de 24 o 32 bits por pixel. Pese a todo, gracias a que la arquitectura Intel es little endian, el código funciona (cosa que no haría si fuese big endian). Es un detalle que corregiré en la siguiente versión, para la que sacaré paquete .deb tanto en 32 como en 64 bits.

Migrando a 64 bits por A cuadros está licenciado bajo una Licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional.