Szymon
> If you do byte by byte construction you do unaligned access too and
> compiler needs to handle it anyway:)
I was referring to C code that accesses a packed structure, not necessarily the
construction part of it. For example: (and in this example I am assuming the
processor can access bytes anywhere, 16-bit values on 16-bit boundaries and
32-bit values on 32-bit boundaries).
struct my_struct
{
uint8_t e8;
uint16_t e16;
uint32_t e32;
} __packed__ /* I know this syntax is wrong, just an example */
struct my_struct my_data
In your C code when you do this: my_data.e32 = 50, what is the compiler going
to do? If the structure is not packed, it knows it can use an instruction that
accesses words. If the structure is packed, well, I guess it is up to the
compiler what to do. In the past, I have seen compilers that add code or call
functions that will check the alignment of e32. If e32 happens to reside on a
4-byte boundary it will use a word instruction; if it happens to reside on a
byte boundary it needs to access the bytes individually to put them in a
register for use.
BTW, you should compile that code for the M0. It would be interesting to see
what the compiler does.
> On Jan 20, 2017, at 9:14 AM, Szymon Janc <[email protected]> wrote:
>
> Hi Will,
>
> On 20 January 2017 at 17:56, will sanfilippo <[email protected]> wrote:
>> 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.
>
> If you do byte by byte construction you do unaligned access too and
> compiler needs to handle it anyway:)
>
>> 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.
>
> Size result I mentioned is from 'newt size' FLASH column. Target is
> nrf52 DK with Cortex M4
> app=@apache-mynewt-core/apps/bletiny
> bsp=@apache-mynewt-core/hw/bsp/nrf52dk
> build_profile=optimized
> cflags=-DSTATS_NAME_ENABLE
>
> So it does reduce ROM usage.
>
>>
>> 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.
>
> Yeap, actually I was thinking on having this wrapped with nice macro
> doing that for us.
>
>>
>> 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.
>
> yeap, if we agreed on using packed structures I'll work on other
> protocols too (including HCI and controller).
>
>
> One note from my side is that having packed structures with meaningful
> members name is much easier to read and understand without
> having to resort to spec. (yes, this is personal opinion:P)
>
>>
>>> 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
>>
>
>
>
> --
> pozdrawiam
> Szymon K. Janc
