anon (anon@anon.com) on 12/22/11 wrote:
---------------------------
>Wilco (Wilco.Dijkstra@ntlworld.com) on 12/22/11 wrote:
>---------------------------
>>anon (anon@anon.com) on 12/21/11 wrote:
>>---------------------------
>>>Wilco (Wilco.Dijkstra@ntlworld.com) on 12/21/11 wrote:
>>>---------------------------
>>>>Exophase (exophase@gmail.com) on 12/21/11 wrote:
>>>>---------------------------
>>>>>stubar (nothanks@gmail.com) on 12/21/11 wrote:
>>>>>---------------------------
>>>>>>I've always done small to large. Is there a technical reason for large to small?
>>>>>
>>>>>If you go large to small you're guaranteed to stay aligned without padding.
>>>>
>>>>You still get the same amount of tail padding.
>>>>
>>>>Wilco
>>>
>>>That is a pretty archaic way to lay out a data structure. It should be grouped
>>>according to cache line access locality, type, and of false sharing with other CPUs,
>>>etc. Unless you're not using caches or something crazy.
>>
>>Most structs are much smaller than a cache line. If you're thinking about big descriptors
>>like used by OSes then you would indeed layout differently.
>
>For structures where the cache effects are negligible, what is the point in arranging
>small to large? A 12 bit offset could address byte granularity within 4K, no?

It is a simple rule to minimise alignment padding overhead which is why it is commonly used. At small sizes the only issue is codesize with Thumb-1 loads/stores having 5-bit scaled offsets. The offset limit is more relevant for stack and globals where you more often see sizes over 4KB. Note it is more about placing big arrays last, eg. if you place the array last in "int x,arr[2000],y", you can access x, y and &arr[0] using a single base pointer.

Wilco