Okay, next fun :)
This is the (nearly) whole function:
void cv_mux_update() {
uint8_t regnum;
int16_t value, *cv, *cvold;
struct update {
uint8_t num;
int16_t val;
} *update;
spibuff[0] = CMD_SETREGS;
update = (struct update *)&(spibuff[1]);
cv = cv_mux_comm.cvdata;
cvold = cv_mux_comm.cvdata_old;
regnum = 0;
if(cv_mux_comm.force_update) {
do {
value = *cv;
*cvold = value;
update->num = regnum;
/* update->val = value;*/
update++;
cvold++;
cv++;
} while(++regnum < NUM_CV);
} else {
}
slave_send(3, spibuff, (uint8_t *)update - spibuff);
cv_mux_comm.force_update = 0;
}
cvdata and cvdata_old in cv_mux_comm are int16_t[], spibuff is
uint8_t[]. If i leave the commented line commented, regnum is left in 8
bit over the loop. No "unsigned int" variables are created, just an "int
spibuff.1", which currently doesn't interest me too much.
If i remove the comments, 2 variables which have absolutely nothing to
do with regnum lead to the "unsigned int" variable introduces again to
take the role of regnum. Same thing as the simpler example which has
shown this problem with 4.1.1:
unsigned int ivtmp.272;
...
MEM[base: update] = (uint8_t) ivtmp.272;
...
ivtmp.272 = ivtmp.272 + 1;
if (ivtmp.272 != 64) goto <L12>; else goto <L11>;
Don't want to rip out the struct, as this is for performance reasons.
You don't want to see the code which results from an int16_t >> 8 :) I
could write it in a different way, but then it gets a bit unreadable :)
Okay, investigating further, just wanted to tell this...
...Michael
