С делением практически покончено
Apr. 12th, 2019 12:29 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
spamsink posting in ![[community profile]](https://www.dreamwidth.org/img/silk/identity/community.png){kind=small}
besm6Мне удалось избавиться от сравнения абсолютных величин мантисс в первом такте деления (путем дополнительного такта с пробным вычитанием) и от сравнения полноразрядной мантиссы с величиной -0.25; также мне удалось ликвидировать регистр inc2. Это делает алгоритм деления чуть ближе к аутентичному (close, but no cigar, still).
Тест АУ по-прежнему проходит, разумеется, но на тактовую частоту эти изменения повлияли негативно (в частности, раз стало меньше регистров, то увеличилась глубина логики на оставшихся). Несильно, конечно - всё равно больше 120 МГц, но вы мне скажите, имеет ли еще смысл возиться и коммитить, или оставим детям для развлечения?
Использованный в БЭСМ-6 алгоритм деления - двоичный SRT. Тест АУ не видит разницы между выбором 0 в качестве очередной цифры частного при значении остатка в диапазоне -0.25 < x < 0.25 (для строгого сравнения отрицательного числа нужны все разряды) и при -0.125 <= x < 0.25 (тут в обоих случаях достаточно сравнивать 3-4 старших бита мантиссы).
Upd: Проверка случайным тестом показывает, что есть разница между исходным и упрощенным сравнением, которая ухудшает сбалансированность округления, но, увы, тестом АУ не ловится. Так что оставляем как было до поры.
Тест АУ по-прежнему проходит, разумеется, но на тактовую частоту эти изменения повлияли негативно (в частности, раз стало меньше регистров, то увеличилась глубина логики на оставшихся). Несильно, конечно - всё равно больше 120 МГц, но вы мне скажите, имеет ли еще смысл возиться и коммитить, или оставим детям для развлечения?
Использованный в БЭСМ-6 алгоритм деления - двоичный SRT. Тест АУ не видит разницы между выбором 0 в качестве очередной цифры частного при значении остатка в диапазоне -0.25 < x < 0.25 (для строгого сравнения отрицательного числа нужны все разряды) и при -0.125 <= x < 0.25 (тут в обоих случаях достаточно сравнивать 3-4 старших бита мантиссы).
Upd: Проверка случайным тестом показывает, что есть разница между исходным и упрощенным сравнением, которая ухудшает сбалансированность округления, но, увы, тестом АУ не ловится. Так что оставляем как было до поры.
no subject
Date: 2019-04-12 07:43 pm (UTC)120 МГц вполне достаточно для наших целей, я считаю. Надо оставить поле деятельности для энтузиастов.
Мне тут Джером дал книжку по архитектуре CDC 6600. Это был первый в мире суперскалярный процессор. В первом приближении всё то же самое, но есть одно важное отличие. У нас одно АУ, выполняющее все операции. Там несколько независимых АУ, но специализированные: одно для сложения, два для умножения, одно для деления, и отдельно для прочих операций. Каждая операция занимает несколько тактов, как и у нас, но все АУ могут работать одновременно. очередная машинная команда поступает в то АУ, которое ей подходит, и при этом свободно. В результате много команд модут выполняться одновременно.
Можно поставить отдельную задачу переделать мэсм6 на суперскалярную микроархитектуру.
no subject
Date: 2019-04-12 09:25 pm (UTC)CDC хороша тем, что она регистровая, поэтому можно легко раскидывать операции на разные АУ. В БЭСМ-6 без серьёзного переименования регистров, т. е. без фактической двоичной компиляции в регистровую архитектуру в хардвере, так не выйдет.
Интересно было бы выяснить, насколько хорошо удавалось загружать АУ в CDC при тогдашних компиляторах, и насколько хорошо это получалось у ассемблерных программистов.
no subject
Date: 2019-04-12 11:52 pm (UTC)no subject
Date: 2019-04-13 01:51 am (UTC)Тоже интересная мысль. Надо обязательно и её подумать, например, в качестве backend взять самое минимальное ядро типа MIPS/RISC-V (контрольную часть без арифметики) и на базе этого сделать что-то типа core i7 с набором команд БЭСМ :)
no subject
Date: 2019-04-13 03:51 am (UTC)no subject
Date: 2019-04-13 01:47 am (UTC)Думаю, что из-за того что практически всегда каждая следующая арифметическая операция зависит от результата предыдущей, суперскалярность просто не получить. Видимо, поэтому ушли в векторность на том этапе развития машин. А с изобретением RISC уже ушли в суперскалярность.
no subject
Date: 2019-04-15 06:31 pm (UTC)Вот тут на странице 135: https://drive.google.com/drive/u/0/folders/1qILSqIlTt3nIS07JFQjvd2SF_6GpDUYi
Позже придумали переименование регистров, и с ним оказалось возможным совместить суперскалярность с регистровой архитектурой. Тот же Интел так делает.
no subject
Date: 2019-04-16 08:38 pm (UTC)no subject
Date: 2019-04-16 08:56 pm (UTC)Количество регистров в АУ уменьшилось до практического минимума.
Из широких регистров остались только сумматор, РМР и рельса.
no subject
Date: 2019-04-16 10:56 pm (UTC)no subject
Date: 2019-04-16 11:02 pm (UTC)no subject
Date: 2019-04-17 12:03 am (UTC)Путь показывает такой (из списка выбраны сигналы, на что-то похожие):
Total path delay (propagation time + setup) of 12.503 is 7.761(62.1%) logic and 4.742(37.9%) route.
no subject
Date: 2019-04-17 12:14 am (UTC)Кажется, я вижу циклическую зависимость в комбинационной логике.
В этом всё дело.
assign Uaddr = Mi + (r_add ? Mr : Vaddr);
assign Mr = M[m_ra];
wire [14:0] m_ra = ... (sel_mr == `SEL_MR_UA) ? Uaddr : ...;
Команда J+M нехорошо сделана. Надо подумать.
no subject
Date: 2019-04-17 04:35 am (UTC)no subject
Date: 2019-04-17 01:26 am (UTC)Попробуй сейчас глянуть критический путь.
no subject
Date: 2019-04-17 05:01 am (UTC)Total path delay (propagation time + setup) of 9.805 is 7.190(73.3%) logic and 2.615(26.7%) route.
Следующий путь в полтора раза короче.
В отличие от БЭСМ-6, где нужен был флаг C_ACTIVE из-за выбранной схемы входа/выхода из прерывания, мы можем просто манипулировать регистром C, обнуляя после каждой обычной команды, и прятать/восстанавливать его, когда надо.
no subject
Date: 2019-04-17 05:44 am (UTC)Я сделал c_active из соображения, что сбрасывать один бит легче, чем все пятнадцать. Но может быть это копеечная экономия.