AVR Freaks

Not being well versed in the subtleties of C, I opt for execution speed and code compactness over the strict adherence to language conventions, especially under the hood. Like frog_jr, I mostly rely on ISR execution to deal with interrupt flag clearing. And, when that is not the case, as in polling, writing one bit almost always does what needs to be done. Guess I'm not going to get my undies all twisted!

Jim

In the case where all three flags in TIFR0 are set, the

TIFR0 |= (1<<TOV0) | (1<<OCF0A);

will actually clear all three bits since it is doing the RMW

 11a:	85 b3       	in	r24, 0x15	; 21   // r24 would be 0x07
 11c:	83 60       	ori	r24, 0x03	; 3    // no change
 11e:	85 bb       	out	0x15, r24	; 21   // clear all three flags...

while the

TIFR0 = (1<<TOV0) | (1<<OCF0A);

does what I expect (just clear OVF and OCFA, leaving OCFB alone).

So, beware using |= for clearing multiple flag bits.

Now my head hurts. .....I have no idea what is right or wrong.

I have an appointment for my pension application today...maybe you should try the same thing..... 

On PORTx, DDRx, GPIOx and some other registers,

one can argue sensibly about whether generating an SBI instruction for an |= violates the volatile rules.

I've done so.

To summarize my position: It does, but the compiler should do it anyway.

On PINx and interrupt flag bits, there is only one sensible position:

The compiler is wrong.

I'm not convinced that *any* assignment to any of those registers is valid C.

In no case, does the hardware do the assignment.

That said, all whole-register read mechanisms produce the same result

and all whole-register write mechanisms produce the same result,

so whole-register optimization choices have no effect, except for timing, on the result.

|=ing a single PINx or interrupt flag bit can produce different results

depending on whether whole-register or single-bit instructions are used.

As noted before, in neither case does the hardware do the assignment.

I think the best answer for this is a pair of macros that expand

into in-line assembly containing a single SBI or CBI instruction.

PORTB ^= fred;

Is the compiler allowed to compile that as

OUT PORTB PINB, Rfred

?

Edit: PORTB to PINB

I thought SBI was a single instruction read-modify-write. 

The compiler could and possibly should convert TIFR0=(1<<TOV0) into an SBI.

So far as I know, none do.

None of the C statements under discussion are valid.

The represented assignments cannot be done on the machine.

TIFR0=0 is valid, but the compiler-generated code would likely be incorrect.

#define sbi1(reg, bit) asm( " SBI %0, %1\n" :: I(_SF_IO_ADDR(reg)), I(bit)

#define cleariflag(reg, bit)  do { if(_SF_IO_ADDR(reg)<=0x1f) sbi1(reg, bit); else reg=(1<<(bit); } while(0)

sbi1 instead of sbi because the latter already exists.

The joy of revision control is that if you really want to know the answer you can wind back time and take a look.  I haven't but I suspect that in the early days the compiler may not have been smart enough to optimise  to SBI/CBI when it could (1 bit changing and low enough address) so I'm guessing sbi() and cbi() were Asm macros that the user could manually force the use of SBI/CBI my when they knew it was appropriate. Later,  when the compiler automated this they were simplified to "do nothing" macros. 

I think I disagree. According to the C semantic model, provided the right bits are set in the lvalue then how they are set is implementation dependent.

C doesn't know anything about registers, which is a major deficiency for low level programming. Even volatile doesn't really have the semantics we need,  there is a lot dependent on the implementation.

Frankly, C is an ancient language which should be binned, but the nature of software is we are stuck with the past. At least, there needs to be formal attributes and semantics defined for things like register access, RMW behaviour, memory barriers, instruction ordering etc.

No, the semantic model describes the result not the method. In the specific case of |=, the operation can only lead to bits being set. Their previous value is a don't care, therefore there is no need to read them. volatile means that if an access is required, then the value is re-read. The only reason for the read is to preserve untouched bits, but if the compiler can preserve the bits in a more optimal way, it can do it.

A valid implementation for a  |= b might be

for each bit in b

   if bit is set

      set corresponding bit in a with "set bit" instruction

No read of a required! Whether that is most optimal code is up to the compiler writer.

Access to registers that require special operation MUST be done with assembler to ensure correct operation, otherwise you are in the alligator infested swamp of "implementation defined behavior".

The thread title should probably read "implementation defined behavior considered harmful", but I think you can easily generalize that to: "C language considered harmful" :)

