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.
Regards,
Leon.
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.
Regards,
Timmy Brolin
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
