lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] Struct packing/alignment problems


From: Timmy Brolin
Subject: Re: [lwip-users] Struct packing/alignment problems
Date: Mon, 26 Apr 2004 18:12:44 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)

K.J. Mansley wrote:

On Mon, 2004-04-26 at 14:53, address@hidden wrote:
Quoting "K.J. Mansley" <address@hidden>:

On Mon, 2004-04-26 at 11:47, Jani Monoses wrote:
That's alot of work you have done there.
A decent solution to this alignment problem is really needed, because as
it is now, lwip is incompatible with most 32bit embedded CPUs.(!!) (Such
as ARM, TI DSPs, ...)
more correctly incompatible with some compilers. lwip works fine on ARM
using gcc.

Quite.  I wonder if the effort to get lwip to work with the compilers
that currently have problems could be better spent getting the compilers
to work with packed structs!  I doubt this is feasible though, so we are
going to have to address this recurrent problem sooner or later.

Kieran
gcc must do some very weird stuff to get unaligned packed structures to work on ARM.

gcc does weird things full stop!
lwip currently depends highly on compiler specific extensions to compile. Structure packing for unaligned memory access is not ANSI C. Don't blaim the compilers when it is the code that is wrong!

If you can suggest a way to ensure the layout of a struct in ANSI C,
without reducing all structs to byte arrays and so moving the complexity
into the rest of the code, that would be great.  There have been many
suggestions so far on this topic, but none is perfect, so there will
have to be compromise somewhere.  On this issue I think I agree with you
(albeit from a practical standpoint) that we won't get support for
packed structs from all compilers, so we have to provide some means to
work around it.

The core issue is actually not compiler support for packing structs. The core issue is CPU support for unaligned memory accesses. The current lwip will have no problem on any CPU which support unaligned memory accesses. The problem arises when you want to compile lwip for a 32bit CPU without support for unaligned memory accesses. (With the exception for compilers who identifies the alignment problem and automatically split a 32bit field into two 16bit fields) I think we can safely assume that very few compilers do this. I didn't think there were any compiler who did this, but if gcc can make lwip run on Ethernet+ARM (the problem does not exist for SLIP/PPP interfaces) without modifications, then I guess there is at least one.

gcc is not the C language definition, ANSI C is. I believe good code should be written to comply with ANSI C, not gcc. Don't you think? :)

Sometimes, yes, other times no :)  (i.e. There are sometimes good
reasons for using extensions to a language.)

Perhaps. But this is not such a case. Few (if any) compilers have this extra feature, and unaligned memory accesses is simply bad for both portability and performance reasons.

Timmy






reply via email to

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