I have mixed feelings about packed structures. For processors that cannot handle unaligned accesses I have always found that they increased code size. Every access of an element in that structure needs code to determine the alignment of that element. Sure, they save RAM, so if that is what you want then fine, but code size? When you did this code size comparison did you do it on a processor that handles unaligned access? This can also impact the speed at which the code runs although that is rarely an issue.
About reducing copies. I am sure you know this, but folks should be careful doing something like mystruct = (struct mystruct *)om->om_data. You are not guaranteed that the data is contiguous so you better m_pullup first. The controller does byte-by-byte copies and does not use packed structs. If we find that they generally svae code space we can modify that code as well. > On Jan 20, 2017, at 8:21 AM, Christopher Collins <[email protected]> wrote: > > Hi Szymon, > > On Fri, Jan 20, 2017 at 10:21:16AM +0100, Szymon Janc wrote: >> Hi, >> >> I was recently looking on how we could reduce size of SM code. >> So my proposal is to change the way PDUs are parsed and constructed. >> >> Instead of having ble_sm_foo_parse(), ble_sm_foo_write() and ble_sm_foo_tx() >> for parsing and constructing PDU byte by byte we could use packed structures >> for describing PDU and let compiler figure out details related to >> unaligned access. > [...] > > I think that's a great idea. The ATT code does something similar, > though there is probably more work to be done there. In my opinion, > using packed structs for parsing and encoding doesn't just reduce code > size, it also simplifies the code. > > Chris
