Developing.ru

Сумматоров и сдвигателей, иначе умножение может занимать многие годы. А раз в самом умножении уже есть сдвиг, то действительно зачем дублировать?

Удвоитель, двигать за один раз на все произвольное количество бит - схема сложнее, рисовать ленивее и тогда добавляются ещё 3 входа для правого операнда.

А попробуй ты на одних сумматорах.

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

Absurd пишет именно за этим. Я - не за этим.

Absurd писал(а):Тем не менее, операция сдвига должна выполняться за один такт, так что это не соответствует тому что использовалось начиная с 386-го процессора.

https://ru.wikipedia.org/wiki/Barrel_shifterТак я и нарисовал сдвиг за один такт, это умножение занимает больше. Просто только на один бит, но для умножения этого достаточно. Всё равно ведь правый операнд последовательно пробегает все значения.

Код: Выделить всё

for (i=0, Result=0; i<7; ++i)
{
 Result+=(x<<i)*((y>>i)&1);
}

можно заменить на

Код: Выделить всё

for (Result=0; y!=0; x<<=1, y>>=1)
{
 Result+=x*(y&1);
}

. Но можно и произвольный сдвиг за 1 такт сделать, просто схема позапутанней выйдет. И при чём здесь i80386? Интерпретация CISC системы команд микрокодом RISC ядра появилась позже. НЯЗ с пентиума. И Вы же не будете утверждать, что на том же i80386 умножение занимает больше времени, чем сложение. И по-Вашему же выходит, что и больше, чем сдвиг. Если же делать сдвиг через умножение, используя весь умножитель целиком, то надо сначала по величине сдвига вычислить множитель, накопив произведение нужного количества двоек (так как без рядов ни как иначе степень на получишь, в лучшем случае можно оптимизировать, учтя, что четвертая степень есть квадрат квадрата, восьмая - квадрата четвёртой и так далее), а потом ещё и умножить полученную степень на левый операнд. x<<=2 в этом случае займёт в три раза больше времени, чем умножение, да и то в предположении о нулевых накладных расходах на цикл, чего не бывает. В порядке бреда конечно можно предположить, что микрокод исполняется на более высокой частоте, чем тактовая частота всего процессора, но я не могу себе представить, как это можно было бы реализовать.

Учебник по Computer science Кормана-Лайзерсона-Ривеста, раздел 29.3.1, иллюстрация 29.14 (матричный умножитель). Точно такая же квадратичная зависимость количества необходимых элементов от разрядности операндов как и в barrel shifter-е.

Примерно так:

Сколько сумматоров наберётся в x64? А с явным сдвигом достаточно одного. И одного сдвигателя. Причём, если плюнуть на растактовку сдвига на произвольную величину, то зависимость линейная, а сдвиг не занимает времени больше, чем умножение. Причём, меньшие размеры - это большая частота.