• AVR Freaks

Hot!Packed and word-alignement execution time

Author
elberto
Super Member
  • Total Posts : 503
  • Reward points : 0
  • Joined: 2005/05/18 06:35:17
  • Status: offline
2020/04/08 05:17:49 (permalink)
0

Packed and word-alignement execution time

I'm working with dsPIC33 and I have a little doubt:
 
I made following struct:
 
typedef union
    {
       unsigned char v[11];
       struct
       {
 
        INT32 lon; // [deg] x1e-07 Longitude
        INT32 lat; // [deg] x1e-07 Latitude
        INT16 hMSL; // [m] Height above mean sea level
        UINT8 numSV; // satellites
       };
    } s_Satellites_reg;
  
 
It should be 11 bytes long, but in fact it's 12 bytes long.
I need to add __packed__ to make it correctly fit 11 bytes long:
 
typedef union
    {
       unsigned char v[11];
       struct __attribute__((__packed__))
       {
 
        INT32 lon; // [deg] x1e-07 Longitude
        INT32 lat; // [deg] x1e-07 Latitude
        INT16 hMSL; // [m] Height above mean sea level
        UINT8 numSV; // numero satelliti in usati
       };
    } s_Satellites_reg;

 
When accessing (through array or struct fields), will this change execution time?
I mean, regardless of memory size usage, are there differences?
thanks.
#1

10 Replies Related Threads

    du00000001
    Just Some Member
    • Total Posts : 3665
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: Packed and word-alignement execution time 2020/04/08 05:22:31 (permalink)
    +3 (3)
    elberto
    When accessing (through array or struct fields), will this change execution time?
    I mean, regardless of memory size usage, are there differences?
    thanks.

     
    Yes - packing is a silly idea and immediately punished with an increase in execution times.
    If you want to know why: don't ask - just compile one and the other and trace the execution (or just read the asm listings). . . .

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #2
    NKurzman
    A Guy on the Net
    • Total Posts : 18655
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: Packed and word-alignement execution time 2020/04/08 06:20:52 (permalink)
    +2 (2)
    Packing is useful if your transmitting packed structs. Or memory is very limited (maybe too limited)
    #3
    moser
    Super Member
    • Total Posts : 557
    • Reward points : 0
    • Joined: 2015/06/16 02:53:47
    • Location: Germany
    • Status: offline
    Re: Packed and word-alignement execution time 2020/04/08 07:57:06 (permalink)
    +2 (2)
    The alignment of a union or struct is the largest alignment of their members. You have already sorted your members from largest alignment to lowest, which is good. However, you will still get a padding of one byte after "numSV".
     
    If your data is aligned, the compiler can use instructions, which process multiple bytes at once, but only work on aligned data. When using packed, it usually needs to replace such an instruction with several instructions which work byte by byte but can handle unaligned data. Therefore, packing usually raises both execution time and program memory (ROM) usage and only reduces main memory (RAM) usage slightly. If you have that struct as const in program memory, then packing might also save a bit there. But unless you have big const data arrays, the raise of instructions is usually more dominant. 
     
    In most cases it is better to ignore those extra wasted bytes as du00000001 has already described. The exceptions where packing might make sense are mainly those two cases which were already described by NKurzman. But even for sending data you can often still use the aligned structs.
    post edited by moser - 2020/04/08 07:59:13
    #4
    andersm
    Super Member
    • Total Posts : 2796
    • Reward points : 0
    • Joined: 2012/10/07 14:57:44
    • Location: 0
    • Status: online
    Re: Packed and word-alignement execution time 2020/04/08 08:19:25 (permalink)
    +2 (2)
    The compiler must add padding even after the last member so that eg. arrays of structs can work. Without the padding, the elements of the next struct in the array would be misaligned.
    #5
    LdB_ECM
    Super Member
    • Total Posts : 355
    • Reward points : 0
    • Joined: 2019/04/16 22:01:25
    • Location: 0
    • Status: offline
    Re: Packed and word-alignement execution time 2020/04/08 18:16:19 (permalink)
    +1 (1)
    In that exact case it will make almost no difference, look at where the pack byte is.
    If you don't understand do an offsetof for each field in both cases and print it out
    post edited by LdB_ECM - 2020/04/08 18:18:03
    #6
    ric
    Super Member
    • Total Posts : 26942
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: Packed and word-alignement execution time 2020/04/08 18:42:30 (permalink)
    +1 (1)
    LdB_ECM
    In that exact case it will make almost no difference, look at where the pack byte is.
    If you don't understand do an offsetof for each field in both cases and print it out

    ... and as soon as you make an array of these structures, the NEXT item in the array will be on an odd address if the pack byte is not there.
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #7
    LdB_ECM
    Super Member
    • Total Posts : 355
    • Reward points : 0
    • Joined: 2019/04/16 22:01:25
    • Location: 0
    • Status: offline
    Re: Packed and word-alignement execution time 2020/04/08 19:40:44 (permalink)
    +1 (1)
    And if you were needing to do that simply put that struct inside another struct which you array and it will pad and take you back to exactly the unpacked situation :-)
     
    That particular example is not an issue really ... note I am not disputing the situation in more complex examples just that example is trivial and the OP can do it with immunity.
     
    Don't know if it's possible on a PIC but on an ARM the generic cure for the problem if speed is an issue is to use DMA with stride adjustments to align or unalign the data as required.
    post edited by LdB_ECM - 2020/04/08 19:55:33
    #8
    andersm
    Super Member
    • Total Posts : 2796
    • Reward points : 0
    • Joined: 2012/10/07 14:57:44
    • Location: 0
    • Status: online
    Re: Packed and word-alignement execution time 2020/04/08 22:38:09 (permalink)
    +1 (1)
    LdB_ECMIn that exact case it will make almost no difference, look at where the pack byte is.

    If the struct is accessed via a pointer (including arrays), the compiler must assume that the fields are misaligned.
    #9
    moser
    Super Member
    • Total Posts : 557
    • Reward points : 0
    • Joined: 2015/06/16 02:53:47
    • Location: Germany
    • Status: offline
    Re: Packed and word-alignement execution time 2020/04/09 02:27:31 (permalink)
    0
     
    LdB_ECM
    And if you were needing to do that simply put that struct inside another struct which you array and it will pad and take you back to exactly the unpacked situation :-)

    Interesting, although this is of course possible, I didn't expect that the compiler is clever enough do do this kind of optimization in all cases in general. But it (in my case: "it" = "xc32 -O1") can do that, even in cases when you access the fields of inner packed struct by using a volatile pointer to a volatile outer aligned struct. But of course not, if you point to the inner packed struct.
    #10
    LdB_ECM
    Super Member
    • Total Posts : 355
    • Reward points : 0
    • Joined: 2019/04/16 22:01:25
    • Location: 0
    • Status: offline
    Re: Packed and word-alignement execution time 2020/04/09 03:29:11 (permalink)
    0
    It's an old trick passed down thru the ages, at the intermediate assembler stage of the compiler there would be no difference, the layout of the data block is the same and hence it will optimize the same.  
    #11
    Jump to:
    © 2020 APG vNext Commercial Version 4.5