+- MISRA Discussion Forums (https://forum.misra.org.uk)
+-- Forum: MISRA C (https://forum.misra.org.uk/forumdisplay.php?fid=4)
+--- Forum: MISRA-C: 2004 rules (https://forum.misra.org.uk/forumdisplay.php?fid=17)
+---- Forum: 6.8 Declarations and Definitions (https://forum.misra.org.uk/forumdisplay.php?fid=35)
+---- Thread: Rule #8.7 for "special function registers" and others? (/showthread.php?tid=831)
Rule #8.7 for "special function registers" and others? - gs - 15-06-2011
Does this rule apply to objects which cannot be declared at block scope, like special function register variables?
Re: Rule #8.7 for "special function registers" and others? - misra-c - 20-06-2011
As Rule 8.7 deals with definitions, should the question be
Quote: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?
Re: Rule #8.7 for "special function registers" and others? - Lundin - 22-06-2011
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.
Re: Rule #8.7 for "special function registers" and others? - mishak - 22-06-2011
Quote: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.