SDCC programming error

[Thomas]

Hi,

debugging and no end.

My code in short form (in reality there are code that does something with the values):

data unsigned char elements_groups[8];

.....

void f1(){

  char i;

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

    MIOS_MIDI_TxBufferPut(0xbd);  //only debug print

    MIOS_MIDI_TxBufferPut((elements_groups >> 4) & 0x0f);  //only debug print

    MIOS_MIDI_TxBufferPut(elements_groups & 0x0f);  //only debug print

  }

 

  f2(8, 0);

}

void f2(unsigned char size, unsigned char offset){

  unsigned char i;

  unsigned char elements_group;

 

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

    elements_group = elements_groups[i + offset];

    MIOS_MIDI_TxBufferPut(0xbc);  //only debug print

    MIOS_MIDI_TxBufferPut((elements_groups[i+offset] >> 4) & 0x0f); 

    MIOS_MIDI_TxBufferPut(elements_groups[i+offset] & 0x0f);  //only debug print

   

    MIOS_MIDI_TxBufferPut(0xba);  //only debug print

    MIOS_MIDI_TxBufferPut((elements_group >> 4) & 0x0f); 

    MIOS_MIDI_TxBufferPut(elements_group & 0x0f);  //only debug print

  }

}

The array elements_groups has the following values:

{0x81, 0x01, 0x01, 0x09, 0x01, 0x01, 0x01, 0x01, 0x01}

The first for loop in f1 prints out (via midi)

BD 08 01

BD 00 01

BD 00 01

BD 00 09

BD 00 01

BD 00 01

BD 00 01

BD 00 01

All is ok. From funktion f2 I get the following output:

BC 08 00  //wrong: must be BC 08 01

BA 08 01  //ok

BC 00 00  //wrong: must be BC 00 01

BA 00 01  //ok

BC 00 05  //wrong: must be BC 00 01

BA 00 01  //ok

BC 00 01  //wrong: must be BC 00 09

BA 00 09  //ok

BC 00 0F  //wrong: must be BC 00 01

BA 00 01  //ok

BC 00 00  //wrong: must be BC 00 01

BA 00 01  //ok

BC 00 00  //wrong: must be BC 00 01

BA 00 01  //ok

BC 00 00  //wrong: must be BC 00 01

BA 00 01  //ok

Ok. I though this it what I noticed as a rule "use a temporare variable not the array itself". It seemed that the version with BA is ok. BUT:

If I remove the BC-part I get:

BA 00 00

BA 00 00

BA 00 01

BA 0E 01

BA 00 0F

BA 00 00

BA 00 00

BA 00 00

>:(

What happens here?

I haven't checked the produced asm output yet.

It's a simliar problem like the other: SDCC produced different behaviour depending from the surrounding code.

By the way: this is code that works perfectly with the other software version.

It cannot be wrong. 

The differences between the software versions are controled by #ifdefs and #if

But this is a common part of all software versions!

Am I the only one who have these problems?

It seems all other program successfully with SDCC?

Is it a problem of code size? (my code goes up to 7d00)

[Thomas]

If I use another variable it works:

unsigend char index;

...

index = i + offset;

elements_group = elements_groups[index];

insteadt of

elements_group = elements_groups[i + offset];

[audiocommander]

does it work when you use a bracket?

=> array[(index + number)];

[Thomas]

Hi Audiocommander!

I will check this next week. Have no time at the moment.

But even if it works: SDCC shouldn't  produce different code then.

Thats the problem, thats why debugging is so hard and thats why I have to ask Thorsten every time how MIOS react to exclude a MIOS bug or unexpected MIOS behaviour.

I contacted Vangelis but no replay until now.

See the other Thread:

In a for-loop SDCC produced different code dependig if I use only constant values in its body or not.

Thorsten meant

unsigend char i;

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

is undefined and therefor the compiler is free to create the code which it wants.

I don't think so. I asks in the german C(++) newsgroups because I'm very courious and unsure now. But it seems I'm right: it is defined! The loop is never executet.

i < 0 is always false for unsigned i.

The problem with signed loop variables are: the code is bigger! There are more asm-statements.

Too many in my case, I'm on the upper limit... 

So it became a #if - orgie...

Greetings Thomas

[audiocommander]

well, setting brackets would be the correct programming style, because the compiler then first evalues (index + something) and then array[index]. I can imagine that SDCC does not think of every possible case where brackets are not set / not set as expected :-\

Thats the problem, thats why debugging is so hard and thats why I have to ask Thorsten every time how MIOS react to exclude a MIOS bug or unexpected MIOS behaviour.

Therefore I programmed the ACDebug/Simulator classes. As you cannot exclude all possible errors (likely this one will not be covered), you can inspect normal illogic behavior by tracking your variables before uploading the code to the Chip :) It's quite normal for me that codes does not work in the first two or three runthroughs; this code really helped me reduce the amount of time finding the errors!

unsigend char i;

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

is undefined and therefor the compiler is free to create the code which it wants.

I don't think so.

I'm not sure what's the point about this example. As you say, an unsigned number that's initiated with 0 and incremented will never be < 0, so this example is just wrong and in my eyes it's unrelevant if it's defined or not: it will just do what it's meant to do: nothing right ;)

As you can read in the SDCC manual there are some (esp. loop-) optimisations done by SDCC which can be supressed if not wanted; either by setting compiler flags or using define-statements...

However, until now I didn't get to a point where I needed such stuff...

Cheers,

Michael

[stryd_one]

I can imagine that SDCC does not think of every possible case where brackets are not set / not set as expected :-\

I agree. early versions of VB were killer for that too... As a result I often use brackets now, where they are not really required  ::) It's rarely harmful though, of course.

Therefore I programmed the ACDebug/Simulator classes.

Yeh guys if you're developing MIOS apps in C and not using this, do yourself a favour...Grab it and use it :) Especially if you use AC's Debugger/Simulator with an IDE like xcode or codeblocks, If you're a newbie you get a quick and easy way to learn to write and test code for MIOS and even if you're more experienced you can save a lot of time and effort.