Rule #8.7 for "special function registers" and others?
Moderators: misra-c, david ward
-
- Posts: 87
- Joined: Thu Nov 18, 2004 1:39 am
Rule #8.7 for "special function registers" and others?
Does this rule apply to objects which cannot be declared at block scope, like special function register variables?
-
- Posts: 572
- Joined: Thu Jan 05, 2006 1:11 pm
Re: Rule #8.7 for "special function registers" and others?
As Rule 8.7 deals with definitions, should the question be
Could you please give an example of the kind of definition that you have in mind?
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.Does this rule apply to objects which cannot be defined at block scope, like special function register variables?
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
Posted by and on behalf of
the MISRA C Working Group
-
- Posts: 70
- Joined: Mon Dec 10, 2007 1:57 pm
Re: Rule #8.7 for "special function registers" and others?
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.
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.
-
- Posts: 10
- Joined: Thu Jun 21, 2007 3:58 pm
Re: Rule #8.7 for "special function registers" and others?
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.So far I haven't heard any convincing arguments why it couldn't be used either.
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.