"for" loop

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
niprc_3742601
Level 4
Level 4
5 likes given First like received First like given

Hello,

I was debugging my code and noticed the following.  I have a simple "for" loop like this

uint64 i = 0;

for( i = 0; i < sz; ++i )

{

  //  use i

}

However, i is 1 in the first iteration when I place a debug pointer inside the loop.  It's almost like it incremented i before the iteration, but not after.  I switched to "while" loop and seems to work fine.  Can anybody explain why this could be?

Thanks!

Nikolay

0 Likes
1 Solution
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

Hi,

I also joined the party and tried some experiments.

I used following code and with my CY8CKIT-044,

i starts from 0, but when I followed the suggested printing format "%llu"

it prints out "lu" looks like 1 ...

==============================

#include "project.h"

#include <stdio.h>

char str[128] ; /* for print buffer */

void init_hardware(void)

{

    CyGlobalIntEnable; /* Enable global interrupts. */

    UART_Start() ;

}

int main(void)

{

    uint64 i = 0 ;

    uint64 sz = 32 ;

 

    init_hardware() ;

 

    sprintf(str, "for test program (%s %s)\n", __DATE__, __TIME__) ;

    for(i = 0; i < sz ; ++i ) {

        sprintf(str, "i = %llu  : ", i) ; /* this outputs "lu" */

        UART_UartPutString(str) ;

        sprintf(str, "i = %d\n", i) ; /* this outputs 0 1 2 ... */

        UART_UartPutString(str) ;

        CyDelay(1000) ;

    }

}

==============================

And executed result was

tera_term_log.JPG

So, unless you were watching at "lu" (el yu) as 1,

you might have modified i somewhere else

or some memory over ran might have affected the value of i.

moto

View solution in original post

0 Likes
7 Replies
Anonymous
Not applicable

Hi npruss,

Did you tried the same with usefull code inside ? I mean : do something the compiler cannot optimize...

I don't know but I would say that the reason it is how it is is the compiler is optimizing this code because there is nothing usefull in the loop.

As I said, this is not an answer, only my thought.

Good luck !

0 Likes

Hello,

thank you for your response.

My for loop is not empty.  I have some code in there that I didn't post in my initial message.  i is the index into one of my buffers.  When I put a debug pointer on the first line of the loop it reports i = 1 in the first iteration.

0 Likes
Anonymous
Not applicable

I think I got it, you pre increment in the for statement... If you write i++ ?

0 Likes

I thought about it too even though I used for loop millions of times before and I always pre-increment and have never seen this behavior.  I tried i++ with the same result.  I wonder if the debugger has a bug or I corrupt memory somewhere before I use the loop.

0 Likes

Set the optimization level from "Debug" to "none" and try again.

Bob

0 Likes
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

Hi,

I also joined the party and tried some experiments.

I used following code and with my CY8CKIT-044,

i starts from 0, but when I followed the suggested printing format "%llu"

it prints out "lu" looks like 1 ...

==============================

#include "project.h"

#include <stdio.h>

char str[128] ; /* for print buffer */

void init_hardware(void)

{

    CyGlobalIntEnable; /* Enable global interrupts. */

    UART_Start() ;

}

int main(void)

{

    uint64 i = 0 ;

    uint64 sz = 32 ;

 

    init_hardware() ;

 

    sprintf(str, "for test program (%s %s)\n", __DATE__, __TIME__) ;

    for(i = 0; i < sz ; ++i ) {

        sprintf(str, "i = %llu  : ", i) ; /* this outputs "lu" */

        UART_UartPutString(str) ;

        sprintf(str, "i = %d\n", i) ; /* this outputs 0 1 2 ... */

        UART_UartPutString(str) ;

        CyDelay(1000) ;

    }

}

==============================

And executed result was

tera_term_log.JPG

So, unless you were watching at "lu" (el yu) as 1,

you might have modified i somewhere else

or some memory over ran might have affected the value of i.

moto

0 Likes

Thank you all for your input!

I think that there is something strange going on with uint64.  I used them for buffers sizes and buffer offsets(didn't have to, my buffers are small).  Changing all occurrences of uint64 to uint32 solved the problem AND eliminated another glitch in my program's behavior.