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.

Compiler/MSP430F5438A: mktime takes 17 ms to run - is that expected?

Part Number: MSP430F5438A

Tool/software: TI C/C++ Compiler

Using TI v 16.9.6 LTS, the mktime() function takes 17 ms to run, throwing off the timing of my application. I ran this same application 5 years ago using whatever compiler shipped with CCS 5.3, and it did NOT take that long, though I did not time it 5 years ago. I can only say that before, the timing worked as designed, and now it does not, and the culprit appears to be mktime(). Any compiler options that might affect this? I am using the same compiler options in regard to optimization that I used 5 years ago. Thanks!

  • The source code to the RTS library, including mktime, is part of the compiler installation.  You can find it in a directory location similar to ...

    C:\ti\ccsv7\tools\compiler\ti-cgt-msp430_16.9.6.LTS\lib\src

    Look for filenames that begin with "mktime".  I compared the implementation of mktime from a version about 5 years ago with the one from version 16.9.6.LTS.  Based on that, I don't see any reason to expect a large difference.  

    Is it possible that, in the older build, the RTS code executes out of fast internal memory, and in the newer build, the RTS code executes out of slow external memory?

    Thanks and regards,

    -George

  • Thanks, George.

    So there is no external memory; just using flash and RAM, and I verified that mktime is running from flash.

    But I copied the mktime code into my local repository and made the requisite changes to make that work and determined that the line in mktime that takes most of that 17 ms is the following:

    tptr->tm_wday = (((EPOCH_WDAY + daycount) % 7) + 7) % 7;

    It seems to be the modulus operator that is taking so long, though daycount is a long long, so that doesn't help.

    I am going to experiment with optimizations to see if that helps.

    Any other ideas?

    Thanks!

    Lara

  • Ok, I found the problem. There are LOTS of differences between the mktime.c of compiler 4.1.5 (the one I used 5 years ago with CCS 5.x) and 16.9.6.

    The crucial difference, however, is that daycount is time_t (unsigned long) in 4.1.5 and is long long in 16.9.6. Changing the current implementation of mktime to use time_t brought the execution of mktime from 17 ms to 2 ms.

    I do not understand why daycount would need to be long long. It is a smaller value than the variable 'result', and that is of type time_t.

    This seems like a bug.