Hi,
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
wrong!
Cheers,
Hauke
On 27.10.2016 13:35, Martine Lenders wrote:
Hi,
because this discussion came up in one of my (higher level) PRs, too.
2016-10-27 12:33 GMT+02:00 Neil Jones <[email protected]
<mailto:[email protected]>>:
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"
<[email protected] <mailto:[email protected]>>
wrote:
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
drivers.
I don't know about your specific code, but I was able to show, that a
bitfield actually *saves* ROM [1].
Cheers,
Martine
[1] https://github.com/RIOT-OS/RIOT/pull/5866#issuecomment-249801576
_______________________________________________
devel mailing list
[email protected]
https://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
[email protected]
https://lists.riot-os.org/mailman/listinfo/devel
