lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: John C. Toman
Subject: [lwip-users] Re: [lwip] Anyone Using An Architecture That Isn't little or big endian?
Date: Thu, 09 Jan 2003 00:30:59 -0000

Hi Shaun,

I just tried a bunch of test code and Rod's idea does work. My problem 
was that my htons,etc. implementation was not constant (instead it's an 
inline assembly snippet). So a definition like

#define ETHIP_TYPE  htons(0x0800)

does turn into a constant, as you say, when htons() is a constant. My 
implementation would then be best served by two htons() methods, one as 
a macro that gets optimized down into a constant, and the second would 
be for working on variables (and in my case would be inline assembly).

I'm not sure how much of an impact on total performance it will have -- 
that's part of my impetus for suggesting it. It will have some impact. 
I'm trying to find out how much.

Thanks for the help,

John

Shaun Jackman wrote:

>Having to redefine every constant for each architecture does not sit 
>well with me. Are you certain you can't coerce your compiler to 
>optimise away constants? I thought most every compiler does this.
>
>Rod's code snippet will not produce compiler errors so long as the 
>xtoxx() calls are macros. eg
>       case ntohs( ETHTYPE_IP):
>evaluates to
>       case (ETHTYPE_IP << 8) | (ETHTYPE_IP >> 8):
>which is constant, thus good C.
>
>Unless you're *very* constrained (in code space or time), I would not 
>sweat the little things such as where and how byte swapping is done. 
>I believe it has very little effect on the overall performance of the 
>stack, although I'd be interested to hear if someone disagrees. If 
>the call is implemented as a macro, the majority of calls will be 
>eliminated when they're called on a constant. When the call is on a 
>variable, the function is so simple that the compiler should produce 
>near-perfect assembler.
>
>Cheers,
>Shaun
>
>
>  
>
>>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  ...
>>    
>>
>[This message was sent through the lwip discussion list.]
>  
>




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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]