srg@quick.com (Spencer Garrett) (09/17/90)
In article <AGLEW.90Sep16115215@dwarfs.crhc.uiuc.edu>, aglew@crhc.uiuc.edu (Andy Glew) writes: > Ie. based on my experience coding in_chksum(), but not having > coded it on a MIPS, I would estimate that the slowdown through not > having carry out and in is approximately 3-fold wrt. good code that > uses carry-out and in. But this is only an upper bound, because > overhead of call, etc., gets in the way. Actually, the upper bound on the MIPS would be a 2-fold increase. All you have to do is compute the checksum 2 bytes at a time and let all the carries accumulate in the upper half of a register. When you get to the end you fold them around to the lower half (twice!) and you're done. I can think of several strategies for improving this figure by some small increment (eg - loop unrolling is likely to be slightly more profitable given that you'll be processing twice as many data items).
aglew@crhc.uiuc.edu (Andy Glew) (09/18/90)
>> Ie. based on my experience coding in_chksum(), but not having >> coded it on a MIPS, I would estimate that the slowdown through not >> having carry out and in is approximately 3-fold wrt. good code that >> uses carry-out and in. But this is only an upper bound, because >> overhead of call, etc., gets in the way. > >Actually, the upper bound on the MIPS would be a 2-fold increase. All >you have to do is compute the checksum 2 bytes at a time and let all >the carries accumulate in the upper half of a register. When you >get to the end you fold them around to the lower half (twice!) and >you're done. I can think of several strategies for improving this >figure by some small increment (eg - loop unrolling is likely to >be slightly more profitable given that you'll be processing twice >as many data items). Yeah, I thought of this just after posting. Most protocols set an upper limit on buffer size, so you don't need to check for overflow from the upper 16 bits. -- Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]