Re: [lwip-devel] new user - Some remarks

[Bastien Allibert]

Hi Mike,David, all,

I also agree with the ANSI C convention for Lwip. I'm just trying to highlight things which are finally (quite) easy to change (casts) and could ease the task of porting lwip to a new target for anybody, especially new users. As David said, depending on the target architecture, such option can lead to a significant change in code density. That's my point of view. 

Regarding the second point (using controller's RAM as a working memory for the microcontroller itself), i understand that this is a bigger change and finally won't make profit for a significant number of users. So it si probably not judicious to make it possible in lwip base. Maybe i can do it on my side, just for this particular device.

Regards,
Bastien

2009/12/3 David Empson <address@hidden>

"Mike Kleshov" <address@hidden> wrote:

Bastien Allibert <address@hidden> wrote:

- first, i have to do back through the ARP code, but i faced some troubles
with an 8-bit data which was left-shifted by 8 when building the ARP
packet... In case integer promotion is enabled, no problem. But when such an
option is cleared, then this becomes a bug. Does this sounds good to you ?

Lwip is written for ANSI C conforming compilers. It doesn't make sense
to try and adapt it to compilers with integer promotion switched off.
Besides, it would only affect low-end 8-bit devices, and they are
hardly capable enough for lwip anyway.

Not just low-end 8-bit devices: our M32C/83 (16-bit integer size with some 32-bit capabilities, 32-bit address space) has more compact and slightly faster code when doing 8-bit arithmetic, so the default for the compiler is to not do promotion to int.

For our original port of LWIP (late 1.1.1) we had the compiler set to use 8-bit arithmetic where possible, because our previous processor/compiler also defaulted to this (and significantly benefited from it). This required trawling through much of the LWIP code and adding explicit typecasts in many places to force integer promotion.

We've recently updated to LWIP 1.3.x (mostly doing a new port rather than updating our existing one), and this time changed the compiler build options to enable integer promotion. This had a small impact on code size but saved us time doing the new port. Unfortunately it created a few new problems elsewhere in our code, where assumptions were being made about the lack of integer promotion. End result is that we've improved our code portability, which is always good.

Overall I agree with LWIP's policy of following the ANSI C convention and expecting integer promotion of 8-bit data.

_______________________________________________
lwip-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-devel