hauke.petersen at fu-berlin.de
Thu Oct 27 15:08:22 CEST 2016
Marinte's example does not use `volatile` fields, this makes it in my
experience even worse...
Anyhow, it still shows, that on Cortex based platforms, the manual
approach is superior in terms of ROM usage (which fits with my
experiences). So especially for register maps (which are completely tied
not only to a platform but to a specific CPU) I see a negative effect
from using named bitfields.
@Neil: yes, I am suggesting (also backed by Martine's example) that
compiler generated code for accessing the bitfeilds is less size
efficient on Cortex-Mx based platforms. But please feel free to prove me
On 27.10.2016 13:35, Martine Lenders wrote:
> because this discussion came up in one of my (higher level) PRs, too.
> 2016-10-27 12:33 GMT+02:00 Neil Jones <neiljay at gmail.com
> <mailto:neiljay at gmail.com>>:
> are you suggesting the compiler generated code for accessing the
> bitfeilds is less size efficient than doing it manually? I would
> be suprised if that was the case ?
> On 27 Oct 2016 08:05, "Hauke Petersen"
> <hauke.petersen at fu-berlin.de <mailto:hauke.petersen at fu-berlin.de>>
> Hi Neil, hi Kees,
> though named bitfields are kind of nice when it comes to code
> readability, they behave very poorly when it comes to code
> size. This is especially true for register maps, as these are
> typically volatile. For this reason, we don't use them in RIOT
> and I strongly advice not to use those.
> As example I was able to save several 100 bytes of ROM when
> removing the named bitfield use from the samr21s peripheral
> I don't know about your specific code, but I was able to show, that a
> bitfield actually *saves* ROM .
>  https://github.com/RIOT-OS/RIOT/pull/5866#issuecomment-249801576
> devel mailing list
> devel at riot-os.org
More information about the devel