Escrito originalmente por veguepic
Saludos:
Se podria hacer lo contrario?
Me explico, si tengo un programa en C y genero el HEX respectivo, luego lo cargo en el IC-Prog y veo el ASM y luego lo grabo es valido? 
Claro, al tener el .hex ya tienes los datos a grabar en el pic, no importa si lo generaste con el compilador de assembly, el del C , de basic o de tantos otros que andan dando vuelta por ahí.
Escrito originalmente por veguepic
Segun tengo entendido para un mismo programa escrito en C ocupa el doble o triple de espacio que uno escrito en ASM, podrian explicar porque.
Porque? la pregunta tiene una respuesta que puede ser muy corta o muy larga, pero básicamente te explico que es porque en el C todo se hace mas "genérico" y al pasarse al assembly hay que adaptarse al microcontrolador en cuestión.
Además todo la cuestión de paso de parámetros a funciones y el manejo de algo que se llama "pila" hace que un código en C sea más largo que uno que haga lo mismo pero en assembly.
Te doy un ejemplo.
En C, tu declaras variables y no importa donde estén alojadas, imaginemos que la variable a está en el RAM BANK #0 (pagina 0 de memoria de datos) y la b en el Ram Bank #2 .
si haces
Codigo:
a = a + 2 + b;
el Compilador deberá hacer los cambios de banco adecuados para poder obtener el dato de b, y de a. Esto si uno está en assembly seria igual.
Entonces el compilador generará un código que haga algo como esto:
1) Situarse en RamBank de a, leer a y guardarlo en una variable en la pila.
2) Situarse en RamBank de b, leer b y guardarlo en una variable en la pila.
3) Leer de la pila el valor a y b, sumarlos y luego sumarles dos, guardar esto en la pila.
4) Situarse en RamBank de a, leer el valor de la pila y asignarselo.
Ahora bien, tal vez la variable a y b estan en el mismo banco, pero como uno en un software puede hacer lo que le plazca el compilador no tiene forma de saber la rutina fue llamada cuando uno estaba en el rambank0 o en el rambank1, etc entonces también agrega el código para pasar de RamBank #0 a Rambank #0! suena estúpido pero es lo que hacen porque la subrutina bien se podría llamar de otro lado.
Además toda esa gestión de manejo de pila consume muchas instrucciones.
Ni te cuento cuando se pasan parámetros a una función o cuando se tienen que evaluar sentencias del tipo "if then else" .
Además en c, cuando uno incluye una librería, la misma se compila con todas las fuunciones que tiene dentro, no solo con la que uno usa.
Lo mismo ocurre para las rutinas de manejo de interrupciones, o con el manejo de los RomBanks, es decir la ubicación de las rutinas en la memoria de programa. El compilador agrega los bits que son necesarios en el PCLATH todas las veces no importa si siempre estamos en el mismo RomBank, y esto es porque no sabe si llamaremos la subrutina desde el RomBank0 o el 1, 2, 3. La lista de ejemplos es interminable jeje.
Cuando codificas en assembly uno sabe exactamente lo que se está haciendo y no es nada genérico sino una solución particular para ese problema específico.
Lo de 2 o 3 veces el tamaño es relativo, hay programas en c que pueden ocupar hasta 10 veces más que uno en assembly y otros que solo 2 o 3 veces mas.
Cuando el código es mayor y se reutilizan más las mismas subrutinas el código en C se hace más optimo en relación al assembly pero nunca llegará a igualarlo.
Además muchisimo tiene que ver la arquitectura. En un pic 12 o 16 esto es muy notorio, precisamente porque tienen todo el tema de paginado de memoria de datos y de programa, además tienen pocas instrucciones que hacen más dificil y laboriosa la tarea del compilador.
En los 18, la arquitectura de los mismos (no existe paginado de memoria de programa ) ayuda a que con esa sola modificación ya el código en c sea mas pequeño, pero además tiene mas de 60 instrucciones algunas muy cómodas cuando se quiere hacer comprobaciones con lenguaje c, comprobaciones como si un registro es 0 en una sola instruccion o de si un bit es 0, etc. Además tienen una memoria "access bank" la cual se puede acceder sin importar en qué página de memoria uno se encuentre, y esto optimiza mucho sobre todo la gestión de la pila y cuestiones de variables que se utilicen mucho en el compilador.
Espero haberte aclarado algo en vez de confundirte mas.
Saludos
Espero haberte aclarado más o menos el problema.
