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

6.8 Declarations and Definitions

Moderators: misra-c, david ward

Post Reply
gs
Posts: 87
Joined: Thu Nov 18, 2004 1:39 am

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

Post by gs » Wed Jun 15, 2011 8:39 pm

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

misra-c
Posts: 556
Joined: Thu Jan 05, 2006 1:11 pm

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

Post by misra-c » Mon Jun 20, 2011 9:18 am

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?
---
Posted by and on behalf of
the MISRA C Working Group

Lundin
Posts: 70
Joined: Mon Dec 10, 2007 1:57 pm

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

Post by Lundin » Wed Jun 22, 2011 8:40 am

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
Posts: 10
Joined: Thu Jun 21, 2007 3:58 pm

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

Post by mishak » Wed Jun 22, 2011 2:33 pm

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.

Post Reply

Return to “6.8 Declarations and Definitions”