no, it sounds reasonable

Maybe. Doing anything with long ints eats cycles like crazy on the '51 architecture, especially bit-shifts. I'll optimize it tomorrow to make better use of the '51.

Here's what the function looks like (from the top of my head, don't have it on my computer at home):

unsigned int sqrt(unsigned long input)
{
  unsigned char i;
  unsigned long remainder = 0;
  unsigned long divisor = 0;

  for(i = 16; i > 0; i--)
  {
    divisor <<= 1;
    remainder = (remainder << 2) + (input >> 30);
    input <<= 2;
    if(divisor < remainder)
    {
      divisor++;
      remainder -= divisor;
      divisor++;
    }
  }
  divisor >>= 1;
  return divisor;
}

On anything that can natively shift 32 bit integers, this should beat the table-lookup-plus-interpolation route easily unless accuracy requirements (table size) is small.

On my '51, some more work might be required. Unrolling the loop and avoiding the shift of input in favor of looking at each byte of input individually should help (the 30 right shifts probably eat cycles like crazy, too). Additionally, divisor will, at most, have 18 significant bits, so for the first 14 iterations only the LSW needs to be shifted (for the first 6, actually, only the LSB).

Of course, doing it in assembly would be a lot faster, since you can do the "shift bit out of A and into B" instead of "shift B left and add A shifted right by 30".