[lwip-users] Re: [lwip] Anyone Using An Architecture That Isn't little or big endian?

[John C. Toman]

Hi Rod,

Thanks for the input. This looks like a good idea, but the compiler I'm 
using would then insert byte-swapping code for each use of ETHTYPE_ARP 
or ETHTYPE_IP, and it wouldn't be optimized out, and it ends up being 
more code than the current approach. Would other C compilers really 
optimize this away? Anyways, this particular code snippet would produce 
compile errors in any C compiler since a case statement must contain a 
constant. It would compile with an if then else statement, but might 
result in two byte swaps taking place instead of one  ...

Regards,

John

Rod Boyce wrote:

>Might I be so bold as to suggest another approach which would be befinical for 
>some of the more common tests and would eliminate the need to htons in the 
>'C'code fragment you detail below.
>htons and htonl are defines if I remember correctly so this will works well.  
>But instead of performing the htons on the variable that will take up code 
>space perform the htons on the constant in the case statment.  This whould 
>then be removed from the code either by the pre-processor or the peep hole 
>optomiser.  This would then mean that for every comparision with a constant 
>the constans is already in the correct format for the machine and does not 
>need a seperate set of constants for each type of endian.  I would suggest 
>changing the code fragment below to look like this:
>
><etherarp.h>
>#define ETHTYPE_ARP (htons(0x0806))
>#define ETHERTYPE_IP (htons(0x0800))
>
><ethernetif.c>
>    switch(ethhdr-type){
>        case ETHTYPE_IP:
>
>I beleive the rest is obvious this makes the code eaiser to read and from my 
>experance in multi-platform code anything to make the code easier to read is 
>a good thing and should be promoted.
>
>I have seen this done with a lot of comerical IP stacks for multi-platforms.
>
>Regards,
>Rod Boyce.
>
>
>On Mon, 19 Aug 2002 12:04, John C. Toman wrote:
>  
>
>>Just checking. I'm considering writing and submitting code which would
>>eliminate many unnecessary byte swaps for little endian architectures,
>>specifically for code constants, without affecting big endian
>>architectures. I'm planning on making changes at least for my system and
>>will contribute them back to the lwIP tree if others are interested. For
>>instance, consider:
>>
>>Currently in lwIP (one example from etharp.h):
>>
>>#define ETHTYPE_ARP 0x0806
>>#define ETHTYPE_IP  0x0800
>>
>>When these are used, they must be byte-swapped in the little endian case
>>(from ethernetif.c):
>>
>>    switch(htons(ethhdr->type)) {
>>    case ETHTYPE_IP:
>>      arp_ip_input(netif, p);
>>      pbuf_header(p, -14);
>>      netif->input(p, netif);
>>      break;
>>    case ETHTYPE_ARP:
>>      p = arp_arp_input(netif, ethernetif->ethaddr, p);
>>      if(p != NULL) {
>>        low_level_output(ethernetif, p);
>>        pbuf_free(p);
>>      }
>>      break;
>>
>>With a #ifdef for LITTLE_ENDIAN systems in the header files, this
>>example would become:
>>
>>etharp.h:
>>
>>#ifdef LITTLE_ENDIAN
>>#  define ETHTYPE_ARP 0x0608
>>#  define ETHTYPE_IP  0x0008
>>#else
>>#  define ETHTYPE_ARP 0x0806
>>#  define ETHTYPE_IP  0x0800
>>#endif
>>
>>Then the code piece in ethernetif.c loses the htons() call, saving code
>>and execution time in the little endian case without harming the big
>>endian case:
>>
>>    switch(ethhdr->type) {
>>    case ETHTYPE_IP:
>>      arp_ip_input(netif, p);
>>      pbuf_header(p, -14);
>>      netif->input(p, netif);
>>      break;
>>    case ETHTYPE_ARP:
>>      p = arp_arp_input(netif, ethernetif->ethaddr, p);
>>      if(p != NULL) {
>>        low_level_output(ethernetif, p);
>>        pbuf_free(p);
>>      }
>>      break;
>>
>>My thinking was that dozens of htons, htonl, ntohs and ntohl calls in
>>lwIP could be eliminated this way or in similar ways, resulting in
>>cleaner code, as well as smaller code size and increased performance for
>>little endian systems.
>>
>>The one drawback I can see to this approach is if there are other
>>architectures that store bytes differently than little or big endian,
>>they would need to come up with their own constants that represent the
>>network-storage format on their systems ...
>>
>>Regards,
>>
>>John
>>
>>
>>[This message was sent through the lwip discussion list.]
>>    
>>
>
>[This message was sent through the lwip discussion list.]
>  
>




[This message was sent through the lwip discussion list.]