Edit: volatile must preserve the read and write regardless, because they are observable side-effects.

 donotdespisethesnake wrote:

So I conclude that if sbi is not a read-modify-write operation, then generating an sbi instruction for a volatile memory location is a bug.

theusch wrote:

Perhaps.  A bit of N1256 standard:

    An object that has volatile-qualified type may be modified in ways unknown to the
    implementation or have other unknown side effects. Therefore any expression referring
    to such an object shall be evaluated strictly according to the rules of the abstract machine,
    as described in 5.1.2.3. Furthermore, at every sequence point the value last stored in the
    object shall agree with that prescribed by the abstract machine, except as modified by the
    unknown factors mentioned previously.116) What constitutes an access to an object that
    has volatile-qualified type is implementation-defined.

 

I can't see that anyone found a valid reason for TIMSK0 |= 1; on an AVR8.  Thus it is a "don't care"?

The one way I can imagine it >>might<< be an issue is when developing with the Arduino environment.  There are a multitude of libraries in use out there, some good, some not so much.  Many use interrupts.  Many users may not know the potential issues.  I expect it wouldn't take very long to find a number of threads both here and in the Arduino fora where a user made changes to TIMSKn with a direct assignment, only to find that some other part of their code stopped working.  But I agree that this isn't of primary concern, even though the Arduino may represent a far larger user base and a far larger installed device base than nearly any other.

I latched onto that at first, but it's a puzzling statement because it contradicts the rest of the spec, and even the two preceding sentences. Access is clearly defined in the abstract machine:

The behaviour of the abstract machine, at least insofar as your quoted text reveals, is blind to the notion of volatile.  The section you quote makes no reference to volatile in any way.  The whole notion of volatile was bolted onto the language after the structure of the C language was framed from the perspective of an abstract machine.  It's right there in the first mention of an abstract machine:

In section 5.1.2.3, you find:

1. The semantic descriptions in this International Standard describe the behavior of an
   abstract machine in which issues of optimization are irrelevant.

Volatile is meant to address the issues created by the abstract machine's ignorance of hardware-level details of implementation.  In my view, aspects of the language described in sections of the standard pertaining to the concept of volatile must naturally supersede and potentially contradictory statements made elsewhere, including those pertaining to the abstract machine.

There seems to be no other reading possible.  The text seems clear and unambiguous.  That which constitutes a volatile access (i.e. a read or a write) is implementation defined.  That means an implementation can stipulate that in order for a volatile object to be read it must be sent by the local postal carrier, and that for it to be written it must be ground into a fine paste.  I can't conceive of an implementation or hardware where this stipulation would be useful, but it seems to me the point of the wording is to account for future hardware with characteristics not foreseen by the writers of the language or of the standard. 

Indeed, any phrase in the standard which included the words 'implementation defined' would seem to supersede any previous seemingly contradictory directives.  Volatile itself was introduced into the language specifically as a means to deal with details of hardware implementation with which an abstract machine cannot and should not concern itself.

One must remember that the standard is not the language, nor vice versa.  The language came first.  The standard came later as an attempt to formalise the language.  The situation is akin to music theory.  Nobody decided what was going to constitute Jazz until long after the genre first appeared, was performed, and appreciated for the innovating thing that it was.  Yet there are endless discussions even today about what is and is not Jazz.  It's an academic argument.  That doesn't make it an worthless argument, but it does occur at some distance from the business end of the music itself.   C is the same as any human language.  Language theory attempts to formalise the unregulated process of language evolution.  A computer language may begin life in a more structured way than a spoken language, but the same language processes still apply.  If the standard were the be-all-end-all of the language, then we wouldn't need newly revised standards.  To date, C has seen several.  A language is developed, put into use, and shortcomings are encountered.  Enhancements are conceived, developed, agreed upon, and formalised via a standard.  The newly refined language is put into use, and shortcomings are encountered.  Rinse and repeat.  Volatile is but one example of an agreed-upon formalised enhancement meant to address a previous shortcoming.  Its nature was debated and compromises were reached.

Whether or not my assessment of the wording of the standard is correct, and whether or not you or anyone agrees with it, it seems clear that the notion of volatile is inadequate to the task to which it is being put, i.e. the bit-oriented nature of sbi/cbi.  The notion of a single bit does not exist in C, so to me this is unsurprising.  Ultimately, if you need careful control of hardware-specific access, there is no provision of the C language which can meet that requirement completely.  If there were, it would seem that there wouldn't be such a great variety of compilers which permit some level of integration with assembler.