On 29/07/16 10:25, Fredrik Hederstierna wrote:
> Some processor architectures do support bitwise access to memory, eg. ARM
> Cortex-M and 8051 (by ARM called bit-banding).
> In these architectures a single bit can somewhat be addressable, but only as
> an 'aliased' memory region for another memory address.
>
> I noticed that Keil ARMCC compiler now seems to support this huge
> optimization possibility.
> ARMCC mark bit-bandable types as __attribute__((bitband)), then when
> declaring, an reference to bit-banded memory is given.
>
> typedef struct
> {
> char i : 1;
> int j : 2;
> int k : 3;
> } BB __attribute__((bitband));
>
> BB bb __attribute__((at(0x20000004)));
>
> void foo(void)
> {
> bb.i = 1;
> }
>
> Should something similar be possible in GCC, using attributes or similar to
> mark this feature possible to utilize,
> then pick up this at a very late target specific optimization pass that could
> use bit-banding when possible?
> Like eg. a Cortex peephole2 or something similar?
>
> Have anyone maybe already tried to look into this feature in GCC?
> Is it a good idea, or even possible?
>
> Refs:
> http://www.keil.com/support/man/docs/armcc/armcc_chr1359124979689.htm
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/15921.html
> https://answers.launchpad.net/gcc-arm-embedded/+question/228758
>
> Best Regards,
> Fredrik
>
The third link here gives you some indication of the issues involved.
In general, I think it would be a substantial effort for the compiler to
handle the idea that the same object can be changed in different ways at
different addresses. In particular, when changing bitfields the
compiler will read in the old struct, modify it, then write it out
again. If it needs to make another change, it will skip the read - and
may skip the first write too. If some of its modifications are done
using bitband writes, it is going to get out of sync pretty quickly.
