8/16bit oddities on avr-gcc

Michael Kukat michael@kukat.de
Fri Mar 2 17:04:00 GMT 2007


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



More information about the Gcc-help mailing list