GNATS-1110: in_cksum_hdr error in PC386 BSP

[Till Straumann]

Joel Sherrill wrote:

> Ralf Corsepius wrote:
>
>> On Wed, 2006-07-05 at 13:47 -0500, Eric Norum wrote:
>>  
>>
>>> I'm beginning to think that we really ought to just switch over to the
>>> C version which was posted with the original problem report.
>>>   
>>
>> I'm inclined to agree. In particular, from my experience, in many cases,
>> GCC is doing a pretty good job at optimizing byte ops etc., and thereby
>> rendering things much easier maintenance-wise.  
>>
FWIW: The asm version (powerpc) is now 14 instructions, the C-version
takes about three times as many (depending on how many times the
loop executes) => space and execution time gain of ~3.

T.

>
> I don't care which version ends up committed -- we just need to close 
> this one before
> the branch is made.
>
>>  
>>
>>>> Till Straumann wrote:
>>>>
>>>>
>>>>     
>>>>
>>>>> I just found another problem with
>>>>> in_cksum_hdr (freebsd mailing list).
>>>>>
>>>>>
>>>>> Currently, (i386, ppc) the algorithm is split into several
>>>>> 'asm' constructs and we assume that the carry bit
>>>>> is preserved across these. This is not a valid assumption,
>>>>> however.
>>>>>       
>>>>
>> This explanation makes sense - I had a gut feeling the explanation might
>> be along these lines, but didn't dare to pronounce it ;)
>>
>>  
>>
>>>> Does their code base have a fixed version?
>>>>
>>>>
>>>>     
>>>>
>>>>> We definitively should try harder to eliminate 'asm'
>>>>>
>>>>>
>>>>>       
>>>>
>>>> Unfortunately, it is a necessary evel.
>>>>     
>>>
>> Really? Did anybody analyze the asm resulting from using the C version
>> of these routines?
>> Unless they perform significantly worse than asm, or unless the asm is
>> eye-strikingly simple (which it had not been), I would not think using
>> asm is still worth it.
>>
>> Ralf
>>
>>
>>  
>>
>