On 08/31/2016 04:56 AM, Jens Bauer wrote:
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 ?
I would expect it to be easier to issue a warning than to add support
for a whole new type qualifier to the two GCC front ends (C and C++).
The latter, of course, has the advantage of a more robust solution.
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]; /* */
This could be implemented via unnamed bit-fields:
uint32_t: 32;
uint32_t: 32;
/* .. more registers here .. */
};
USART3->ODR = byteToSend;
receivedByte = USART3->IDR;
I'm not sure I understand the purpose of using the union here but
that's probably not important for your proposal.
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 ?
I can't imagine what impact RTTI might have on this. I'd expect
"__attribute__((not_writable))" to map to "const" with no need for
the attribute.
__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.
Understood. I think a write-only attribute or type qualifier would
make sense. Until/unless it's implemented I would recommend to work
around its absence by hiding access to the registers behind a read-
only and write-only functional API.
Martin
