Consulta acerca de codigo generado por SDCC y PICC (Hitehc)

[AngelGris]

Hola gente, estuve buscando bastante tiempo y no pude encontrar nada. Busqué en Internet en general y también dentro del foro...

Estoy tratando de mudar a Linux y para ello bajé el PikLab (estoy usando este entorno porque me permite configurar un programador por puerto paralelo), SDCC y PICC para dicho S.O.
He compilado tanto con PICC y con SDCC un mismo proyecto y para mi asombro hay una diferencia abismal entre lo que ocupa el .HEX generado por PICC y lo ocupado por el generado por SDCC.
El .HEX generado por PICC sólo ocupa 38 líneas de código de programa mientras que el generad por SDCC ocupa 240 líneas.

¿Alguien pudo experimentar entre ambos compiladores? Como para darme una idea si es algo normal o le estoy pifiando en algún parámetro del SDCC. Aclaro que los parámetros de compilación son los que pasa por defecto el PIKLAB cuando llama al SDCC.

Desde ya, muchísimas gracias por cualquier aporte

[Felixls]

Uso SDCC con ubuntu (no conozco PICC), y te puedo decir que normalmente el asm que genera SDCC es mucho más largo que los de otros compiladores.
Puntualmente, cual sería el código que estás probando? que tipo de PIC es? Si es 16F genera mucho más código que en el caso de los 18F

[AngelGris]

Hola,
el código es el que sigue (lo usé simplementa para ver la diferencia). Aclaro que en el programa original está bien la sentencia #include y la configuracion del PIC (no la agrego aquí ya que difiere según el compilador)

Código: C

1. void main()
2. {
3.     unsigned char dato = 1;
4.     TRISB = 0;
5.     while (1)
6.     {
7.         PORTB = dato;
8.         if (dato < 128) dato = dato<<1;
9.         else
10.             dato = 1;
11.     }
12. }

Justamente el PIC con el que estoy probando es un 16F876A.
En base a lo que comentás me quedo un poco más tranquilo entonces, ya que no sería un error entre el PIKLAB y el SDCC.

[Felixls]

Compilé ese código con SDCC y me dio este ASM:

Código: [Seleccionar]

_main
MOVLW 0x01
BANKSEL r0x1000
MOVWF r0x1000
BANKSEL _TRISB
CLRF _TRISB
_00109_DS_
BANKSEL r0x1000
MOVF r0x1000,W
BANKSEL _PORTB
MOVWF _PORTB
MOVLW 0x80
BANKSEL r0x1000
SUBWF r0x1000,W
BTFSC STATUS,0
GOTO _00106_DS_
BCF STATUS,0
RLF r0x1000,F
GOTO _00109_DS_
_00106_DS_
MOVLW 0x01
BANKSEL r0x1000
MOVWF r0x1000
GOTO _00109_DS_
RETURN

El c completo para un 16f628a sería:

Código: [Seleccionar]

#include <pic/pic16f628a.h>

typedef unsigned int word;
word at 0x2007 CONFIG = _XT_OSC & _WDT_OFF & _PWRTE_ON & _BOREN_OFF & _LVP_OFF & _CP_OFF & _DATA_CP_OFF & _MCLRE_ON;

void main()
{
    unsigned char dato = 1;
    TRISB = 0;
    while (1)
    {
        PORTB = dato;
        if (dato < 128) dato = dato<<1;
        else
            dato = 1;
    }
}

Utilicé este Makefile

Código: [Seleccionar]

PROG_NAME = test.hex
OBJS = test.o

sdcc_PIC_TYPE = 16f628a
lkr_PIC_TYPE = 16f628a

TOOLSDIR = /usr
DEBUG = -DUSB_USE_UART #-DDEBUG_UART -DDEBUG # -DDEBUG_PRINT
CFLAGS = -mpic14 -p$(sdcc_PIC_TYPE) $(DEBUG) --opt-code-size
INC = -I.
CRT = crt0.o

all: clean $(PROG_NAME)

.c.o:
sdcc  $(CFLAGS) $(INC) -c $<

$(PROG_NAME): $(OBJS)
sdcc $(DEBUG) -Wl-s/usr/share/gputils/lkr/$(lkr_PIC_TYPE).lkr,-m -mpic14 -p$(sdcc_PIC_TYPE) $+ -o $(@)
clean:
rm -f *.o *.lst *.cod *.hex *.map *.asm      

