Jump to content
David Bender

another gcc asm mystery: extra register pushed but never used

Recommended Posts

Given the following C code:

static uint16_t rx_buffer = 0;

__attribute__((interrupt(TIMER0_A0_VECTOR)))
static void SoftUART_RX(void){
 register int16_t tmp = TA0CCTL0;

 TA0CCR0 += rx_ticks_per_bit;

 if(tmp & CAP){
  TA0CCR0 += rx_ticks_per_bit_2;
  tmp = 0x0100;
  TA0CCTL0 &= ~CAP;
 }
 else{
  tmp &= SCCI;
  tmp |= rx_buffer;
  tmp >>= 1;

   if(tmp & 0x1){
    /* Shift to align with byte. */
    tmp >>= 3;
    __bic_SR_register_on_exit(CPUOFF);
    TA0CCTL0 |= CAP;
   }
  }
 rx_buffer = tmp;
}

I get the following assembler

0000f92e <SoftUART_RX>:
    f92e:	0f 12       	push	r15		
    f930:	0e 12       	push	r14		
    f932:	1f 42 62 01 	mov	&0x0162,r15	
    f936:	92 52 08 02 	add	&0x0208,&0x0172	
    f93a:	72 01 
    f93c:	3f b0 00 01 	bit	#256,	r15	;#0x0100
    f940:	09 24       	jz	$+20     	;abs 0xf954
    f942:	92 52 0c 02 	add	&0x020c,&0x0172	
    f946:	72 01 
    f948:	b2 f0 ff fe 	and	#-257,	&0x0162	;#0xfeff
    f94c:	62 01 
    f94e:	3f 40 80 00 	mov	#128,	r15	;#0x0080
    f952:	10 3c       	jmp	$+34     	;abs 0xf974
    f954:	3f f0 00 04 	and	#1024,	r15	;#0x0400
    f958:	1f d2 04 02 	bis	&0x0204,r15	
    f95c:	0f 11       	rra	r15		
    f95e:	1f b3       	bit	#1,	r15	;r3 As==01
    f960:	09 24       	jz	$+20     	;abs 0xf974
    f962:	0f 11       	rra	r15		
    f964:	0f 11       	rra	r15		
    f966:	0f 11       	rra	r15		
    f968:	b1 c0 10 00 	bic	#16,	4(r1)	;#0x0010, 0x0004(r1)
    f96c:	04 00 
    f96e:	b2 d0 00 01 	bis	#256,	&0x0162	;#0x0100
    f972:	62 01 
    f974:	82 4f 04 02 	mov	r15,	&0x0204	
    f978:	3e 41       	pop	r14		
    f97a:	3f 41       	pop	r15		
    f97c:	00 13       	reti			

r14 is never used...why the push?

 

I'm using msp430-gcc 4.6.3, same flags as in my previous post.

Share this post


Link to post
Share on other sites

Probably it was used in a calculation that was replaced during peephole optimization, which follows prolog/epilog generation. The bis-to-memory operation at f958 is one that probably was originally a read into r14 followed by a write of r14 to the memory location.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×