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

[Chris Jones]

For many DSPs, structure field alignment is only part of the problem.

The C5500 family from TI and the Analog Devices SHARC family can't 
run LWIP in it's released form because they lack byte addressing.

The compiler for the C55 defines a 'char' to be 16 bits. A 'char'
on the SHARC is 32 bits.

The best solution for porting LWIP to a DSP that lacks byte addresssing
is to redefine the header structures in terms of the native integer size
and then extract the individual fields with macros in the source.

The current release of LWI does this for most of the IP header, but 
not the TCP header. In my port to the C55, I completed the implemetation
of macros for TCP and got the stack running successfully.

However, the LWIp code also uses byte pointers and byte pointer 
arithmetic and this code also has to be modified.

My port is available at the following link.
http://www.engeniumtech.com/lwip/lwip_dsp.htm

-Chris



-----Original Message-----
From: address@hidden
[mailto:address@hidden
Behalf Of Timmy Brolin
Sent: Tuesday, May 04, 2004 8:18 PM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Struct packing/alignment problems


Leon Woestenberg wrote:

> Given that TCP/IP header fields use natural alignment (alignment
> boundary equals field size), I am now quite convinced that the
> "Ethernet header fix" and proper definition of the uX_t variables
> will work for all architectures.
>
> (I hope the DSP people are reading this and can confirm this). 

Well, obviously it works fine on the C6000 series Texas DSPs with Code 
Composer (the setup I'am using). Code Composer has no pack directives at 
all, and the C6000 DSPs do not support unaligned memory accesses.
The Code Composer environment is the only compiler available for most 
(all?) Texas DSP families, and since Code Composer does not support any 
pack directives at all, anyone currently running lwip on a Texas DSP 
using Code Composer would obviously not have any problem with removed 
PACK_STRUCTs.
I think Texas has a 50% marketshare or so, so this eliminates about half 
of the DSPs out there.

>> guarantees to not pad structs in the way I've described?  The packed
>> attribute specifies that a variable or structure field should have the
>> smallest possible alignment, which seems to me to be exactly what we 
>> want
>
> Packed tells the compiler not to create padding bytes inbetween fields.
> Thus, it always uses 1-byte "alignment", i.e. "align on the next byte
> address". (I will leave bit fields out of this, we do not (want) to 
> use these).
>
> Your choice of words "smallest possible alignment" may still suggest
> "smallest possible natural alignment".
>
>> here.  Maybe it's unnecessary, but we should make sure of that before we
>> go breaking things, and if it's not tightly specified to be as you say,
>> I'd rather leave the packed directives in.  Given that the packed
>
> I would rather remove the pack directives; and have someone come up with
> a problem report if that breaks stuff.
>
> We know how to pack stuff now, even with the #include method (that was
> for a M$ compiler, am I right??), so we can easily revert to this method
> might someone find the unusual subject.
>
>> directives (in lwip) are all macros that can easily be redefined by
>> anyone for whom it causes a problem, I think I've lost sight of what the
>> objection to them was.
>
> Messes up the code unnecessarely. 

Nice and clean code is the holy grail. Or something. :-)

Timmy

> Regards,
>
> Leon.




_______________________________________________
lwip-users mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/lwip-users