Duda con enmsablador y Wiz

[^OMAP-Cranck^]

Hola amigos. He estado mirando algunos códigos fuente de emuladores y programas para Wiz y en algunos casos me he topado con archivos que tienen sentencias de ensamblador para la Wiz supongo. Mi pregunta es: ¿es necesario configurar de alguna forma especial el sdk o el toolchain para poder compilar estos proyectos que hacen uso de de estos archivos?

[LTK666]

No cres preciso tocar nada en el sdk o toolchain, lo que si ha de estar indicado en el makefile que compile esos archivos, estás mirando algún ejemplo concreto?

[^OMAP-Cranck^]

Estaba mirando el gpsp de wiz que parece ser que usa algo de ensamblador, pero como digo no tengo ni idea de como hace para enlazarlo todo. Esa es la duda que tengo.

< - >

lo que si ha de estar indicado en el makefile que compile esos archivos,

¿es decir que existen algunas instrucciones especificas en el makefile para poder enlazar el codigo en ensamblador con codigo en C?

[juanvvc]

En el makefile no hay que hacer nada especial, porque si el compilador encuentra un archivo .c compila como si fuese C, y si encuentra un .s compila como si fuese ensamblador.

Sí que hay que escribir el inicio del código ensamblador de una forma especial que ya no recuerdo, para que las funciones C pueda llamar a ese código. Como el compilador C/ensamblador "es de la misma casa", no es demasiado complejo.

El código de gpsp es un buen sitio para aprender, yo aprendí a hacerlo mirándolo :) Creo recordar que hay un archivo memcpy.S "sencillo de entender", que hace lo mismo que el memcpy estándar pero con alguna mejora de velocidad en Gp2x (no sé si Wiz lo heredó), y otro archivo en ensamblador para el escalado de pantalla, y este es mucho más complejo.

[jcom]

¿es decir que existen algunas instrucciones especificas en el makefile para poder enlazar el codigo en ensamblador con codigo en C?

Normalmente los compiladores suelen tener una macro para poder insertar código en ensamblador en medio del código C. En el caso de gcc es asm, por lo que he visto haciendo una búsqueda rápida en google.

En el makefile no tiene por qué haber instrucciones específicas para los ficheros con código ensamblador, gcc los procesa de una manera similar a la que usa con ficheros con código C.

Pero bueno, a veces depende. Hay programas que emplean compiladores de ensamblador que son independientes de gcc (nasm, por ejemplo). En este caso el código ensamblador esta en uno o varios ficheros aparte que al ser procesados por nasm generan ficheros objeto (los .o) en el formato que usa el gcc. Estos .o provenientes del código ensamblador se enlazan sin más problema con el resto de ficheros objeto a la hora de crear el ejecutable. Aquí sí que habría instrucciones específicas en el Makefile.

[^OMAP-Cranck^]

En el makefile no hay que hacer nada especial, porque si el compilador encuentra un archivo .c compila como si fuese C, y si encuentra un .s compila como si fuese ensamblador.

El código de gpsp es un buen sitio para aprender, yo aprendí a hacerlo mirándolo :) Creo recordar que hay un archivo memcpy.S "sencillo de entender", que hace lo mismo que el memcpy estándar pero con alguna mejora de velocidad en Gp2x (no sé si Wiz lo heredó), y otro archivo en ensamblador para el escalado de pantalla, y este es mucho más complejo.


Si, ese es el que he estado mirando. Entonces entiendo que los ficheros .s los he de añadir al proyecto junto con los .c . Que me recomendais que use ¿el sdk oficial bajo windows o el no oficial?

Deberia funcionar sin problemas con los dos ?no¿

[LTK666]

Pero bueno, a veces depende. Hay programas que emplean compiladores de ensamblador que son independientes de gcc (nasm, por ejemplo). En este caso el código ensamblador esta en uno o varios ficheros aparte que al ser procesados por nasm generan ficheros objeto (los .o) en el formato que usa el gcc. Estos .o provenientes del código ensamblador se enlazan sin más problema con el resto de ficheros objeto a la hora de crear el ejecutable. Aquí sí que habría instrucciones específicas en el Makefile.

A esto es a lo que me refería con las modificaciones en el makefile, a compilar .s con otros distintos a gcc