Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.


Porting IAR code to SDCC

  • boze

    Hi folks,

    I'm new to SDCC. I'm trying to port the TI app code for the CC1111 written with IAR.

    1. Does anybody knows how to implement in SDCC the IAR pragma directive:

    #pragma bitfields=reversed
    #pragma bitfields=default

    From the IAR manual:

    Reverses order of storage of bitfields.
    #pragma bitfields=reversed
    Causes the compiler to allocate bitfields starting at the most significant
    bit of the field, instead of at the least significant bit. The ANSI standard
    allows the storage order to be implementation dependent, so you can
    use this keyword to avoid portability problems.

    2. Does anybody have some general guidelines, gotcha's for porting code from IAR to SDCC?

    I would appreciate any help,

    • Maarten Brock
      Maarten Brock

      SDCC does not support the option to set the order of bitfields. Another gotcha might be the endianness.

    • boze

      Thanks Maarten,
      I've checked, both SDCC and IAR store numbers in little endian format.
      Going back to the #pragma bitfields=reversed issue. I'm looking into how to implement this functionality.
      #pragma bitfields=reversed
      typedef struct {
         BYTE VLEN      : 3;
         BYTE LENH      : 5;
         BYTE LENL      : 8;
         BYTE WORDSIZE  : 1;
         BYTE TMODE     : 2;
         BYTE TRIG      : 5;
         BYTE SRCINC    : 2;
         BYTE DESTINC   : 2;
         BYTE IRQMASK   : 1;
         BYTE M8        : 1;
         BYTE PRIORITY  : 2;
      } DMA_DESC;
      #pragma bitfields=default

      Normally this would be allocated as 4 bytes, than 3 bits for VLEN, and so forth. In the end would be 1 bit for MB, 2 bits for PRIORITY.

      The IAR compiler default setting is the same as the SDCC compiler: "bitfields are allocated within an integer from the least significant bit to the most significant bit".

      The reversed pragma causes IAR to "the bitfield members are placed from the most significant to the least significant bit".

      I could do the "reversed" structure by manually re-arranging, like:

      BYTE PRIORITY   : 2;
      BYTE MB         :1;
      BYTE IRQMASK    :1;

      My problem is that I don't know if for the multiple bit bitfields the LSB MSB bits are also reversed by the pragma. This is an IAR question that I will follow up to clarify.

      But what if it so?

      How could I create an equivalent "reversed" structure in SDCC?


      • Maarten Brock
        Maarten Brock

        I doubt any compiler would reverse bits in a multi-bit bitfield. That's just plain insane. The logical way to convert a normal int to/from a bitfield is by shifting and masking.

        Manually rearranging the bitfields should be enough.

    • boze

      >Manually rearranging the bitfields should be enough.

      Yes, that makes sense.
      So, I set up a makefile and started to compile the TI supplied IAR code with SDCC.

      I'm getting warning 126: unreachable code for macros defined in the TI code:

      Line causing the warning:       SET_MAIN_CLOCK_SOURCE(CRYSTAL);
      Definition of SET_MAIN_CLOCK_SOURCE:

      #if (chip == 1110 || chip == 1111 || chip == 2510 || chip == 2511)
      #define SET_MAIN_CLOCK_SOURCE( source )       \   do {                                        \     if(source) {                              \       CLKCON |= 0x40;                         \       while(!HIGH_FREQUENCY_RC_OSC_STABLE);   \       SLEEP |= 0x04;                          \     }                                         \     else {                                    \       SLEEP &= ~0x04;                         \       while(!XOSC_STABLE);                    \       NOP                                     \       CLKCON &= ~0x47;                        \       SLEEP |= 0x04;                          \     }                                         \   }while(0)

      What does this message means? How can I get rid of it?
      Is there an equivalent of the IAR xcl linker script files defining the memory layout for certain chips?
      What memory model should I use?


      • Maarten Brock
        Maarten Brock

        This message probably means that CRYSTAL is a compile time constant. The compiler detects that either the if- or the else-clause will never be executed and warns you about it. You may ignore it. To get rid of it you can disable it or you can change it to a preprocessor #if #else #endif.

        SDCC has no input scripts, only command line options. Look in the manual for --code-loc, --data-loc, etc. For the memory model I suggest small and move larger variables to idata/pdata/xdata manually if necessary.