AVR Freaks

My recollection is that we have had this discussion before and that I was on the other side of it.

avr-gcc routinely issues sbi and cbi instructions of utility, but dubious legality.

The aforementioned optimization is in the same category.

Sometimes issuing an sbi or cbi instruction changes the semantics.

While this is an OT from the most-recent question regarding the possibility of optimising PORT ^= into PIN =, I continue to wonder about the legality of optimising a RMW of a volatile byte-sized entity i.e. PORT |= (1<<BIT) into the writing of a single bit-sized entity i.e. sbi PORT,BIT.

 

On the one hand, I agree that in the strictest sense this breaks the 'letter of the standard' w.r.t. the intended purpose of volatile.  As a volatile, a PORT read must not be eliminated.  The standard would seem to stipulate that PORT |= (1<<BIT) should be compiled as:

  in r,PORT
  ori r,1<<BIT
  out PORT,r

... the optimisation in question results instead in:

  sbi PORT,BIT

This has several effects.  The beneficial effects are:

• shorter (1 word instead of 3)
• faster (2 cycles instead of 3)
• fewer registers consumed (0 instead of 1)
• inherently atomic

 

It has two questionable side effects:

• PORT is never read
• PORT is not written (except for one bit)

 

Examining this in the specific context of an AVR's PORTx I/O registers, there are >>no<< deleterious effect associated with the side effects.  The behaviour of the output buffers is unaffected, except for the exact timing.  Since machine timing is not a purview of the C standard, this is not a violation.

 

Let's find an example where the side effects >> would<< result in differential behaviour between the strict form (in/or/out) and the optimised form (sbi):

  TIFR0 |= (1<<TOV0);

That's an interesting one.  The TIFR0 register lies within the lower half of I/O space, and is reachable by sbi/cbi.  If the compiler were to follow the letter of the standard, this would result in:

  in r,TIFR0
  ori r,1<<TOV
  out TIFR0,r

The consequence of this would be to clear not just TOV, but >>any and all<< flags currently set in TIFR0 at the moment the in instruction is executed.  Would this be the intention of the programmer?  Probably not.  In fact it would belie a misunderstanding on his part w.r.t. the functioning of the hardware vis a vis the procedure for clearing of interrupt flags (something we've seen here many times).

 

However, the compiler generates this:

  sbi TIFR0,TOV0

This is both 'right' and 'wrong'.  It is 'right' in that it likely reflects the programmer's intent, even though that intent was incorrectly expressed.  It is 'wrong' both in the sense that it violates the letter of the standard, and it is also a latent bug in the programmer's code.  If later the code is ported to a device where the TIFR0 register is no longer reachable by sbi/cbi, the behaviour will be different.  The same might be true if updating the code for a different, non-sbi-reachable register on the same device.  This may be a moot point, as I cannot recall a device which has an upper-half I/O space register (or SRAM-mapped-only register) which contains more than one interrupt flag.  All such registers appear to be in lower I/O space.

 

However, the issue would be similar when attempting RMW operations on registers like ADCSRA.  On the ATmega48/88/168/328, that is out of reach of sbi/cbi, but on the ATtiny25/45/85 it >>is<< within reach.  That means that an expression like:

  ADCSRA |= (1<<ADATE);

On the ATmega48/88/168/328:

  in r,ADCSRA
  ori r,1<<ADATE
  out ADCSRA,r

On the ATtiny25/45/85:

  sbi ADCSRA,ADATE

... resulting in different behaviour w.r.t. ADIF, depending upon the target, based solely on the address of ADCSRA on each target.  Putting aside for the moment the utility of the above expression, it is nevertheless worrisome.

 

Another worrisome example (on post-2006 hardware):

  PIN |= (1<<BIT);

Letter-of-the-standard:

  in r,PIN
  ori r,(1<<BIT)
  out PIN,r

Optimised:

  sbi PIN,BIT

Again, hardware behaviour very different.  Again, programmer's understanding of the hardware called into question.  Again, a possibly hard-to-find latent bug.

 

This analysis has only considered the 'letter of the standard'.  Whatever else they may be, standards are human documents.  By following them the hope is to arrive at an implementation that is true to the intention of the designers of the standard.  As human documents, however,  the need to interpret is never far away.  Whereas volatile may have been originally intended to provide a mechanism for multiple threads to have predictable read and write access to shared variables in memory, that intention seems to be insufficient to the task of describing and managing prescribed and proscribed read and write access to hardware resources like I/O ports and peripheral configuration registers on 'physical computing' platforms like the AVR and other microcontrollers.

 

It would seem like the standard is due for an update in this regard.  Perhaps some new keywords to help fully describe a programmers intent w.r.t. appropriate access to hardware resource.  Maybe something as simple as volatile_r, volatile_w, and volatile_rw.