|Subject:||Re: [lwip-devel] new user - Some remarks|
|Date:||Fri, 4 Dec 2009 11:33:13 +0100|
"Mike Kleshov" <address@hidden> wrote: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.
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.
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
|[Prev in Thread]||Current Thread||[Next in Thread]|