This is the mail archive of the
mailing list for the GCC project.
Re: Proposal: readable and writable attributes on variables
- From: Jens Bauer <jens-lists at gpio dot dk>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 1 Sep 2016 16:40:09 +0200
- Subject: Re: Proposal: readable and writable attributes on variables
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <firstname.lastname@example.org>
On Thu, 1 Sep 2016 15:21:27 +0200, Florian Weimer wrote:
>> So I'd like to propose the following two attributes, which is 'off'
>> by default (eg. read access + write access):
> You can already do this:
> int my_register;
> #define store_my_register(val) (my_register = (val))
> #pragma GCC poison my_register
> And GCC will reject any access to my_register.
I very much appreciate this enlightenment. Thank you. :)
> Is this solution good enough?
It is helpful, I'll try and play a little with it; I'm not thinking about my own needs in this case, though.
I have a few concerns about the above solution:
1: As far as I know, the CMSIS library is not allowed to make use of #pragma (I think this is for compatibility/portability reasons).
2: There are many people working with microcontrollers (ARM/PIC/AVR/others; especially after the Arduino-boom).
These people would want their C code to look like it usually does. ;)
3: There's also another party involved; the chip manufacturer. The chip manufacturer usually provides an IDE (based upon Eclipse with the GCC toolchain and OpenOCD). They build upon CMSIS and they would likely not want to change their library code.
If it was up to me, to decide how to solve it, I think I would want to use typedef and make a type for each of the modes on uint8_t, uint16_t, uint32_t and uint32_t *.
It's not a perfect solution either, because some people are already using __IO, __I and __O in their code. They would be able to quickly switch to a different type, though - but since it might be possible by adding attributes and changing the existing macro, I personally favour this approach.
It would also be easy for developers who write device drivers on platforms like Linux, Windows, Mac, etc. to just prefix their structure members with the macro and then click the "compile" button.
Note: Many copies of the core_cm4.h include files can be found on the net, including this one:
-It contains all the combinations of the permissions in the two structures NVIC_Type and SCB_Type.
The "blank" uint32_t should really be __NA (no access); eg. the reserved fields.
The structures are used in this way:
cpuid = SCB->CPUID; /* this register is only readable, not writable. */
NVIC->STIR = (1 << 3); /* this register is only writable, not readable. */
Some hardware registers behave "strange" compared to how RAM behaves.
Writing a set bit to a status register will clear the bit in the same register. (this does not apply to all status registers; this is just an example on how some status registers behave).