This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 8/16bit oddities on avr-gcc


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]