lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] Problem With dns.c Using 32-Bit Compilers


From: Timmy Brolin
Subject: Re: [lwip-users] Problem With dns.c Using 32-Bit Compilers
Date: Fri, 18 Jan 2008 23:34:53 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)

Jonathan Larmour wrote:
Nicolas Pinault wrote:
  
John Keil a écrit :
    
Unfortunately, TI's compiler does not support any kind of structure packing
for their C6000 DSP's (no #pragma pack, or anything similar).  This is
always a bit of a headache when interfacing to other devices, but
fortunately hasn't caused us too many problems with lwIP.  In fact, the
dns.c file is one of the few we have to modify (there are also overlays of
32-bit structures made on non-32-bit aligned arrays in dns.c, which don't
work for us).
      

I'm surprised you don't have trouble elsewhere in lwIP since structure
packing is used extensively in core structures!
  
lwip did cause alot more trouble on C6000 DSPs some time ago. Particularly the 14byte Ethernet header which normally causes all the IP and TCP headers to become completely unaligned in memory.
Fixes were implemented a few years ago when I ported lwip to a C6000 DSP. I heard from someone else who was also porting lwip to C6000 a year or two ago. lwip seems to be quite popular for DSPs :)

Structure packing is indeed used extensively in lwip, but today all structures used in the lwip core are written to be perfectly aligned and the ethernet header can be padded to 16byte to avoid unalignment problems, so structure packing is usually not really required. The compilers will not add any padding anyway.
The problem with these DSP is that whatever the size of the operand, (8,
16 or 32 bits), the compiler allways use 32bit "accesses". This is due
to the fact that these DSPs can manipulate only 32bit registers. Memory
accesses are also only 32bit accesses.
    

Despite the optimal width of memory accesses the C6x does support a load
byte (ldb) instruction (very possibly implemented in silicon as a 32-bit
read with a mask and shift to cope with the memory access constraints).
Either way, it doesn't prevent a compiler supporting a packed structure and
knowing it will have to assume it and all its members are potentially
unaligned.
  
Older DSPs has had very limited support for data widths other than the native width. I think there is actually a DSP or two out there which only supports 24bit data types or something like that.
But the more modern C6000 series has much better support for 8, 16 and 32bit data. It does however not support unaligned access, and the compiler has no support for structure packing. Structure packing would require the compiler to produce ugly code with multiple memory accesses, shifts and bitmasks to avoid unaligned access. So I can understand if TI is a bit reluctant to implement support for it.

Regards,
Timmy Brolin

reply via email to

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