С делением практически покончено

[spamsink]

Мне удалось избавиться от сравнения абсолютных величин мантисс в первом такте деления (путем дополнительного такта с пробным вычитанием) и от сравнения полноразрядной мантиссы с величиной -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: Проверка случайным тестом показывает, что есть разница между исходным и упрощенным сравнением, которая ухудшает сбалансированность округления, но, увы, тестом АУ не ловится. Так что оставляем как было до поры.

Comments

[vak]

Залез в исходники выяснить детали, но inc2 всё ещё здесь. Ты не заслал правки пока, наверное.

120 МГц вполне достаточно для наших целей, я считаю. Надо оставить поле деятельности для энтузиастов.

Мне тут Джером дал книжку по архитектуре CDC 6600. Это был первый в мире суперскалярный процессор. В первом приближении всё то же самое, но есть одно важное отличие. У нас одно АУ, выполняющее все операции. Там несколько независимых АУ, но специализированные: одно для сложения, два для умножения, одно для деления, и отдельно для прочих операций. Каждая операция занимает несколько тактов, как и у нас, но все АУ могут работать одновременно. очередная машинная команда поступает в то АУ, которое ей подходит, и при этом свободно. В результате много команд модут выполняться одновременно.

Можно поставить отдельную задачу переделать мэсм6 на суперскалярную микроархитектуру.

[spamsink]

Я не заслал правки, потому что стало "хуже", а изменения слишком разрозненные, чтобы делать `ifdef.

CDC хороша тем, что она регистровая, поэтому можно легко раскидывать операции на разные АУ. В БЭСМ-6 без серьёзного переименования регистров, т. е. без фактической двоичной компиляции в регистровую архитектуру в хардвере, так не выйдет.

Интересно было бы выяснить, насколько хорошо удавалось загружать АУ в CDC при тогдашних компиляторах, и насколько хорошо это получалось у ассемблерных программистов.

[vak]

Действительно, стековая архитектура сильно ограничивает возможности распаралелливания. Вот почему БЭСМ-10 планировалась больше как регистровая машина, хотя и с сохранением совместимости.

[x86128]

Тоже как-то давно читал про CDC-шный scoreboard штука интересная. Я думаю её можно сделать когда сделаем для МЭСМ6 "аппаратную" многопотоковость, что-то типа hyperthreading.

Думаю, что из-за того что практически всегда каждая следующая арифметическая операция зависит от результата предыдущей, суперскалярность просто не получить. Видимо, поэтому ушли в векторность на том этапе развития машин. А с изобретением RISC уже ушли в суперскалярность.

[x86128]

В БЭСМ-6 без серьёзного переименования регистров, т. е. без фактической двоичной компиляции в регистровую архитектуру в хардвере, так не выйдет.

Тоже интересная мысль. Надо обязательно и её подумать, например, в качестве backend взять самое минимальное ядро типа MIPS/RISC-V (контрольную часть без арифметики) и на базе этого сделать что-то типа core i7 с набором команд БЭСМ :)

[spamsink]

Интересным экспериментом, который, наверное, никто не делал, было бы скомпилировать какой-нибудь бенчмарк как для одноадресной машины, т. е. с использованием ровно одного регистра, и посмотреть, насколько хорошо register renaming с этим делом справляется.

[vak]

В этом главная проблема стековой архитектуры, что все вычисления проходят через аккумулятор, и поэтому каждая операция зависит от следующей. Лебедев это осознавал, поэтому в проекте БЭСМ-10 ввели восемь регистров данных (вместо аккумулятора и РМР).

Вот тут на странице 135: https://drive.google.com/drive/u/0/folders/1qILSqIlTt3nIS07JFQjvd2SF_6GpDUYi

Позже придумали переименование регистров, и с ним оказалось возможным совместить суперскалярность с регистровой архитектурой. Тот же Интел так делает.

[spamsink]

Однобитный inc2 я пока всё-таки оставил. Теоретически можно вместо него использовать rmr[40], т.е. знаковый бит РМР, но у нас он сейчас не гасится, и тесты идут; с заменой inc2 на rmr[40] он в конце операции оказывается нулем, и тесты всё равно идут. Согласно документации он должен гаситься, но почему тесты это не проверяют, неясно.

[vak]

Неплохо.
Количество регистров в АУ уменьшилось до практического минимума.
Из широких регистров остались только сумматор, РМР и рельса.

[spamsink]

Ну да. Реально у нас две копии сумматора, но это всё равно меньше, чем в оригинале.

[vak]

При синтезе mesm6_cpu.sv частота получается в районе 50-60 МГц. Можешь глянуть, где там затык?

[spamsink]

Мне для Spartan7 показывает 80, но тоже плоховато.

Путь показывает такой (из списка выбраны сигналы, на что-то похожие):

uop[31] - Uaddr[0] - m_ra[0] - M[3] - Uaddr_axb_3 - Uaddr[3] - m_ra[3] - M[8] - Uaddr_axb_8 - Uaddr_cry_11 - Uaddr[14]

Total path delay (propagation time + setup) of 12.503 is 7.761(62.1%) logic and 4.742(37.9%) route.

[vak]

Спасибо!
Кажется, я вижу циклическую зависимость в комбинационной логике.
В этом всё дело.

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 нехорошо сделана. Надо подумать.

[vak]

Переделал, и кое-что даже упростилось.
Попробуй сейчас глянуть критический путь.

[x86128]

Любопытно, но квартус тоже ругался на наличие циклической зависимости, но я значения не придал. Ввиду неопытности подумал, что такие зависимости всё равно разрываются Д-треиггерами по клоку. И в этом нет ничего страшного, кроме удлинения пути сигнала.

[spamsink]

102 МГц, критический путь по uop[45] - Vaddr_next - stack_mode.

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, обнуляя после каждой обычной команды, и прятать/восстанавливать его, когда надо.

[vak]

Ага, совсем другое дело. Посмотрю, может ещё можно ускорить.

Я сделал c_active из соображения, что сбрасывать один бит легче, чем все пятнадцать. Но может быть это копеечная экономия.