Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

Issues - SDCC generating too much extra code

Alex Walls
2011-08-25
2013-10-31
  • Alex Walls
    Alex Walls
    2011-08-25

    Hello.
    I have been wanting to migrate from CC5X compiler to SDCC. But I have found a couple of issues that have pushed me a little backwards and I wish you could assist me clarifying some questions.

    I have found a behaviour that I did not find in CC5X. This is.-
    Compiling for PIC16F877A…

    void main()
    {
        while (1);
    }
    

    (That and only that, there is no more code than that in the main.c file)

    The output file (lets talk about the ASM one here) is as short as this.

        processor  16F877A
        radix  DEC 
        GOTO main
    main
    m001    GOTO m001
        END
    

    Of course, I did not ask it to do anything else at all.

    …But in the other side, SDCC’s result is a lot bigger.-

    ;--------------------------------------------------------
    ; File Created by SDCC : free open source ANSI-C Compiler
    ; Version 3.0.0 #6037 (Apr 13 2011) (Linux)
    ; This file was generated Thu Aug 25 00:28:43 2011
    ;--------------------------------------------------------
    ; PIC port for the 14-bit core
    ;--------------------------------------------------------
    ;   .file   "main.c"
        list    p=16f877a
        radix dec
        include "p16f877a.inc"
    ;--------------------------------------------------------
    ; external declarations
    ;--------------------------------------------------------
        extern  __sdcc_gsinit_startup
    ;--------------------------------------------------------
    ; global declarations
    ;--------------------------------------------------------
        global  _main
        global PSAVE
        global SSAVE
        global WSAVE
        global STK12
        global STK11
        global STK10
        global STK09
        global STK08
        global STK07
        global STK06
        global STK05
        global STK04
        global STK03
        global STK02
        global STK01
        global STK00
    sharebank udata_ovr 0x0070
    PSAVE   res 1
    SSAVE   res 1
    WSAVE   res 1
    STK12   res 1
    STK11   res 1
    STK10   res 1
    STK09   res 1
    STK08   res 1
    STK07   res 1
    STK06   res 1
    STK05   res 1
    STK04   res 1
    STK03   res 1
    STK02   res 1
    STK01   res 1
    STK00   res 1
    ;--------------------------------------------------------
    ; global definitions
    ;--------------------------------------------------------
    ;--------------------------------------------------------
    ; absolute symbol definitions
    ;--------------------------------------------------------
    ;--------------------------------------------------------
    ; compiler-defined variables
    ;--------------------------------------------------------
    ;--------------------------------------------------------
    ; initialized data
    ;--------------------------------------------------------
    ;--------------------------------------------------------
    ; overlayable items in internal ram 
    ;--------------------------------------------------------
    ;   udata_ovr
    ;--------------------------------------------------------
    ; reset vector 
    ;--------------------------------------------------------
    STARTUP code 0x0000
        nop
        pagesel __sdcc_gsinit_startup
        goto    __sdcc_gsinit_startup
    ;--------------------------------------------------------
    ; code
    ;--------------------------------------------------------
    code_main   code
    ;***
    ;  pBlock Stats: dbName = M
    ;***
    ;entry:  _main  ;Function start
    ; 2 exit points
    ;has an exit
    ;; Starting pCode block
    _main   ;Function start
    ; 2 exit points
    _00106_DS_
    ;   .line   9; "main.c" while (1);
        GOTO    _00106_DS_
        RETURN  
    ; exit point of _main
    ;   code size estimation:
    ;       2+    0 =     2 instructions (    4 byte)
        end
    

    …of course ignoring the comments, it is still a lot more.
    Now, the HEX files output by CC5X and SDCC are 34 Bytes and 1224 Bytes respectively.
    The result binary of CC5X takes one instruction to get into the while statement, but the one by SDCC takes about 350 instructions to fall in it.

    Why is that? Is there any reason for that much instructions, which I have no idea what they actually do, to be ran before the actual program I wrote begins? Is it avoidable?

    Under normal circunstances I would not care about losing 350microseconds in the startup of a PIC, it is not, lets say, toooooo much time. But I am worried about another issue that I suspect might be related to this.

    First, a lot of general purpose registers are altered with random (I think) values before my program starts, I don’t know why it happens but seen from my ignorance in this issue it appears to me like a waste of registers. I wish I knew why that happens.

    Now my real issue is that, for a project I am coding, I need to alter the PCL‘s registry value for me to jump to an arbitrary function… In this case, I want to jump to the main function again and lets imagine its location in the program memory is 0x02D.

    The code I want then to try is.-

    void main()
    {
        // Whatever else...
        PCL = 0x02D;
    }
    

    This behave (I think) the same as if I surrounded that “Whatever else” in a while(1) structure.

    The strange thing is that the binary result of CC5X compiler works flawleslly with this code, also its result binary size is minimal. With SDCC instead I get a different behaviour.

    Using PIC Simulator IDE (happens with GPSim too), when PCL has to get the new value, it gets a random value which makes it, it seems, kind of forget it is working and just to sum up until it overflows, over and over just like a normal timer. The only instruction being processed by the simulator is a “ADDLW 0xIT“ one, forever.
    But this wont happen if in the beginning of the simulation I, by hand, give the PCL register the address of the main function of my program, so it will be the first or second instruction to be processed. In this case, my program works as expected.

    So, my only guess is that there has to be something wrong happening with all that “startup” code that SDCC generated. But no clue on what that could be.

    Any help on clarifying this will be very appreciated. Greetings.

     
  • Jan Kirschner
    Jan Kirschner
    2013-10-31

    Same problem for me. Did someone manage to find a solution?