> So I looked at wikipedia (I wasn't aware of this algorithm, clever > though), and am still somewhat puzzled by your 'r'. > > What's 'wrong' with their iterative version, or what's better about your > 'r' stuff?
I need to look more carefully, but it looks nifty. Basically, it's avoiding the usual issue of counting the lsbits to factor out a power of 2. Rather than taking out the common factors of 2 a bit at a time, to reduce to the case where one is even and one is odd (i.e. ((a ^ b) & 1) == 1), just find the low-order differing bit and use that instead of "1" in the algorithm. I.e. ((1 ^ b) & r) == r. I have to see if there's a nicer way to arrange things, but it looks good. What I'd like is a better way to automatically configure "divide is slow" from an architecture. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
