Microsoft and Intel don't play nice together - FYI

This is a discussion on Microsoft and Intel don't play nice together - FYI within the C Programming forums, part of the General Programming Boards category; I got around a bug some time ago and wanted to share it (took me some time to find the ...

  1. #1
    CSharpener vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,484

    Microsoft and Intel don't play nice together - FYI

    I got around a bug some time ago and wanted to share it (took me some time to find the reason) No question in this post.

    Code:
    static Ipp16s* Parm2Bits( Ipp32s param, Ipp16s *pBitStrm, Ipp32s ParamBitNum )
    {
       Ipp32s i;
       for ( i = 0 ; i < ParamBitNum ; i ++ ) {
          *pBitStrm ++ = (Ipp16s) (param & 0x1);
          param >>= 1;
       }
    
       return pBitStrm;
    }
    The above snipplet is provided by Intel in its sample library distributed with Intel IPP that illustrates usage of G723.1 audio encoder
    Ipp32s is signed 32 bit integer
    Ipp16s is signed 16 bit integer

    param is some value to be converted to bit array
    pBitStrm is array to be filled
    ParamBitNum - number of bits to extract

    At some point this function was called with param = 31 and ParamBitNum = 6

    In debug build (using VS2010 Premium) the resulting array was filled correctly with 6th bit set to 0

    In release build with following compilation flags
    Code:
    /nologo /W0 /WX- /Ox /Ob2 /Oi /Ot /Oy /D "NDEBUG" /D "WIN32" /D "_WIN32"
    /D "_WIN32_WINNT=0x500" /D "_WINDOWS" /D "STRICT"
    /D "CLIPPING_DENORMAL_MODE" /D "_USC_ALL" /D "_MBCS" /Gm- /EHsc /MT
    /Zp16 /GS /arch:SSE2 /fp:precise /Zc:wchar_t /Zc:forScope /openmp-
    /analyze- /errorReport:queue
    The first 5 bits were extracted correctly and 6th bit was set to 1

    After changing the code to
    Code:
    static Ipp16s* Parm2Bits( Ipp32s param, Ipp16s *pBitStrm, Ipp32s ParamBitNum )
    {
       Ipp32s i;
       Ipp32u val = (Ipp32u)param;
    
       for ( i = 0 ; i < ParamBitNum ; i ++ ) {
          *pBitStrm ++ = (Ipp16s) (val & 0x1);
          val >>= 1;
       }
    
       return pBitStrm;
    }
    The bug was fixed. But Intel is using right shift on signed values extensively... And as I see MS does not always optimizes such code correctly... So I'm a little bit troubled by this encounter.
    The first 90% of a project takes 90% of the time,
    the last 10% takes the other 90% of the time.

  2. #2
    Registered User
    Join Date
    May 2009
    Posts
    2,694
    In the embedded world, I have learned never to do shift or bit-wise operations on signed integers.
    Most of the times it works; but, when it does NOT finding the cause of it is very time consuming.

    Tim S.
    "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the Universe is winning." Rick Cook

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Intel 64 vs AMD 64
    By siavoshkc in forum Tech Board
    Replies: 6
    Last Post: 07-28-2007, 01:00 PM
  2. Intel USB problem
    By biosninja in forum Tech Board
    Replies: 10
    Last Post: 10-17-2006, 11:11 PM
  3. how to play play and stop wav files
    By cnu_sree in forum Linux Programming
    Replies: 4
    Last Post: 08-14-2006, 11:11 PM
  4. Intel on a Mac?
    By Syneris in forum A Brief History of Cprogramming.com
    Replies: 19
    Last Post: 02-19-2006, 06:45 PM
  5. Intel Compiler 7?
    By RoD in forum A Brief History of Cprogramming.com
    Replies: 9
    Last Post: 05-14-2003, 04:36 AM

Tags for this Thread


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21