AVR Freaks

It would be nice if "C" could add more finesse here, so the result could be assured & less compiler dependent

 

Like   PORTA |-rmw= (1<< PA1_FAST) | (1<< PA2_CAR) 

 

So in this example (maybe not the most favorable implementation), the oring of the 2 port bits would be restricted (-rmw) to not using rmw.

In this case, it would use two sbi operations, or whatever the processor offered up to do so.

If the request was not possible, it would flag an error.

 

Maybe the next rev of C will take care of clearing up some of these shortcomings

I'd bet there is a list kept somewhere of pending improvements & proposals.

C - Project status and milestones

I don't think that you need any "new" directive for the language.

PORTB |= (1<< PB4_LED)

PORTA |= (1<< PA1_FAST) | (1<< PA2_CAR)

Looking here It is ambiguous as to whether you will get r-m-w, or whether you will get only writes (sbi instructions)

--------------

 

PORTB |-rmw= (1<< PB4_LED)

PORTA |-rmw= (1<< PA1_FAST) | (1<< PA2_CAR)

Now it becomes clear, the ambiguity is removed

You will not get any rmw, it is being expressly prohibited That is the key difference.

In this case, it will result in 3 sbi instructions being generated

If it cannot be accomplished, you will get an error.

 

PORTB |= (1<< PB4_LED)

This is independent of whether you are trying to clear a flag by writing a 1 to it.

Here, you can simply ensure an sbi is used 

Before you go off espousing changes to a 50-year-old language, perhaps you can digest the content of the thread that I linked to.  Than, if you have something new to present, do it with reference to the "prior art".  Or shall I quote all the pertinent sections of that 5-year-old thread here?  Will you then even read and consider them?

 

In particular:

>>You<<, the author of the code, have instructed the compiler to take the contents of a volatile location, apply some values to that content, and return the new contents to its volatile house.  Now, if you use SBI then one of the bits will be set before another.  Wasn't it you participating in the recent thread on dead time, and trying to draw a distinction between non-overlapping and its synonym?  Surely, then you are ABHORRED at the thought of two SBIs.  In fact, ANY SBI when working with a volatile location.

 

Or are you again setting yourself up as the final authority and sit ex cathedra regardless of the facts?

 

In Embedded C are changes to C99 for CPU and I/O registers, RMW, and address spaces; instruction ordering may be implementation defined.

TR 18037: Embedded C | Project status and milestones

 

Looks like they may be taking my suggestion, at least using their own flavor (#16):

 

Inherent processor-architecture based address spaces are implementation-defined and provided by the compiler for that processor architecture and as such will be available to all applications normally supported by the processor. Examples include accesses to various native data spaces, or data spaces where write and read operations are not symmetrical.

 

I/O register definition for intrinsic or user defined address spaces Input/Output registers may be located within any of the address spaces: either intrinsic address spaces or new address spaces defined by addressmod as part of an application. The _Access modifier provides a means to extend the information associated with the declaration. The _Access modifier has three optional arguments that further may be used to define the access to the variables declared by declaration; these arguments are defined as follows: - access method defines the hardware based access restrictions typically found on Input/Output registers, and is one of read_write, read, write, or read_modify_write; the default is full access (read_modify_write);

Before you go off espousing changes to a 50-year-old language

They do update it slooowly, as they should.  It's actually good to know they are investigating potential changes, not necessarily this one in particular, but overall---to keep honing and improving aspects that have previously been implemented as "workarounds." 

My two cents:

Regardless of the C standard,

when an SBI or a CBI has essentially the same effect as the corresponding RMW,

the compiler has my blessing to generate an SBI or a CBI

In other cases, it does not.

 

That said, getting a desired SBI or CBI should not be hard.

Macros that expand to a line of inline assembly would be good enough.

 

Some statements the compiler should reject altogether:

PINB |= 2;

The compiler is unlikely to generate assembly that accomplishes the assignment.

If it did, the author of the statement would likely be astonished and annoyed.

+1 ;-)

 

Only if your bored and want to get into a debate?

 

 

To each their own?  I suppose  if it bothers you THAT much, move on to something else that meets your specifications?

 

I can remember when I moved from ASM to C and this tutorial was strongly suggested to me:

 

https://www.avrfreaks.net/forum/...

 

Deans first example of setting a bit - or bits as the case may be:

To set bit 0 in foo and then store the result back into foo:

foo = foo | 0x01;

The OR operation is used between the variable that we want to change and a constant which is called a BIT MASK or simply the MASK. The mask is used to identify the bit that we want changed.

Remember that we write the constants in hexadecimal because it's shorter than writing it in binary. It is assumed that the reader knows how to convert back and forth between hex and binary. ;-)

Usually, though the statement is made shorter in real programming practice to take advantage of C's compound assignment:

foo |= 0x01;

This is equivalent to the statement above.

 

TO play fair, I looked at my second source....SmileyMicros C programming for micocontrollers, and in my skimming through the pages, I only found one mention of using '|=' on page 61 in Table 6.

I cannot scan/post the table, but the table lists the operators like |=, +=, &= etc., and Smiley writes about these:

This provides a short cut way to write an expression.

 

 

Does any of this mean anything?  Probably not.  Again, if one does not approve of '|=' or its family members, then find another post to participate in.  Kind of like 4 way junctions.

 

Back under the rock I go.

 

JIm

Note that any [let's call it] generic use isn't the topic here.  Rather, it is when foo is volatile, in particular an AVR volatile I/O location.  See

https://www.avrfreaks.net/forum/...

and other links in the early responses in this thread to start the rehash.

 

A related "problem" case is when the AVR I/O location in question contains I/O event flags that are cleared by writing a 1.  And even more complicated when such IFs are intermingled with other non-IF bits in the same I/O register.

 

I won't bother doing a lot of quoting from the link above.  Read the OP, and then go to

 

...and then see the further discussion.  Pay also attention to what the C standard about volatile.  And then count the angels on the head of the pin.

Should the compiler translate PINB = 2 into an SBI instruction?

That is kind of the point of the philosophical discussion, to me.  Of course you are TELLING the compiler to explicitly do a RMW.  Now, when the compiler optimizes it on an AVR target to an SBI, it is NOT doing the RMW.  That is the question I raised in the OP in the linked thread.  I cannot really disagree with skeeve that [paraphrasing] yeah, it may not be exactly right but our AVR toolchains should probably work that way. Further the C standard of that era says to me that this "volatile" keyword has some implementational leeway.

 

Because your thingie >>is<< an I/O location so it is volatile.  Tell how you implement your two-bit change in machine language. [two bits of change means you get a quarter back, right?]  IN-OR-OUT right?  So a RMW. :) Anyway, an interrupt can hit after the IN and the OUT louses up your thingie.  And if you do an SBI-SBI  then your bridge has shoot-through, right?

 

In the end it is just one of the things to always be careful of.  I've had a couple of introduced I/O races in seemingly innocent code, and they were a bitch to find.