On Monday 02 April 2001  9:39 pm, Richard Earnshaw wrote:
> chris@paradox.demon.co.uk said:
> > I've attached the patch.  If people could take a look and check I've
> > not done  anything really daft (it runs, I'm currently doing a make
> > build with it in  place :) (or if there's anything else I can do :)
> > If it looks ok I'll commit  it.
>
> Is the algorithm that David Seal devised?  If so, I think it would be
> right to credit him with it in a comment.

Yes i think it might be, but I've no idea how to credit him, if I put 
copyright as him then I certainly can't submit it.  My other problem was I 
wasn't too sure it was his, a version of the ffs stuff I've got from way back 
thinks it's his (or finding the number that can be done in 3 arm instr is 
probably his, the algorithm is probably fairly generic)  Does anyone have an 
email or contact details for him?

I'm no legal expert, and certainly don't plan to submit this till it's clear 
who to credit the ffs to.  There are other uses for it, eg libc ffs(), 
libkern ffs(), context switch code has an ffs like routine in it as well

> ! 	orrne	r9, r9, r9, lsl #4	/* X * 0x11 */
> ! 	orrne	r9, r9, r9, lsl #6	/* X * 0x451 */
> ! 	rsbne	r9, r9, r9, lsl #16	/* X * 0x0450fbaf */
> ! 	/* fetch the bit number */
> ! 	ldrneb	r9, [r5, r9, lsr #26 ]
> !
> ! 	/* and loop back */
> ! 	bne 	irqloop
>
> Hmm, five instructions conditionally executed would be slower on all ARM
> chips than branching around the sequence (on StrongARM the limit is two).
> You start the sequence with beq anyway, so why leave these as conditional?

Yep, still got to check that kinda thing (the reason it's still conditional 
was because it was (until I examined it and thought don't be daft branch is a 
win there :) Also some of the comments are blatently wrong :)   that's down 
on my tidy up list to do.

Cheers,
Chris