[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] [PATCH] fix warning for gcc and possible unaligned acce

From: Timmy Brolin
Subject: Re: [lwip-users] [PATCH] fix warning for gcc and possible unaligned access
Date: Mon, 01 May 2006 12:09:35 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)

Leon Woestenberg wrote:

As Curt mentions, this will surely be sub-optimal, but worst case is
still doing everything run time, AFAICS.

If we can do better, I would like to hear.


I think the current arrangement is probably the best tradeoff there is.
The two byte padding at the beginning of the ethernet header struct in combination with ip_addr2 made sure that the lwip code never accesses a datatype on a alignment less than its natural alignment. When it comes to the packing of structs there is plenty of flexibility. People with compilers which insert more padding than actually neccessary to reach natural alignment can use packing directives to get around that problem. Others can choose to not use the packing directives. Some compilers may generate sub-optimal code when using packing directives, but if the same compilers also inserts more padding than required to get natural alignment of nested structs, then I only see a few options to get that to work in code: 1: Use packing. 2: Replace structs with arrays of U16s. 3: Don't use nested structs. I doubt option 2 would be much more efficient than option 1, and it would make the code unreadable. Option 3 should work, but I think someone said there is a reason ip_addr and ip_addr2 are structs rather than simply U32. I can't remember the reason at the moment.

There might be a fourth option in some cases.. There may be a command line option for some of the ARM compilers to not align nested structs on a 32bit alignment. If there is, then packing would not be neccessary.

Timmy Brolin

reply via email to

[Prev in Thread] Current Thread [Next in Thread]