Дык и так можно

А если маска в R24...R27, то и так тоже


p.s. В любом случае -- это прямой перенос на asm алгоритма, сделанного под C.
Который делалася так, чтобы продемонстрировать идею РПП и получить разумно-быструю функцию для любой архитектуры без необходимости что-то дотачивать (это всё поначалу вообще на AT89C55 гонялось).
На асме можно и по-другому сделать, посмотрите тему в RU.ALGORITHMS -- с чего тема началась. Там «цифра за цифрой», что не очень уобно реализуется на C, но на асме, мне кажется, может позволить частично объединить регистры (как при делении, когда две переменные сдвигаются вместе и частное вдвигается на место делимого).
Кажется, именно такой алгоритм на асме для AVR где-то вте же годы написал Александр Труш, только там из 3-байтового числа корень извлекался.

Сейчас скомпилил в avr-gcc указанный С-шный исходник, так тело цикла 1:1 тому, что я дал выше (начиная от метки loop и заканичая сдвигом mask на два), а вот с организацией цикла он прави не прав одновремённо. У AVR-то регистров немеряно.
Конец цикла он проверяет не по 0 в mask, а тупо по счётчику, так как при данном начальном значении mask и сдвигах на 2 тело цикла будт пройдено 16 раз (кстати, в дів раза меньше, чем при делении 32/32, так что способ извлечения корня y = (x + y/x) / 2, требующий нескольких делений, явно отстаёт). Но он почемуто решил, что счётчик нужно сделать двухбайтовым.
Так что можно ещё так изменить
Ещё тройка тактов в цикле экономится, на всём корне при 16МГц тактовой ещё микросекунды три выиграется. С учётом всех изменений микросекунд в 40 в наихудшем случае влезет. В среднем, думаю, 35.
И именно из этого уже ничего не выжать. Надо смтреть в сторону «цифра за цифрой» (бит за битом), читайте Винокурова в той теме.

Жалко столько регистров использовать )). У меня ж они не только для расчёта используются. Ща проверим быстродействие.
И всё таки какой древний алгоритм, а раз выжил - значит хороший.

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

Программа была переделана по вашим рекомендациям. Скорость расчёта улучшилась с 65 до 35 мкс. Вот конечная версия. На этом можно остановиться, я думаю. Всем большое спасибо.

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.

Подробнее>>

Ну так если регистры очень нужны где-то ещё, то всё равно будет по скорости лучше и по объёму кода не хуже в начале четыре регистра push-нуть, задействовать их для вычислений, потом назад pop-нуть.

Вот глянул первоначальный вариант - там sqr инициализируетя нулями (4*sts = 16байт, но половина из них уйдёт и на инициализацию регистров) потом в цикле дважды считывается (8*lds = 32 байта) и один раз сохраняется (4*sts = 16 байт). По об́ъёму кода это во много раз больше, чем 4*push+4*pop (16байт). Ну а по скорости так само собой. Доп расхода памяи на стек нет, на это уйдёт та память, которая была нужна для временной переменной sqr, причём в другое время этот стек будет для чего-то другого использован.

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Если алгоритм древний, то я тогда какой?

А если это вы автор этого алгоритма, то вы замечательный человек . Надеюсь, вы мне простите тогда, что я заюзал ваши авторские права.

народ мне интересно а если число 33 битное, то какое число нужно записать в mask по первому примеру? Я так догадываюсь что 0x400000000??

Не факт. И, мне почему-то кажется, что исходное число должно иметь чётное количество бит

Число с нечётным числом бит всегда можно превратить в число с чётным их числом, добавив слева нулевой бит

В маске поднят младший бит из самой старшей пары бит.
Для 10-битного числа маска будет 0x100
33-битное число рассматривайте как 34-битное, маска будет 0x100000000ULL

p.s. Маска представляет собой квадрат числа с единственной единичкой. Начальная маска -- квадрат числа с единичкой в старшем разряде (максимального) ожидаемого корня.
Так и получается, что маска прыгает через два бита и всегда в младшем бите из пары.
0x8000 (старшая единичка в 16-битном числе результата) в квадрате давало маску 0x40000000.
Если описания по ссылкам почитать, это должно быть ясно.

Хм я так понимаю у этого алгоритма есть небольшя погрешность?

Народ хелп!! При числе 2С52С0000 и больше выдаёт какую-то хрень((

При целочисленном извлечении корней погрешность будет обязательно, если только аргумент не является точным квадратом.


Стартертопика интересовал 32-битный аргумент. А число 2С52С0000 уже 34-битное.

Алгоритм работает нормально, если какая-то программа выдаёт хрень -- надо искать в ней ошибку.
Раз число вылезло за 32 бита, нужно подправить типы и маску.
И выдача программы:
Всё честно.

Вот делаем маску изначально меньше и ограничиваем маской диапазон входных чисел в 34 бита, куда влезет 2C52C0000 (макс. значение 34-битного входа 3 FFFF FFFF, а с учётом округления алгоритм будет выдавать правильные ответы до 4 0002 0000, но это ему просто повезёт по причине реально 64-битных вычислений):
В последней строке ответ неправильный, но тут уже не выдержан диапазон аргумента, а алгоритм ни при чём.

Блин уже голова трещит....и все равно нифга не канает((

Собственно делаю вычиление: x=sqrt(a^2+b^2+c^2)

Теперь предположим что a=b=c=#F500 --- все нормально, результат правильный(и до него тоже)

А если a=b=c=#F600 () и далее , то все уже фигня выходит((

Маску менял и так и эдак...одна фигня((

Народ поясните подробнее while(mask>>=2)?

Все вопрос решен. Сам даже незнаю как, но все заработало

Это плохо. То, что непонятно как само заработало, с тем же успехо само и перестанет. Кто в доме хозяин?

Че эт перестанет то?! . Уже проверил на всяких разных числах. Просто я чето поменял... и забыл че поменял))

Это и плохо, что забыл Грабли нужно помнить.
В следующий раз при редактировании может нечаянно назад поменяться. Впрочем, тогда и память может освежиться.