• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 55 subscribers
  • Views 521 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

porting tools

John Fisher
Expert 1030 points


    My client has 200KLOC of working code on an architecture where char is 8 bits, short is 16 bits, and int and long are 32 bits. They want to port to C55x where char, short and int are all 16 bits, and long is 32 bits. The source for the most part looks reasonably well written C90 code, however I have discovered code which relies on the current architecture. For example:

    unsigned char c;
    unsigned short s1, s2;
    unsigned long l;

    /* Mask to 8 bits */
    c = (unsigned char)l;
   
    /* May overflow on C55x */
    l = s1 + s2;
   
    Does anyone know of tools that can draw attention to code that works on the current architecture, but probably won't on C55x?
   
    To be more specific, I'm looking for a tool or tools that will locate code where:
    1. a short, int or long is implicitly or explicitly demoted to char;
    2. a binary operation that could cause overflow (* + - << *= += -= <<=) occurs between any two integer types except long, and the result is placed in either an int or a long;
    3. a unary operation that could cause overflow (- ++ --) occurs on int and
    4. casts occur between char * and other pointer types.

    The preceding paragraph specifies type widths only, not signedness or qualification or the lack of either.
   
    I have already tried splint and gcc under cygwin. I don't think they can be made to do what I want. I don't believe gcc is available for C55x. I've searched web descriptions of static analysers, but so far have not found anything that helps.

  • 0
    Expert 1816 points

    Hi John,

    I have no real solution to your problems but maybe a couple of hints...

    To address problems related to different sizes of int and unsigned you may try to typedef int32 and Uint32 and use those types instead of int and unsigned (or simply change the type in definitions with int or unsigned to the corresponding long type).

    BTW, I would expect the example with s1+s2 to also overflow on the original architecture as there short is also 16 bit wide.

    The 16 bit character issue is quite a nasty one. In some situations it might help to define

    typedef struct {
      Uint16 lo:8;
      Uint16 hi:8;
    } char16;

    and use the lo component if you need 8 bit overflow.

    Regards

    Johannes

     

     

     

  • 0 in reply to Johannes von Löwis
    TI__Guru**** 251090 points

    I'm not aware of any tool which helps this particular situation.  

    I also recommend the technique of using typedef names for types.  I highly recommend use of the standard header file <stdint.h> for this purpose.  This header file is supported by most C compilers, and all the TI compilers.  This means you can use fixed width type names such at int16_t, uint32_t, and so on.  An internet search on "stdint.h" will yield lots of useful information.

    Keep in mind you can make the change to typedef names before you port the code to C5500.  Make the changes and test it out on your current system.  This won't find every single problem, but it will find quite a few.

    Thanks and regards,

    -George

  • 0
    TI__Expert 4280 points

    The --check_32bit_int_portability option will help on some of these issues.  This is the description from the Release Notes:

    ================================================================================
    4.1.0-15. New Option to Check for Portability Issues for 32-bit int Type
    ================================================================================
    When the option --check_32bit_int_portability is specified the compiler will
    issue a warning if it detects a source language construct that may not be
    portable when moved from a C environment where the type int is represented in 32
    bits to C55x C where int is 16 bits.  Not all such portability issues can be
    detected at compile-time.

  • 0 in reply to Johannes von Löwis
    TI__Guru* 84285 points

    Johannes L. said:

    BTW, I would expect the example with s1+s2 to also overflow on the original architecture as there short is also 16 bit wide.

    No, because the C standard requires that both s1 and s2 be converted to "signed int" before the addition on the original architecture.

  • 0 in reply to Archaeologist
    Expert 1816 points

    You are right, thank you for pointing out that I was wrong.

    I found it rather difficult deducing sizeof(s1+s1) == sizeof int from K&R but it's mentioned there. My research on the web showed that I'm not the only one which makes me feel a bit less stupid.

    Regards, Johannes