Rule #8.7 for "special function registers" and others?

[gs]

Does this rule apply to objects which cannot be declared at block scope, like special function register variables?

[misra-c]

As Rule 8.7 deals with definitions, should the question be

Does this rule apply to objects which cannot be defined at block scope, like special function register variables?

There are a variety of methods by which special function registers might be defined, some (most or even all?) of which will involve language extensions in order to place the register at a particular location in the address space.

Could you please give an example of the kind of definition that you have in mind?

[Lundin]

I think this issue is highly relevant, as you will find such registers in all safety-critical applications. Implementing and accessing them correctly is extremely important to program safety. Perhaps future MISRA-C versions could address how to declare/define such hardware registers explicitly?

In C language utopia, all tools would use the C standard-compatible way to define such registers:

#define PORT (*(volatile uint8_t*)0x1234U)

With this definition, one doesn't need any variable declarations at file scope and one can write fully MISRA-compatible C code for accessing registers:

#define PORT_MASK 0x80U
...
PORT |= PORT_MASK;
PORT &= (uint8_t)~PORT_MASK;

If everyone used this syntax, there wouldn't be any strange non-standard solutions, nor any questionable bit field implementations. So personally, I interpret 8.7 as if it does apply to special registers, because I see no reason why the above syntax can't be used.

So far I haven't heard any convincing arguments why it couldn't be used either. Hardware registers should not be linked so that cannot be the reason for non-standard extensions. I have actually addressed this issue with several tool vendors, and they all replied with some mumble about their debugger being unable to show those registers unless they make non-standard extensions. Why they can't make debuggers that are aware of a specific CPU's register map, without getting it handed to them through debug info files from the compiler, is beyond me.

[mishak]

So far I haven't heard any convincing arguments why it couldn't be used either.

Many micros have registers in a memory space that can't be accessed with a macro unless an extension (typically of the form of a qualifier) is used.

Some also require the use of extensions for efficiency reasons. For example, the 8051 (an many, many derivatives) have bit-addressable locations and registers which cannot be (efficiently) accessed using standards-compliant 'C' code.