Cuidado con CCS & ASM

[elmasvital]

Se nota que estoy de proyecto???vuelvo con otra paradoja que me ha llevado casi al manicomio

El proyecto está realizado en CCS (compilado desde mplab para debugear mejor con ICD2). Todo las referencias sobre el programa que uso está referido al entorno de MPLAB con pluging para CCS.

Estoy como algunos sabeis realizando un proyecto en el que la temporización es crucial y cualquier desjuste te da un fallo en vete a saber tu donde y que es dificil de relacionar hasta que le das mil vueltas...

He aquí otro ejemplo de ello...

este código

   btfsc   PORTA, 0 
   bsf     INDF0, 7
   subwf   FSR0L, W
   btfsc   STATUS,Z
   goto   fin_data
   incf   FSR0L
   goto   Get_Data

con porta a 0 e INDF >0 deberia realizarse en 8 ciclos de instrucción... pues bien despues de darle muchas vueltas y de sospechar de esta rutina veamos lo que dice el simulador de mplab compilando esta rutina y observando el stopwatch...




7 CICLOS???? pero cómo porqué... Ya visto el problema está claro que no está compilando lo que yo le he mandado... veamos la ventanita de program memory (para el que no lo sepa esta ventana contiene realmente lo que el pic tiene en su memoria de programa)



El problema en cuestión como podeis ver es que el compilador, imagino que ccs, supervisa el código y optimiza

   btfsc   STATUS,Z   
   goto   fin_data

que se ejecutaría en 2/3 ciclos de instrucción

por

   bz 0x44c

que se ejecuta en 1/2....

[Nocturno]

Jeje, se podría decir que el compilador "se ha pasado de listo".

[alogic.on]

pues vaya chasco, si que se ha pasado de listo el compilador.
Aparte del tema, yo tenia una preguntica sobre mplab, me acorde al ver la ventana de programa de elmasvital, como se hace para que la ventana de programa muestre los nombres asignados a la memoria ram y los bits de cada uno y los nombres de las CALL. A mi me sale solo con numeros hace un par de versiones, y desde entonces ando un poco perdido  en esa ventana

[droky]

  Vaya, para una vez que depura bien...

Salu2

[elmasvital]

pues vaya chasco, si que se ha pasado de listo el compilador.
Aparte del tema, yo tenia una preguntica sobre mplab, me acorde al ver la ventana de programa de elmasvital, como se hace para que la ventana de programa muestre los nombres asignados a la memoria ram y los bits de cada uno y los nombres de las CALL. A mi me sale solo con numeros hace un par de versiones, y desde entonces ando un poco perdido  en esa ventana

En la misma ventana de program memory hay unas pestañitas abajo a la izquierda. Señala la que pone symbolic. Si trabajas con ccs tambien puedes ver las concordancias del codigo fuente en c y el ensamblado en la ventana view>>dissasembly listing.

[pibe]

Y es por esto que no me decido pasarme a C, viva el asm! 

[jfh900]

Una pregunta ¿el código ASM está embebido? o ¿es el generado por el compilador al transformar el programa "C"?

Un saludo

[RedPic]

Esa es la misma pregunta que se me ocurre a mi.

¿Esta con #ASM o es el que genera CCS?

[elmasvital]

es #asm #endasm... osea embebido dentro de un programa de c del compilador ccs, que es lo que se ve en la ventana de la izquierda. En la ventana de la derecha la memoria de programa del pic.

[MGLSOFT]

El nivel de optimizacion del compilador de CCS viene por defecto en 9 , siendo el valor mas alto creo que el 11.
Lo que no sabia es que pudiera optimizar mas aun el codigo ya escrito en assembler...

[alogic.on]

En la misma ventana de program memory hay unas pestañitas abajo a la izquierda. Señala la que pone symbolic. Si trabajas con ccs tambien puedes ver las concordancias del codigo fuente en c y el ensamblado en la ventana view>>dissasembly listing.

oooooooooh!!     gracias  me acabas de alegrar el finde (esto antes de mirarlo)

joder pero si es un perro, no es que me muerda, es que soy jili!! (y esto despues de mirarlo) 
pues na ya lo ven, a veces uno con la cosa mas simple se queda pillao dando vueltas 

volviendo al tema del asm optimizado por c ??  yo no se mucho, pero no me parece que vaya a hacer lo mismo el codigo en asm que optimizado por ccs, para mi que se le ha ido la olla. si no seria mas facil programar en assembler y que ccs te lo optimize, en vez de hacerlo a pulso, y ron como algunos ;P jejej
bueno, son instrucciones para pic18 que las estoy empezando a mirar, pero si te recoloca el programa ten cuidado por si alguna te lia que el assembler ya es puñetero como para que te lo modifiquen

un saludo y gracias

[jfh900]

A mi me parece un bug del propio compilador. Un código escrito en ASM no lo debe de tocar bajo ningún concepto, ya que se entiende que si lo has escrito expresamente en ASM es por alguna razón de peso (velocidad, ahorro memoria, precisión, etc) y por lo tanto al optimizarlo puede pasar como a ocurrido que lo estropee en vez de mejorarlo.

Un saludo

[MGLSOFT]

Yo creo que el compilador solo sigue reglas de reemplazo, no es que sea muy listo...
En el caso del salto, lo reemplazo por una macro que ahorra un ciclo y listo, no se puso a averiguar porque razon (si es que la habia) el programador lo hizo de esa forma....

[RedPic]

es #asm #endasm... osea embebido dentro de un programa de c del compilador ccs, que es lo que se ve en la ventana de la izquierda. En la ventana de la derecha la memoria de programa del pic.

Pues entonces me parece un error garrafal por parte del CCS. Yo quiero que cuando escribo en ASM me lo respete escrupulosamente, precisamente por eso escribo ASM, para hacer exactamente lo que yo quiero hacer, no lo que interprete el programdor del compilador.