El code size estimation tiró:

;   code size estimation:
;      16+    6 =    22 instructions (   56 byte)

No lo veo tan mal  

[AngelGris]

Compilé ese código con SDCC y me dio este ASM:

Código: [Seleccionar]

_main
MOVLW 0x01
BANKSEL r0x1000
MOVWF r0x1000
BANKSEL _TRISB
CLRF _TRISB
_00109_DS_
BANKSEL r0x1000
MOVF r0x1000,W
BANKSEL _PORTB
MOVWF _PORTB
MOVLW 0x80
BANKSEL r0x1000
SUBWF r0x1000,W
BTFSC STATUS,0
GOTO _00106_DS_
BCF STATUS,0
RLF r0x1000,F
GOTO _00109_DS_
_00106_DS_
MOVLW 0x01
BANKSEL r0x1000
MOVWF r0x1000
GOTO _00109_DS_
RETURN

El c completo para un 16f628a sería:

Código: [Seleccionar]

#include <pic/pic16f628a.h>

typedef unsigned int word;
word at 0x2007 CONFIG = _XT_OSC & _WDT_OFF & _PWRTE_ON & _BOREN_OFF & _LVP_OFF & _CP_OFF & _DATA_CP_OFF & _MCLRE_ON;

void main()
{
    unsigned char dato = 1;
    TRISB = 0;
    while (1)
    {
        PORTB = dato;
        if (dato < 128) dato = dato<<1;
        else
            dato = 1;
    }
}

Utilicé este Makefile

Código: [Seleccionar]

PROG_NAME = test.hex
OBJS = test.o

sdcc_PIC_TYPE = 16f628a
lkr_PIC_TYPE = 16f628a

TOOLSDIR = /usr
DEBUG = -DUSB_USE_UART #-DDEBUG_UART -DDEBUG # -DDEBUG_PRINT
CFLAGS = -mpic14 -p$(sdcc_PIC_TYPE) $(DEBUG) --opt-code-size
INC = -I.
CRT = crt0.o

all: clean $(PROG_NAME)

.c.o:
sdcc  $(CFLAGS) $(INC) -c $<

$(PROG_NAME): $(OBJS)
sdcc $(DEBUG) -Wl-s/usr/share/gputils/lkr/$(lkr_PIC_TYPE).lkr,-m -mpic14 -p$(sdcc_PIC_TYPE) $+ -o $(@)
clean:
rm -f *.o *.lst *.cod *.hex *.map *.asm      

El code size estimation tiró:

;   code size estimation:
;      16+    6 =    22 instructions (   56 byte)

No lo veo tan mal  

No, claro, eso es fantástico.. 

Como yo lo había compilado con PICC me daba 38 byte y con SDCC 240 byte. Pero tu compilación tira que pueden ser 56 byte, nada que ver.... 

Voy a ver que diferencais hay entre tu "makefile" y lo que está generando el PIKLAB. Tal vez modificando algo logre llegar a un código tan reducido.

Muchísimas gracias por la ayuda que me estás brindando.

[Risanti]

Consutla como puedo usar ese makefile, es verdad que el codigo de sdcc es grande me interesaria saber como puedo probar esto?'

Gracias

[AngelGris]

Pues yo todavía no hice ninguna otra prueba.

Me perdí a en investigar un poco de programación QT y/o Lazarus para hacerme mi propio programador de PICs por puerto paralelo. Ya que el que incluye el PIKLAB no me gusta porque no puedo usar más de una señal de VPP. Mi programador está basado en el ProPic2 y tiene VPP y VPP2 así que quiero un soft que pueda manejar las dos señales...

[AngelGris]

Recién volví a hacer una prueba con el PikLab (Linux) y al final de la compilación (con los parámetros que pasa por defecto el PikLab) me tira

Código: ASM

1. ;       code size estimation:
2. ;          16+    6 =    22 instructions (   56 byte)

Pero he notado algo y supongo que es lo que hace que el .Hex quede tan "grande".

Código: ASM

1. STARTUP code 0x0000
2.         nop
3.         pagesel __sdcc_gsinit_startup
4.         goto    __sdcc_gsinit_startup

O sea que, además del código que genere nuestro programa también se encuentra el código que exista en "__sdcc_gsinit_startup" el cuál no sé de que se trata.