Hi Martin (and everyone else on the gcc list).
I appreciate your input and kind reply to my proposal. :)
On Tue, 30 Aug 2016 20:44:35 -0600, Martin Sebor wrote:
> This sounds reasonable and useful to me but to be fully integrated
> into the language, attribute not_readable would need to be elevated
> to the status of a type qualifier analogous to const. Otherwise it
> would (likely, if applied as most other attributes) be lost during
> conversions such as in
>
> __attribute__ ((not_readable)) int write_only;
> int *preadwrite = &write_only;
Would it not be possible to bring a warning in such cases ?
-or would that actually require a kludge ?
If it's not possible (or if it's too complicated to bring a warning or error),
then I would still find it valuable to have __attribute__((not_writable)) and
__attribute__((not_readable)).
They're intended to be used in structures, which in the CMSIS case would be
something like this:
#define __I volatile __attribute__((not_writable))
#define __O volatile __attribute__((not_readable))
#define __IO volatile
#define __NA __attribute__((not_readable,not_writable)) /* not available or
no access */
typedef struct {
__IO uint32_t SR
union {
__I uint32_t IDR; /* input data register */
__O uint32_t ODR; /* output data register */
};
__NA uint32_t reserved[2]; /* */
/* .. more registers here .. */
};
USART3->ODR = byteToSend;
receivedByte = USART3->IDR;
Normally, __I, __O and __IO are defined as follows in the CMSIS include files:
#ifdef __cplusplus
#define __I volatile /*!< Defines 'read only' permissions */
#else
#define __I volatile const /*!< Defines 'read only' permissions */
#endif
#define __O volatile /*!< Defines 'write only' permissions */
#define __IO volatile /*!< Defines 'read / write' permissions */
-That means for C++, __I does not work entirely as intended; it was probably
done this way due to RTTI.
I believe that in this case an attribute would not have this problem ?
__O can not prohibit reading.
Some hardware registers react upon 'access'; eg. if read, it becomes zero, if
written, only the set bits are changed.
__O currently cannot prevent reading such registers.
I'll wait for a few days and see if there are someone who can find flaws with
the proposal.
Using attribute would be my best suggestion, because it would not change the C
language.
Also, if anyone have improvements to this proposal, please speak up (I'm
interested in the best solution). ;)
Love
Jens
