БЭСМ-6 HDL

[Alex Loktionoff]

В этой теме хотелось бы собрать знания и опыт реализации БЭСМ-6 на языке описания аппаратуры.

Вопросы по реализации на современных аппаратных платформах Рассыпуха/FPGA/ASIC.

[Alex Loktionoff]

Первое, что я столкнулся когда только попробовал - это сумматор в АЛУ БЭСМ6.

Хотя есть и микросхемы сумматоров с быстрым переносом и в FPGA есть готовые блоки DSP, но все-же они не безразмерные и объединить их хочется как в БЕСМ6 с синхронным переносом за один (короткий!) такт.

И сразу напоролся на грабли - по документации операция сложения в среднем происходит за 9 тактов (да по статистике в среднем 9 переносов если брать случайные числа). Но у меня выходит даже без переносов, на выходе будет значение не раньше чем на 3-ем такте:

1- запись значения в регистр В (и если нужно сброс регистра А) на выходе при это еще старое значение А!

2 - неполное суммирование  A ^ B и формирования переносов (A & B)<<1. В при этом еще не 0 поэтому результат еще не готов.

3 - то-же, что и в 2, только В уже новый 0-вый (у нас самый простой пример без переносов), тут уже формируется сигнал готовности, но доступен он будет на выходе, только в следующем такте!

4 - сумма на выходе сумматора и данные готовы, аккумулятор может в этом такте уже принимать новые данные, поэтому этот так уже не считается.

Вопрос, что я делаю не так?

Вроде идея понятная: 

 - реализовать именно аккумулятор, в который можно либо загрузить значение либо добавить/накопить. так как и команды одноадресные и мультиплексор для выбора значения для В лучше ставить только в одном "плече", там где только быстрая "операция" И, при этом оба  "плеча" И и  XOR по времени прохождения становятся более-менее сбалансированными. И время такта можно сократить до минимума, выжав максимум из железа.

Но:

- почему 3 такта на ровном месте?

- подозреваю, что XOR в "парафазной" логике реализуется быстрее чем обычной с дополнительными инверторами.

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

- а в ASIC-е еще можно городить этажерки мосфетов и склеить   НЕИНЕ в один каскад с задержкой распространения примерно как у И и еще подкорректировать площадь затворов, подгоняя время фронтов чтоб вообще сровнять 1:1 скорости. 

Тогда вопрос как писать HDL код ? Для рассыпухи один, для ASIC другой а для  FPGA вообще третий? А чем нам тогда вообще HDL код на FPGA поможет в разработке ASIC-а если он вообще другой и тайминг другие?

Вот схемка в digit, примерчик аккумулятора, я даже индикаторы пририсовал с права внизу для наглядности:

 

Буду благодарен если меня кто-то просветит.

[Leo B.]

Для простоты, чтобы не надо было учитывать нормализацию, рассмотрим длительность выполнения команды 013 (циклическое сложение). Её длительность в АУ такова: минимальная - 3 такта, средняя - 6 тактов, максимальная - 27 тактов. Из этого следует, что приведение переносов выполнялось 2 раза за такт (27 = 48/2 + 3) благодаря парафазности. На какой смеси тестовых данных у разработчиков получилось, что в среднем для команды 013 нужно 6 приведений переносов (6 = (6-3)*2), а не 9, неясно. 

Массовая цепь сравнения регистра переноса с нулём была асинхронная. Цепи приведения переносов были активны, и могли последние несколько полутактов работать вхолостую, пока не вырабатывался признак окончания переноса, а это могло занимать разное время в зависимости от того, какие разряды в регистре переноса перешли из 1 в 0 последними.

Кстати говоря, в зависимости от того, что мы хотим получить, сначала дизайн может быть полезно иметь на уровне RTL (регистровых передач). На этом уровне всё пишется за один такт, и в явном представлении парафазности пока нет необходимости. На этом уровне написан mesm6. 

Грубо говоря, на Верилоге

always_comb begin

    acc_next = (новое значение сумматора в зависимости от текущей выполняемой команды, изменяющей сумматор, например, acc_reg + input_reg)

    acc_hold = (условие неизменности сумматора на следующем такте, например, если текущая команда не изменяет сумматор, или если БАК пуст, и т. п.)

end

always @(posedge clk) begin

    if (!acc_hold)

        acc_reg <= acc_next;

end

[Leo B.]

Тестирование на случайных данных показало, что среднее количество приведений переносов при сложении 48-битных целых не 9, а даже меньше 6 (5.89):

#include <random>
#include <cstdint>
#include <iostream>

uint64_t getRandomInt64() {
    static std::random_device rd;  // Non-deterministic seed
    static std::mt19937_64 gen(rd());  // 64-bit Mersenne Twister engine
    static std::uniform_int_distribution<uint64_t> dist;

    return dist(gen);
}

int trial() {
        uint64_t sum = getRandomInt64() >> 16;
        uint64_t carry = getRandomInt64() >> 16;
        int steps = 0;
        do {
                uint64_t new_sum, new_carry;
                new_sum = sum ^ carry;
                new_carry = (sum & carry) << 1;
                ++steps;
                sum = new_sum;
                carry = new_carry;
        } while (carry);
        return steps;
}

int main() {
        uint64_t total = 0;
        for (int i = 0; i < 1000000; ++i) {
                total += trial();
        }
        std::cout << "Average " << total / 1000000.0 << '\n';
}

[Alex Loktionoff]

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

Ну если в среднем 9 а минимально 3 то с моей схемой сходиться, значит я на правильном пути. Читать формулы из тех описания БЭСМ сил нету, мне легче заново изобрести...
Вот только сегодня вечером нашел тему "Ардуино БЭСМ-6" где обещали помочь в разъяснении :)

В этой теме и хотелось бы собрать "базу знаний" чтоб написать "almost cycle-accurate" /* чтоб не слишком замахиваться */ симулятор БЭСМ-6 и Э1-КБ в первую очередь для пользовательского режима /* и быстрее получить какой-то полезный инструмент */. 

Меня терзают смутные сомнения что на более чем "almost cycle-accurate" замахиваться при современной стандартной синхронной логике, лучше не надо, иначе где-то что-то порвется.

Красные и синие каскады мне не кажутся такой уж проблемой, можно просто считать что тактовая частота в 2 раза выше. Как я и предполагал в элементной базе БЭСМ при монтажном ИЛИ и парафазный логике реализация XOR может быть по скорости сравнима с AND. Но на FPGA мы и так будем иметь иные времянки... Так что только  "almost cycle-accurate". Но все-равно хотелось бы понимать как это работало.

Вы писали, про регистры АУМ, РС1, РС2,  РП1 , РП2, ВР, ПР, ВРУ, ПРУ, РОМ, РСМ. Можно как-то схематично их соединить, чтоб понять как это связано и еще с БАК? /* а как это описать на HDL уж можно придумать*/ Как реализацию задокументировать это другой вопрос, хотя интересный и трудный. В свое время было закодировано "формулами", которые мало кто может декодировать, теперь есть system verilog, но как я понял описание на нем должно быть разным для разной элементной базы, но как я говорил это уже другой вопрос.

понедельник, 8 сентября 2025 г. в 08:23:33 UTC+2, Leo B.:

[Alex Loktionoff]

воскресенье, 7 сентября 2025 г. в 18:45:37 UTC+2, Leo B.:

Для простоты, чтобы не надо было учитывать нормализацию, рассмотрим длительность выполнения команды 013 (циклическое сложение).

Согласен, вот с нее и начнем.

 

Её длительность в АУ такова: минимальная - 3 такта, средняя - 6 тактов, максимальная - 27 тактов. Из этого следует, что приведение переносов выполнялось 2 раза за такт (27 = 48/2 + 3)

2 раза за такт? Это значит было две стадии конвейера с промежуточной защелкой?

Вот тогда я не понимаю, у меня минимум 3 такта, при одной стадии конвейера, тоесть вообще без конвейеризации.

 

благодаря парафазности. На какой смеси тестовых данных у разработчиков получилось, что в среднем для команды 013 нужно 6 приведений переносов (6 = (6-3)*2), а не 9, неясно. 

 

Массовая цепь сравнения регистра переноса с нулём была асинхронная.

Вот тут у меня прокол, 48ИЛИНЕ в один каскад не удастся реализовать не на одной элементной базе, фронты поплывут... /*  а хочется раскачегарить до предела */

 

Цепи приведения переносов были активны, и могли последние несколько полутактов работать вхолостую, пока не вырабатывался признак окончания переноса, а это могло занимать разное время в зависимости от того, какие разряды в регистре переноса перешли из 1 в 0 последними.

Вот тут не понял от слова совсем, можно сравнить с моей схемой или фрагмент верилога или на пальцах как-то?  

Кстати говоря, в зависимости от того, что мы хотим получить, сначала дизайн может быть полезно иметь на уровне RTL (регистровых передач). На этом уровне всё пишется за один такт, и в явном представлении парафазности пока нет необходимости. На этом уровне написан mesm6. 

Но mesm6 он весь микрокодовый, и реализован на sliced  ALU от AMD, тоесть времянки совсем не те.

  

Грубо говоря, на Верилоге

always_comb begin

    acc_next = (новое значение сумматора в зависимости от текущей выполняемой команды, изменяющей сумматор, например, acc_reg + input_reg)

    acc_hold = (условие неизменности сумматора на следующем такте, например, если текущая команда не изменяет сумматор, или если БАК пуст, и т. п.)

end

always @(posedge clk) begin

    if (!acc_hold)

        acc_reg <= acc_next;

end

Ну это как-то на TLS смахивает, "это-ж не наши методы". Тут мне хотелось бы собрать базу  "almost cycle-accurate"...

[Serge Vakulenko]

On Monday, September 8, 2025 at 11:45:35 AM UTC-7 oxy...@gmail.com wrote:

Но mesm6 он весь микрокодовый, и реализован на sliced  ALU от AMD, тоесть времянки совсем не те.

  

Вы путаете микро-бэсм и мэсм6. 

[Leo B.]

On Monday, September 8, 2025 at 11:33:01 AM UTC-7 oxy...@gmail.com wrote:

Меня терзают смутные сомнения что на более чем "almost cycle-accurate" замахиваться при современной стандартной синхронной логике, лучше не надо, иначе где-то что-то порвется.

Пожалуй. Или всё надо реализовать в стандартных флип-флопах сначала однофазно, потом на posedge/negedge, а когда заработает, тогда можно подумать и о преобразовании в схему "L1L2"  на защёлках.

 

Красные и синие каскады мне не кажутся такой уж проблемой, можно просто считать что тактовая частота в 2 раза выше. Как я и предполагал в элементной базе БЭСМ при монтажном ИЛИ и парафазный логике реализация XOR может быть по скорости сравнима с AND. Но на FPGA мы и так будем иметь иные времянки... Так что только  "almost cycle-accurate". Но все-равно хотелось бы понимать как это работало.

Забудьте пока про времянки, про картинки  со схематикой, про разные реализации между FPGA и ASIC... Рассуждайте исключительно в терминах RTL, пока дизайн на уровне RTL не заработает. 

Вы писали, про регистры АУМ, РС1, РС2,  РП1 , РП2, ВР, ПР, ВРУ, ПРУ, РОМ, РСМ. Можно как-то схематично их соединить, чтоб понять как это связано и еще с БАК? /* а как это описать на HDL уж можно придумать*/ Как реализацию задокументировать это другой вопрос, хотя интересный и трудный. В свое время было закодировано "формулами", которые мало кто может декодировать, теперь есть system verilog, но как я понял описание на нем должно быть разным для разной элементной базы, но как я говорил это уже другой вопрос.

Обилие регистров связано, в частности, с парафазностью. На уровне RTL, например, двойное приведение переносов вполне можно написать без дополнительного регистра - пусть синтезатор строит логику, как сумеет.

Просто берите https://github.com/besm6/mesm6/blob/master/rtl/mesm6_alu.sv, который работает (и потому любые изменения поддаются regression testing), и начинайте делать инкрементные изменения, приводя реализацию к похожей по количеству тактов на АУ БЭСМ-6.

В первую очередь, например, нужно ликвидировать явную операцию умножения. 

Потом все явные сложения-вычитания сумматора нужно превратить в приведение переносов (а также логическое ИЛИ в однократное приведение переносов без сдвига carry - см. разницу в длительности выполнения НТЖ и ИЛИ), и т.п. 
Как там делать многотактные операции путем введения дополнительных состояний автомата, надеюсь, понятно.

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

Leo

[Leo B.]

On Monday, September 8, 2025 at 11:45:35 AM UTC-7 oxy...@gmail.com wrote:

воскресенье, 7 сентября 2025 г. в 18:45:37 UTC+2, Leo B.:

Для простоты, чтобы не надо было учитывать нормализацию, рассмотрим длительность выполнения команды 013 (циклическое сложение).

Согласен, вот с нее и начнем.

 

Её длительность в АУ такова: минимальная - 3 такта, средняя - 6 тактов, максимальная - 27 тактов. Из этого следует, что приведение переносов выполнялось 2 раза за такт (27 = 48/2 + 3)

2 раза за такт? Это значит было две стадии конвейера с промежуточной защелкой?

Вот тогда я не понимаю, у меня минимум 3 такта, при одной стадии конвейера, тоесть вообще без конвейеризации.

Так это нормально. В mesm6, где сумма вырабатывается комбинационно, ее длительность уже 2 такта. Если делать двухрядный код, по-видимому, как раз 3 и получится.

 

благодаря парафазности. На какой смеси тестовых данных у разработчиков получилось, что в среднем для команды 013 нужно 6 приведений переносов (6 = (6-3)*2), а не 9, неясно. 

 

Массовая цепь сравнения регистра переноса с нулём была асинхронная.

Вот тут у меня прокол, 48ИЛИНЕ в один каскад не удастся реализовать не на одной элементной базе, фронты поплывут... /*  а хочется раскачегарить до предела */

 

Цепи приведения переносов были активны, и могли последние несколько полутактов работать вхолостую, пока не вырабатывался признак окончания переноса, а это могло занимать разное время в зависимости от того, какие разряды в регистре переноса перешли из 1 в 0 последними.

Вот тут не понял от слова совсем, можно сравнить с моей схемой или фрагмент верилога или на пальцах как-то?  

Строго говоря, сравнение с нулём делается с помощью монтажного ИЛИ, но я не знаю, были ли в этом ИЛИ на 48 разрядов какие-то дополнительные  усилители, и насколько сбалансировано было это дерево. Но да, по сравнению с любой современной элементной базой эта операция, скорее всего, была относительно более быстрой.  О времянках пока заботиться не надо, всему своё время.

Leo

[Alex Loktionoff]

Её длительность в АУ такова: минимальная - 3 такта, средняя - 6 тактов, максимальная - 27 тактов. Из этого следует, что приведение переносов выполнялось 2 раза за такт (27 = 48/2 + 3)

2 раза за такт? Это значит было две стадии конвейера с промежуточной защелкой?

Вот тогда я не понимаю, у меня минимум 3 такта, при одной стадии конвейера, тоесть вообще без конвейеризации.

Так это нормально. В mesm6, где сумма вырабатывается комбинационно, ее длительность уже 2 такта. Если делать двухрядный код, по-видимому, как раз 3 и получится.

Леонид, можете обьяснить каким образом  "приведение переносов выполнялось 2 раза за такт"?

И что такое "двухрядный код" ?

 

Строго говоря, сравнение с нулём делается с помощью монтажного ИЛИ, но я не знаю, были ли в этом ИЛИ на 48 разрядов какие-то дополнительные  усилители, и насколько сбалансировано было это дерево. Но да, по сравнению с любой современной элементной базой эта операция, скорее всего, была относительно более быстрой.  О времянках пока заботиться не надо, всему своё время.

За времянками я смотрю, чтоб заново воссоздать "almost cycle accurate" архитектуру, потому как в  60х за ними следили и именно из этого родилась архитектура АЛУ и БЭСМ6.   

Leo

На схеме из digit "я его слепила из того что _было_" нет там элементов логики с одним входом шириной в шину :( Попробую на выходных нарисовать в Xilinx ISE /*не знаю года получиться*/

В БЭСМ монтажное ИЛИ не везде можно было использовать, его на шину непосредственно  не повесишь - всю закоротишь. Должны были быть буферы и то сомневаюсь чтоб 48 выходов буферов можно было обеднеть - там должна была быть пирамида. Поэтому один элемент 48ИЛИ у меня надо упростить и кажется я понимаю почему в БЕСМ6 было минимум 3 такта, даже если прибавляешь 0 - 48ИЛИ был только один, только он может быть скомпенсирован/сбалансирован.

[Alex Loktionoff]

вторник, 9 сентября 2025 г. в 00:03:53 UTC+2, Leo B.:

On Monday, September 8, 2025 at 11:33:01 AM UTC-7 oxy...@gmail.com wrote:

Меня терзают смутные сомнения что на более чем "almost cycle-accurate" замахиваться при современной стандартной синхронной логике, лучше не надо, иначе где-то что-то порвется.

Пожалуй. Или всё надо реализовать в стандартных флип-флопах сначала однофазно, потом на posedge/negedge, а когда заработает, тогда можно подумать и о преобразовании в схему "L1L2"  на защёлках.

Вот я в verily ни разу не профи, но что-то мне подсказывает, что нельзя просто так взять и запихнуть любую схему в FPGA. Незрячих там все триггеры двухкаскадные с защёлкиванием по фронту, конечно от LUT-ов есть выводы, в обход триггеров, но все будет только комбинационная логика с гонками фронтов как лавина. На verilog написать можно многое но синтезировать нет, а эффективно и его меньше...

Тут надо как-то стараться портировать/реализовать архитектуру БЭСМ6 "almost cycle-accurate" на современную синхронную элементу базу. 

 

 

Красные и синие каскады мне не кажутся такой уж проблемой, можно просто считать что тактовая частота в 2 раза выше. Как я и предполагал в элементной базе БЭСМ при монтажном ИЛИ и парафазный логике реализация XOR может быть по скорости сравнима с AND. Но на FPGA мы и так будем иметь иные времянки... Так что только  "almost cycle-accurate". Но все-равно хотелось бы понимать как это работало.

Забудьте пока про времянки, про картинки  со схематикой, про разные реализации между FPGA и ASIC... Рассуждайте исключительно в терминах RTL, пока дизайн на уровне RTL не заработает. 

Вот в этой ветке я этого бы не хотел, реализации БЭСМ уже есть и микробам и мэсм6 и работают.

Тут хотелось бы собрать информацию о реальной реализации  архитектуры БЭСМ6 "almost cycle-accurate" на современной синхронной элементной базе. Даже если что-то удасться, то информация здесь останется и будет полезна будущим поколениям.

 

Вы писали, про регистры АУМ, РС1, РС2,  РП1 , РП2, ВР, ПР, ВРУ, ПРУ, РОМ, РСМ. Можно как-то схематично их соединить, чтоб понять как это связано и еще с БАК? /* а как это описать на HDL уж можно придумать*/ Как реализацию задокументировать это другой вопрос, хотя интересный и трудный. В свое время было закодировано "формулами", которые мало кто может декодировать, теперь есть system verilog, но как я понял описание на нем должно быть разным для разной элементной базы, но как я говорил это уже другой вопрос.

Обилие регистров связано, в частности, с парафазностью. На уровне RTL, например, двойное приведение переносов вполне можно написать без дополнительного регистра - пусть синтезатор строит логику, как сумеет.

РС1 РС2 это просто регистры для прямого и инверсного кодов?

 

Просто берите https://github.com/besm6/mesm6/blob/master/rtl/mesm6_alu.sv, который работает (и потому любые изменения поддаются regression testing), и начинайте делать инкрементные изменения, приводя реализацию к похожей по количеству тактов на АУ БЭСМ-6.

В первую очередь, например, нужно ликвидировать явную операцию умножения. 

Сложение, мне кажется процентов на 90 я смогу похоже реализовать.

Есть наметки на умножение.

 

Потом все явные сложения-вычитания сумматора нужно превратить в приведение переносов (а также логическое ИЛИ в однократное приведение переносов без сдвига carry - см. разницу в длительности выполнения НТЖ и ИЛИ), и т.п. 
Как там делать многотактные операции путем введения дополнительных состояний автомата, надеюсь, понятно.

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

Leo

Да интересно, а кто-то знает алгоритм деления БЭСМ6? Хотелось бы уже над этим подумать.

Еще возникает вопрос, хорошо сумматор на 48 бит мы практически знаем как реализовать, а как быть с плавающей запятой? Держать два разных АЛУ /*   и аккумулятора???*/ конечно можно сумматор параметризовать через маски и мультиплексоры, но это же уронит быстродействие чутье не в разы?/*универсальная/реконфигурируемая схема больше и сигналы через нее проходят дольше*/ Как это было в БЭСМ6, наверно экономили и делали универсальный, но были какие-то секреты чтоб где-то срезать углы? Или несколько специализированных  блоков вычислителей "работали" на те-же регистры по монтажному ИЛИ?  

[Alex Loktionoff]

Да смешалось МЭСМ и МикроБЭСМ, но написано что МЭСМ микрокодовый:

https://github.com/besm6/mesm6/wiki/Microarchitecture

"Для реализации устройства управления выбран микропрограммный подход. ПЗУ микрокоманд содержит 512 слов по 36 бит. Регистр UPC задаёт адрес текущей микрокоманды. Биты микрокоманды содержат управляющие сигналы для всех остальных блоков процессора (УУ, АУ), а также адрес следующей микрокоманды для ветвлений."

понедельник, 8 сентября 2025 г. в 20:58:11 UTC+2, serge.v...@gmail.com:

[Serge Vakulenko]

On Tuesday, September 9, 2025 at 12:48:39 PM UTC-7 oxy...@gmail.com wrote:

Да смешалось МЭСМ и МикроБЭСМ, но написано что МЭСМ микрокодовый:

https://github.com/besm6/mesm6/wiki/Microarchitecture

"Для реализации устройства управления выбран микропрограммный подход. ПЗУ микрокоманд содержит 512 слов по 36 бит. Регистр UPC задаёт адрес текущей микрокоманды. Биты микрокоманды содержат управляющие сигналы для всех остальных блоков процессора (УУ, АУ), а также адрес следующей микрокоманды для ветвлений."

Мэсм6 микрокодовый, но sliced ALU там нету. Времянки по любому не те. Восстановить точную микроархитектуру БЭСМ-6 по имеющимся материалам вряд ли возможно.

--Сергей

[Leo B.]

Не путаем устройство управления с арифметическим устройством.

On Tuesday, September 9, 2025 at 12:48:39 PM UTC-7 oxy...@gmail.com wrote:

[Leo B.]

On Tuesday, September 9, 2025 at 9:16:55 AM UTC-7 oxy...@gmail.com wrote:

Так это нормально. В mesm6, где сумма вырабатывается комбинационно, ее длительность уже 2 такта. Если делать двухрядный код, по-видимому, как раз 3 и получится.

Леонид, можете обьяснить каким образом  "приведение переносов выполнялось 2 раза за такт"?

И что такое "двухрядный код" ?

Двухрядный код - это представление N-битного целого числа А двумя N-битными векторами S, C таким образом, что желаемое численное значение А является суммой S + C, при этом конкретные значения Х и У могут быть произвольны.

Однократное приведение переносов - это выполнение операций 

S_next = S_prev ^ C_prev,
C_next = (S_prev & C_prev) << 1

Если реализовать эту логику два раза подряд между регистрами, будет приведение переносов 2 раза за такт.

 

Строго говоря, сравнение с нулём делается с помощью монтажного ИЛИ, но я не знаю, были ли в этом ИЛИ на 48 разрядов какие-то дополнительные  усилители, и насколько сбалансировано было это дерево. Но да, по сравнению с любой современной элементной базой эта операция, скорее всего, была относительно более быстрой.  О времянках пока заботиться не надо, всему своё время.

За времянками я смотрю, чтоб заново воссоздать "almost cycle accurate" архитектуру, потому как в  60х за ними следили и именно из этого родилась архитектура АЛУ и БЭСМ6.   

Это слишком рано. Сначала воссоздаём логику потактно, чтобы максимально приближалось к документации, потом заботимся о физическом представлении.

На схеме из digit "я его слепила из того что _было_" нет там элементов логики с одним входом шириной в шину :( Попробую на выходных нарисовать в Xilinx ISE /*не знаю года получиться*/

Пишите на Верилоге, и всё получится.

 

В БЭСМ монтажное ИЛИ не везде можно было использовать, его на шину непосредственно  не повесишь - всю закоротишь. Должны были быть буферы и то сомневаюсь чтоб 48 выходов буферов можно было обеднеть - там должна была быть пирамида. Поэтому один элемент 48ИЛИ у меня надо упростить и кажется я понимаю почему в БЕСМ6 было минимум 3 такта, даже если прибавляешь 0 - 48ИЛИ был только один, только он может быть скомпенсирован/сбалансирован.

Ну да. Тогда, если/когда заботиться о времянках, можно будет объявить задержку на этой пирамиде несущественной. 

Leo

[Leo B.]

On Tuesday, September 9, 2025 at 9:39:19 AM UTC-7 oxy...@gmail.com wrote:

Пожалуй. Или всё надо реализовать в стандартных флип-флопах сначала однофазно, потом на posedge/negedge, а когда заработает, тогда можно подумать и о преобразовании в схему "L1L2"  на защёлках.

Вот я в verily ни разу не профи, но что-то мне подсказывает, что нельзя просто так взять и запихнуть любую схему в FPGA. Незрячих там все триггеры двухкаскадные с защёлкиванием по фронту, конечно от LUT-ов есть выводы, в обход триггеров, но все будет только комбинационная логика с гонками фронтов как лавина. На verilog написать можно многое но синтезировать нет, а эффективно и его меньше...

Как говорится, "вы не поверите". Умеючи, на FPGA эмулируются даже двунаправленные switch networks, а уж несчастные защёлки просто предусмотрены в конфигурации логического блока - понятное дело, никто не строит защёлки из комбинационной логики. Одним битиком триггер превращается в защёлку. В конце концов можно будет реализовать именно парафазную логику - хотя бы, чтобы посмотреть, на сколько процентов от этого изменится количество логических элементов и задержки. 

Тут надо как-то стараться портировать/реализовать архитектуру БЭСМ6 "almost cycle-accurate" на современную синхронную элементу базу. 

На современной синхронной элементной базе с триггерами можно добиться практически полной аккуратности, за исключением каких-то мелких деталей, связанных с парафазностью, типа нестабильного количества тактов на выполнение команды НТЖ. Просто надо медленно и постепенно избавляться от арифметики в mesm6_alu.

Забудьте пока про времянки, про картинки  со схематикой, про разные реализации между FPGA и ASIC... Рассуждайте исключительно в терминах RTL, пока дизайн на уровне RTL не заработает. 

Вот в этой ветке я этого бы не хотел, реализации БЭСМ уже есть и микробам и мэсм6 и работают.

Тут хотелось бы собрать информацию о реальной реализации  архитектуры БЭСМ6 "almost cycle-accurate" на современной синхронной элементной базе. Даже если что-то удасться, то информация здесь останется и будет полезна будущим поколениям.

Чтобы быть полезной, эта информация должна быть написана на HDL, и когда добрые две трети работы (считая инфраструктуру, конечно) уже сделаны, проще не начинать с нуля, а доделывать имеющееся работающее.

 

Вы писали, про регистры АУМ, РС1, РС2,  РП1 , РП2, ВР, ПР, ВРУ, ПРУ, РОМ, РСМ. Можно как-то схематично их соединить, чтоб понять как это связано и еще с БАК? /* а как это описать на HDL уж можно придумать*/ Как реализацию задокументировать это другой вопрос, хотя интересный и трудный. В свое время было закодировано "формулами", которые мало кто может декодировать, теперь есть system verilog, но как я понял описание на нем должно быть разным для разной элементной базы, но как я говорил это уже другой вопрос.

Обилие регистров связано, в частности, с парафазностью. На уровне RTL, например, двойное приведение переносов вполне можно написать без дополнительного регистра - пусть синтезатор строит логику, как сумеет.

РС1 РС2 это просто регистры для прямого и инверсного кодов?

Нет, это регистр сумматора для каждого из двух полутактов. Соответственно, РП1, РП2 - регистр переносов для каждого из двух полутактов.

  

Просто берите https://github.com/besm6/mesm6/blob/master/rtl/mesm6_alu.sv, который работает (и потому любые изменения поддаются regression testing), и начинайте делать инкрементные изменения, приводя реализацию к похожей по количеству тактов на АУ БЭСМ-6.

В первую очередь, например, нужно ликвидировать явную операцию умножения. 

Сложение, мне кажется процентов на 90 я смогу похоже реализовать.

Есть наметки на умножение.

 

Делать умножение по одному биту за такт просто. Хитрости начинаются тогда, когда хочется сделать как в АУ БЭСМ-6 - по 4 бита за такт, т. е. по два за полутакт. В главном мультиплексоре сумматора был даже предусмотрен сдвиг мантиссы вправо на 4 разряда.

Потом все явные сложения-вычитания сумматора нужно превратить в приведение переносов (а также логическое ИЛИ в однократное приведение переносов без сдвига carry - см. разницу в длительности выполнения НТЖ и ИЛИ), и т.п. 
Как там делать многотактные операции путем введения дополнительных состояний автомата, надеюсь, понятно.

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

Да интересно, а кто-то знает алгоритм деления БЭСМ6? Хотелось бы уже над этим подумать.

Алгоритм деления описан в ТО4, но там опущено детальное описание последнего шага - коррекции при завершении деления, чтобы деление нацело было гарантированно точным. Сейчас деление  и в софтверном эмуляторе, и в mesm6 делается  сдвигом-вычитанием так, чтобы проходили стандартные тесты, но некоторые деления чисел с плавающей точкой всё равно отличаются от реальных в младшем разряде (потому что при честном полноразрядном вычитании при делении нацело нечего корректировать, а в БЭСМ-6 эта коррекция применялась в любом случае, приводя при делении с плавающей точкой к расхождению младшего разряда результата от математически ближайшего значения).
Это стало известно, когда компиляция массива степеней 10, записанных в экспоненциальном виде, не  совпала в точности с этим массивом в двоичном виде на образе диска.

Еще возникает вопрос, хорошо сумматор на 48 бит мы практически знаем как реализовать, а как быть с плавающей запятой? Держать два разных АЛУ /*   и аккумулятора???*/ конечно можно сумматор параметризовать через маски и мультиплексоры, но это же уронит быстродействие чутье не в разы?/*универсальная/реконфигурируемая схема больше и сигналы через нее проходят дольше*/ Как это было в БЭСМ6, наверно экономили и делали универсальный, но были какие-то секреты чтоб где-то срезать углы? Или несколько специализированных  блоков вычислителей "работали" на те-же регистры по монтажному ИЛИ?  

На БЭСМ-6 выбор между "целым" и "плавающим" режимом сумматора делался переключением разряда блокировки нормализации в регистре режимов. Вся арифметическая логика была в единственном экземпляре. Даже странно, что на этом уровне дискуссии это приходится объяснять. :)

Leo

[Alex Loktionoff]

Мэсм6 микрокодовый, но sliced ALU там нету. Времянки по любому не те. Восстановить точную микроархитектуру БЭСМ-6 по имеющимся материалам вряд ли возможно.

--Сергей

Есть понимание существования блоков БАЗ БРЗ УУ БАК АЛУ,  таблица тактов команд причем даже написано в каком блоке сколько тактов проводит! Можно пере-изобрести заново "almost cycle accurate" неизвестно сколько это займет по времени, но задача интересная. Мне кажется что сумматор мне удалось пере-изобрести, попробую выложить последнюю версию после выходных. 

[Alex Loktionoff]

среда, 10 сентября 2025 г. в 01:51:21 UTC+2, Leo B.:

On Tuesday, September 9, 2025 at 9:39:19 AM UTC-7 oxy...@gmail.com wrote:

Пожалуй. Или всё надо реализовать в стандартных флип-флопах сначала однофазно, потом на posedge/negedge, а когда заработает, тогда можно подумать и о преобразовании в схему "L1L2"  на защёлках.

Вот я в verily ни разу не профи, но что-то мне подсказывает, что нельзя просто так взять и запихнуть любую схему в FPGA. Незрячих там все триггеры двухкаскадные с защёлкиванием по фронту, конечно от LUT-ов есть выводы, в обход триггеров, но все будет только комбинационная логика с гонками фронтов как лавина. На verilog написать можно многое но синтезировать нет, а эффективно и его меньше...

Как говорится, "вы не поверите". Умеючи, на FPGA эмулируются даже двунаправленные switch networks, а уж несчастные защёлки просто предусмотрены в конфигурации логического блока -  

понятное дело, никто не строит защёлки из комбинационной логики. Одним битиком триггер превращается в защёлку. В конце концов можно будет реализовать именно парафазную

Можно по-подробней? в каждой ячейке DFF после LUT может быть сконфигурирован как защелка или двухкаскадный по фронту? Это какая FPGA?  Я видимо дал маху купил плату со Spartan6.

 

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

Тут надо как-то стараться портировать/реализовать архитектуру БЭСМ6 "almost cycle-accurate" на современную синхронную элементу базу. 

На современной синхронной элементной базе с триггерами можно добиться практически полной аккуратности, за исключением каких-то мелких деталей, связанных с парафазностью, типа нестабильного количества тактов на выполнение команды НТЖ. Просто надо медленно и постепенно избавляться от арифметики в mesm6_alu.

Забудьте пока про времянки, про картинки  со схематикой, про разные реализации между FPGA и ASIC... Рассуждайте исключительно в терминах RTL, пока дизайн на уровне RTL не заработает. 

Вот в этой ветке я этого бы не хотел, реализации БЭСМ уже есть и микробам и мэсм6 и работают.

Тут хотелось бы собрать информацию о реальной реализации  архитектуры БЭСМ6 "almost cycle-accurate" на современной синхронной элементной базе. Даже если что-то удасться, то информация здесь останется и будет полезна будущим поколениям.

Чтобы быть полезной, эта информация должна быть написана на HDL, и когда добрые две трети работы (считая инфраструктуру, конечно) уже сделаны, проще не начинать с нуля, а доделывать имеющееся работающее.

 

Вы писали, про регистры АУМ, РС1, РС2,  РП1 , РП2, ВР, ПР, ВРУ, ПРУ, РОМ, РСМ. Можно как-то схематично их соединить, чтоб понять как это связано и еще с БАК? /* а как это описать на HDL уж можно придумать*/ Как реализацию задокументировать это другой вопрос, хотя интересный и трудный. В свое время было закодировано "формулами", которые мало кто может декодировать, теперь есть system verilog, но как я понял описание на нем должно быть разным для разной элементной базы, но как я говорил это уже другой вопрос.

Обилие регистров связано, в частности, с парафазностью. На уровне RTL, например, двойное приведение переносов вполне можно написать без дополнительного регистра - пусть синтезатор строит логику, как сумеет.

РС1 РС2 это просто регистры для прямого и инверсного кодов?

Нет, это регистр сумматора для каждого из двух полутактов. Соответственно, РП1, РП2 - регистр переносов для каждого из двух полутактов.

Полутакты - это значит они последовательно соединены? Но тогда не сходиться если делать по два переноса за такт, то в среднем надо будет 3 старт + (6 переносов / 2 за такт) = 6 тактов.

Вы же сами посчитали, что переносов в среднем 6? А в документации говориться 9 тактов, а не полутактов? 

 

  

Просто берите https://github.com/besm6/mesm6/blob/master/rtl/mesm6_alu.sv, который работает (и потому любые изменения поддаются regression testing), и начинайте делать инкрементные изменения, приводя реализацию к похожей по количеству тактов на АУ БЭСМ-6.

В первую очередь, например, нужно ликвидировать явную операцию умножения. 

Сложение, мне кажется процентов на 90 я смогу похоже реализовать.

Есть наметки на умножение.

 

Делать умножение по одному биту за такт просто. Хитрости начинаются тогда, когда хочется сделать как в АУ БЭСМ-6 - по 4 бита за такт, т. е. по два за полутакт. В главном мультиплексоре сумматора был даже предусмотрен сдвиг мантиссы вправо на 4 разряда.

Упс. Я уже начал писать однобитовый, какой конфуз. Спасибо что подсказали.

 

Потом все явные сложения-вычитания сумматора нужно превратить в приведение переносов (а также логическое ИЛИ в однократное приведение переносов без сдвига carry - см. разницу в длительности выполнения НТЖ и ИЛИ), и т.п. 
Как там делать многотактные операции путем введения дополнительных состояний автомата, надеюсь, понятно.

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

Да интересно, а кто-то знает алгоритм деления БЭСМ6? Хотелось бы уже над этим подумать.

Алгоритм деления описан в ТО4, но там опущено детальное описание последнего шага - коррекции при завершении деления, чтобы деление нацело было гарантированно точным. Сейчас деление  и в софтверном эмуляторе, и в mesm6 делается  сдвигом-вычитанием так, чтобы проходили стандартные тесты, но некоторые деления чисел с плавающей точкой всё равно отличаются от реальных в младшем разряде (потому что при честном полноразрядном вычитании при делении нацело нечего корректировать, а в БЭСМ-6 эта коррекция применялась в любом случае, приводя при делении с плавающей точкой к расхождению младшего разряда результата от математически ближайшего значения).
Это стало известно, когда компиляция массива степеней 10, записанных в экспоненциальном виде, не  совпала в точности с этим массивом в двоичном виде на образе диска.

Это интересно, современное деление нацело сдвигом и вычитанием не точное???

Или это все-же артефакт неидеальной коррекции деления в БЭСМ6?

То что я прикидывал действительно имеет точность +/-ULP, я думал, что для БЭСМ6 это нормально.

 

Еще возникает вопрос, хорошо сумматор на 48 бит мы практически знаем как реализовать, а как быть с плавающей запятой? Держать два разных АЛУ /*   и аккумулятора???*/ конечно можно сумматор параметризовать через маски и мультиплексоры, но это же уронит быстродействие чутье не в разы?/*универсальная/реконфигурируемая схема больше и сигналы через нее проходят дольше*/ Как это было в БЭСМ6, наверно экономили и делали универсальный, но были какие-то секреты чтоб где-то срезать углы? Или несколько специализированных  блоков вычислителей "работали" на те-же регистры по монтажному ИЛИ?  

На БЭСМ-6 выбор между "целым" и "плавающим" режимом сумматора делался переключением разряда блокировки нормализации в регистре режимов. Вся арифметическая логика была в единственном экземпляре. Даже странно, что на этом уровне дискуссии это приходится объяснять. :)

Я примерно нарисовал сумматор в котором все пути прохождения сигналов более менее скомпенсированы, если туда еще вcтавлять какие-то дополнительные мультиплексоры (управляемые битами конфигурации), то это увеличит прохождение сигнала на 3 каскада/ключа, что почти 40% В тактах-то мы не проиграем все будет сходиться, только реальная скорость упадет :(

Должно быть 4 режима 

1 сумма всех 48 разрядов с переносом в 1 

2 сумма 41 разрядов /* без нормализации */

3 сумма 42? разрядов  с нормализацией 

4 сумма 7 разрядов порядка

Пока писал, понял, что сумматор неисчерпаем как атом, тут непонятки как нормализацию впихнуть. /* подозреваю, что в БЭСМ наложение маски было через монтажное или, а у нас это будет вентиль, хорошо хоть не мультиплексор*/

Может и режим АЛУ можно как-то без мультиплексора реализовать на одном вентильном каскаде? Надо подумать...

 

Leo

[Leo B.]

On Wednesday, September 10, 2025 at 12:02:14 PM UTC-7 oxy...@gmail.com wrote:

Как говорится, "вы не поверите". Умеючи, на FPGA эмулируются даже двунаправленные switch networks, а уж несчастные защёлки просто предусмотрены в конфигурации логического блока -  

понятное дело, никто не строит защёлки из комбинационной логики. Одним битиком триггер превращается в защёлку. В конце концов можно будет реализовать именно парафазную

Можно по-подробней? в каждой ячейке DFF после LUT может быть сконфигурирован как защелка или двухкаскадный по фронту? Это какая FPGA?  Я видимо дал маху купил плату со Spartan6.

https://gab.wallawalla.edu/~curt.nelson/engr433/xilinx/spartan6%20clbs.pdf Страница 9, на элементах, вырабатывающих выходы  AQ, BQ, CQ, DQ, чётко видно, что они конфигурируются как FF, LATCH, и ещё варианты по мелочи.

Нет, это регистр сумматора для каждого из двух полутактов. Соответственно, РП1, РП2 - регистр переносов для каждого из двух полутактов.

Полутакты - это значит они последовательно соединены? Но тогда не сходиться если делать по два переноса за такт, то в среднем надо будет 3 старт + (6 переносов / 2 за такт) = 6 тактов.

Вы же сами посчитали, что переносов в среднем 6? А в документации говориться 9 тактов, а не полутактов? 

 

См. ещё раз внимательно длительности выполнения команды 013 (СЛЦ) в 9-й части ТО. Длительности выполнения команды в АУ - 3/6/27.

 

Алгоритм деления описан в ТО4, но там опущено детальное описание последнего шага - коррекции при завершении деления, чтобы деление нацело было гарантированно точным. Сейчас деление  и в софтверном эмуляторе, и в mesm6 делается  сдвигом-вычитанием так, чтобы проходили стандартные тесты, но некоторые деления чисел с плавающей точкой всё равно отличаются от реальных в младшем разряде (потому что при честном полноразрядном вычитании при делении нацело нечего корректировать, а в БЭСМ-6 эта коррекция применялась в любом случае, приводя при делении с плавающей точкой к расхождению младшего разряда результата от математически ближайшего значения).
Это стало известно, когда компиляция массива степеней 10, записанных в экспоненциальном виде, не  совпала в точности с этим массивом в двоичном виде на образе диска.

Это интересно, современное деление нацело сдвигом и вычитанием не точное???

Или это все-же артефакт неидеальной коррекции деления в БЭСМ6?

Это артефакт неидеальной коррекции деления.

 

То что я прикидывал действительно имеет точность +/-ULP, я думал, что для БЭСМ6 это нормально.

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

 

Еще возникает вопрос, хорошо сумматор на 48 бит мы практически знаем как реализовать, а как быть с плавающей запятой? Держать два разных АЛУ /*   и аккумулятора???*/ конечно можно сумматор параметризовать через маски и мультиплексоры, но это же уронит быстродействие чутье не в разы?/*универсальная/реконфигурируемая схема больше и сигналы через нее проходят дольше*/ Как это было в БЭСМ6, наверно экономили и делали универсальный, но были какие-то секреты чтоб где-то срезать углы? Или несколько специализированных  блоков вычислителей "работали" на те-же регистры по монтажному ИЛИ?  

На БЭСМ-6 выбор между "целым" и "плавающим" режимом сумматора делался переключением разряда блокировки нормализации в регистре режимов. Вся арифметическая логика была в единственном экземпляре. Даже странно, что на этом уровне дискуссии это приходится объяснять. :)

Я примерно нарисовал сумматор в котором все пути прохождения сигналов более менее скомпенсированы, если туда еще вcтавлять какие-то дополнительные мультиплексоры (управляемые битами конфигурации), то это увеличит прохождение сигнала на 3 каскада/ключа, что почти 40% В тактах-то мы не проиграем все будет сходиться, только реальная скорость упадет :(

Должно быть 4 режима 

1 сумма всех 48 разрядов с переносом в 1 

2 сумма 41 разрядов /* без нормализации */

3 сумма 42? разрядов  с нормализацией 

4 сумма 7 разрядов порядка

Режим (1) - это (2) и (4) с последовательно включенными цепями переноса. Сложение всегда вырабатывает бит переноса из 41 р. При арифметическом сложении нормализация вправо на 1 разряд., если бит переноса не равен 41р, делается безусловно, и это занимает отдельный такт,  так что (3) эквивалентно (2). 

Пока писал, понял, что сумматор неисчерпаем как атом, тут непонятки как нормализацию впихнуть. /* подозреваю, что в БЭСМ наложение маски было через монтажное или, а у нас это будет вентиль, хорошо хоть не мультиплексор*/

Может и режим АЛУ можно как-то без мультиплексора реализовать на одном вентильном каскаде? Надо подумать...

Режим АУ (если последовательно пользоваться БЭСМовскими терминами) влияет не на мультиплексирование, а на конечный автомат. Запускать нормализацию или нет, накладывать потом бит округления или нет.

Leo

[Alex Loktionoff]

среда, 10 сентября 2025 г. в 21:43:21 UTC+2, Leo B.:

On Wednesday, September 10, 2025 at 12:02:14 PM UTC-7 oxy...@gmail.com wrote:

Как говорится, "вы не поверите". Умеючи, на FPGA эмулируются даже двунаправленные switch networks, а уж несчастные защёлки просто предусмотрены в конфигурации логического блока -  

понятное дело, никто не строит защёлки из комбинационной логики. Одним битиком триггер превращается в защёлку. В конце концов можно будет реализовать именно парафазную

Можно по-подробней? в каждой ячейке DFF после LUT может быть сконфигурирован как защелка или двухкаскадный по фронту? Это какая FPGA?  Я видимо дал маху купил плату со Spartan6.

https://gab.wallawalla.edu/~curt.nelson/engr433/xilinx/spartan6%20clbs.pdf Страница 9, на элементах, вырабатывающих выходы  AQ, BQ, CQ, DQ, чётко видно, что они конфигурируются как FF, LATCH, и ещё варианты по мелочи.

Вот это да! Так это такое везение братцы, теперь я спокоен, чего мне боятся...

Спасибо, что поделились.

 

Нет, это регистр сумматора для каждого из двух полутактов. Соответственно, РП1, РП2 - регистр переносов для каждого из двух полутактов.

Полутакты - это значит они последовательно соединены? Но тогда не сходиться если делать по два переноса за такт, то в среднем надо будет 3 старт + (6 переносов / 2 за такт) = 6 тактов.

Вы же сами посчитали, что переносов в среднем 6? А в документации говориться 9 тактов, а не полутактов? 

 

См. ещё раз внимательно длительности выполнения команды 013 (СЛЦ) в 9-й части ТО. Длительности выполнения команды в АУ - 3/6/27.

Как вот где собака порылась: 3, 3 + (6/2), 3 + (48/2)

Леонид, если есть понимание почему 2 стадии, поделитесь пожалуйста.

С одной стороны все может просто, чтоб фазы входа и выхода совпадали.

А с другой стороны, что-то припоминаю регистр просто обратной связью реализовывался на одном "каскаде", если простую обратную связь дополнить комбинаторной логикой, может бы заработало? 

Возникает вопрос, как тогда это реализовывать на обычной синхронной логике DFF по фронтам?  

Мне сумматор удалось реализовать без отдельных DFF состояния: 3,9,51. 

Ели делать двустадийный конвейер, боюсь без автомата с отдельными DFF состояния не обойтись.

Но, если считать 2 наших такта за 1 БЕСМ, то можно просто добавить 3 каскада DFF задержки на входе и дело в шляпе? (3 + 3)/2=3, (3 + 3 +6)/2=6, (3 + 3+48)/2=27 

?

...  

 

Еще возникает вопрос, хорошо сумматор на 48 бит мы практически знаем как реализовать, а как быть с плавающей запятой? Держать два разных АЛУ /*   и аккумулятора???*/ конечно можно сумматор параметризовать через маски и мультиплексоры, но это же уронит быстродействие чутье не в разы?/*универсальная/реконфигурируемая схема больше и сигналы через нее проходят дольше*/ Как это было в БЭСМ6, наверно экономили и делали универсальный, но были какие-то секреты чтоб где-то срезать углы? Или несколько специализированных  блоков вычислителей "работали" на те-же регистры по монтажному ИЛИ?  

На БЭСМ-6 выбор между "целым" и "плавающим" режимом сумматора делался переключением разряда блокировки нормализации в регистре режимов. Вся арифметическая логика была в единственном экземпляре. Даже странно, что на этом уровне дискуссии это приходится объяснять. :)

Я примерно нарисовал сумматор в котором все пути прохождения сигналов более менее скомпенсированы, если туда еще вcтавлять какие-то дополнительные мультиплексоры (управляемые битами конфигурации), то это увеличит прохождение сигнала на 3 каскада/ключа, что почти 40% В тактах-то мы не проиграем все будет сходиться, только реальная скорость упадет :(

Должно быть 4 режима 

1 сумма всех 48 разрядов с переносом в 1 

2 сумма 41 разрядов /* без нормализации */

3 сумма 42? разрядов  с нормализацией 

4 сумма 7 разрядов порядка

Режим (1) - это (2) и (4) с последовательно включенными цепями переноса. Сложение всегда вырабатывает бит переноса из 41 р. При арифметическом сложении нормализация вправо на 1 разряд., если бит переноса не равен 41р, делается безусловно, и это занимает отдельный такт,  так что (3) эквивалентно (2). 

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

Если на пальцах упрощенно 2бита порядок, 1бит знак, 2бита мантисса: //(3) не эквивалентно (2)

(2)

EESMM

00010 +

00010=

----------

00100

EESMM

(3)

EES?MM

000010 +

000010=

----------

000100

EES?MM

 

Пока писал, понял, что сумматор неисчерпаем как атом, тут непонятки как нормализацию впихнуть. /* подозреваю, что в БЭСМ наложение маски было через монтажное или, а у нас это будет вентиль, хорошо хоть не мультиплексор*/

Может и режим АЛУ можно как-то без мультиплексора реализовать на одном вентильном каскаде? Надо подумать...

Режим АУ (если последовательно пользоваться БЭСМовскими терминами) влияет не на мультиплексирование, а на конечный автомат. Запускать нормализацию или нет, накладывать потом бит округления или нет.

Да чую, без автомата и регистра состояния не обойтись даже для простого сумматора.

 

 

Leo

[Leo B.]

On Thursday, September 11, 2025 at 10:29:51 AM UTC-7 oxy...@gmail.com wrote:

 

См. ещё раз внимательно длительности выполнения команды 013 (СЛЦ) в 9-й части ТО. Длительности выполнения команды в АУ - 3/6/27.

Как вот где собака порылась: 3, 3 + (6/2), 3 + (48/2)

Леонид, если есть понимание почему 2 стадии, поделитесь пожалуйста.

С одной стороны все может просто, чтоб фазы входа и выхода совпадали.

Разумеется. 
 

А с другой стороны, что-то припоминаю регистр просто обратной связью реализовывался на одном "каскаде", если простую обратную связь дополнить комбинаторной логикой, может бы заработало? 

Возникает вопрос, как тогда это реализовывать на обычной синхронной логике DFF по фронтам?  

Один вариант - сделать вместо защёлок  DFF-ы. При этом, по-видимому, получатся и "короткие" участки логики между противофазными DFF, и "длинные" участки логики от главной фазы до главной фазы. Если timing engine достаточно умён, он и поймёт этот дизайн, и подберёт нужное соотношение длительностей фаз для достижения максимальной тактовой частоты.

Другой вариант - написать всё на одной фазе (т. е. не будет никаких РС2/РП2, а всё, что делалось за два полутакта, будет делаться комбинационно за один такт). При этом площадь логики, конечно, увеличится, но всё равно должно поместиться, потому что при поразрядной реализации арифметики количество логических элементов там, по современным меркам, смешное.

Мне сумматор удалось реализовать без отдельных DFF состояния: 3,9,51. 

Ели делать двустадийный конвейер, боюсь без автомата с отдельными DFF состояния не обойтись.

Но, если считать 2 наших такта за 1 БЕСМ, то можно просто добавить 3 каскада DFF задержки на входе и дело в шляпе? (3 + 3)/2=3, (3 + 3 +6)/2=6, (3 + 3+48)/2=27 

?

Конечно, если будет получаться "слишком быстро", то замедлить труда не составит. Признаков состояния в АУ хватало; к сожалению, они в описании нигде не перечислены все вместе в качестве вектора состояния конечного автомата, а упоминаются для каждой отдельной операции по ходу дела.

Должно быть 4 режима 

1 сумма всех 48 разрядов с переносом в 1 

2 сумма 41 разрядов /* без нормализации */

3 сумма 42? разрядов  с нормализацией 

4 сумма 7 разрядов порядка

Режим (1) - это (2) и (4) с последовательно включенными цепями переноса. Сложение всегда вырабатывает бит переноса из 41 р. При арифметическом сложении нормализация вправо на 1 разряд., если бит переноса не равен 41р, делается безусловно, и это занимает отдельный такт,  так что (3) эквивалентно (2). 

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

Вы уже прочитали 4-ю часть ТО, хотя бы для общего ознакомления? Там механизм нормализации после сложения описан очень хорошо. И манера изложения в целом очень веселит.

Режим АУ (если последовательно пользоваться БЭСМовскими терминами) влияет не на мультиплексирование, а на конечный автомат. Запускать нормализацию или нет, накладывать потом бит округления или нет.

Да чую, без автомата и регистра состояния не обойтись даже для простого сумматора.

Ничего удивительного, так как он там, в сущности, и был. 

Leo

[Alex Loktionoff]

четверг, 11 сентября 2025 г. в 19:52:17 UTC+2, Leo B.:

On Thursday, September 11, 2025 at 10:29:51 AM UTC-7 oxy...@gmail.com wrote:

 

См. ещё раз внимательно длительности выполнения команды 013 (СЛЦ) в 9-й части ТО. Длительности выполнения команды в АУ - 3/6/27.

Как вот где собака порылась: 3, 3 + (6/2), 3 + (48/2)

Леонид, если есть понимание почему 2 стадии, поделитесь пожалуйста.

С одной стороны все может просто, чтоб фазы входа и выхода совпадали.

Разумеется. 
 

А с другой стороны, что-то припоминаю регистр просто обратной связью реализовывался на одном "каскаде", если простую обратную связь дополнить комбинаторной логикой, может бы заработало? 

Возникает вопрос, как тогда это реализовывать на обычной синхронной логике DFF по фронтам?  

Один вариант - сделать вместо защёлок  DFF-ы. При этом, по-видимому, получатся и "короткие" участки логики между противофазными DFF, и "длинные" участки логики от главной фазы до главной фазы. Если timing engine достаточно умён, он и поймёт этот дизайн, и подберёт нужное соотношение длительностей фаз для достижения максимальной тактовой частоты.

Другой вариант - написать всё на одной фазе (т. е. не будет никаких РС2/РП2, а всё, что делалось за два полутакта, будет делаться комбинационно за один такт). При этом площадь логики, конечно, увеличится, но всё равно должно поместиться, потому что при поразрядной реализации арифметики количество логических элементов там, по современным меркам, смешное.

У меня просто дух захватывает, неужели на моем древнем Спартане6 можно реализовать двухфазную защёлочную конвейеризацию. Производительность по идее должна быть в два раза выше? Я загорелся попробовать сравнить побыстрее. Надо попробовать минимальный сумматор реализовать на DFF и на LATCH и посмотреть тайминги в ISE. /* только ISE не поддерживает system verilog, а Vivado не поддерживает Spartan6 :( */ 

 

Мне сумматор удалось реализовать без отдельных DFF состояния: 3,9,51. 

Ели делать двустадийный конвейер, боюсь без автомата с отдельными DFF состояния не обойтись.

Но, если считать 2 наших такта за 1 БЕСМ, то можно просто добавить 3 каскада DFF задержки на входе и дело в шляпе? (3 + 3)/2=3, (3 + 3 +6)/2=6, (3 + 3+48)/2=27 

?

Конечно, если будет получаться "слишком быстро", то замедлить труда не составит. Признаков состояния в АУ хватало; к сожалению, они в описании нигде не перечислены все вместе в качестве вектора состояния конечного автомата, а упоминаются для каждой отдельной операции по ходу дела.

Но что-то мне подсказывает, что эти три такта в начале не спроста - наверное входные проверки аргументов проходят. 

Должно быть 4 режима 

1 сумма всех 48 разрядов с переносом в 1 

2 сумма 41 разрядов /* без нормализации */

3 сумма 42? разрядов  с нормализацией 

4 сумма 7 разрядов порядка

Режим (1) - это (2) и (4) с последовательно включенными цепями переноса. Сложение всегда вырабатывает бит переноса из 41 р. При арифметическом сложении нормализация вправо на 1 разряд., если бит переноса не равен 41р, делается безусловно, и это занимает отдельный такт,  так что (3) эквивалентно (2). 

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

Вы уже прочитали 4-ю часть ТО, хотя бы для общего ознакомления? Там механизм нормализации после сложения описан очень хорошо. И манера изложения в целом очень веселит.

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

[Alex Loktionoff]

воскресенье, 7 сентября 2025 г. в 10:55:00 UTC+2, Alex Loktionoff:

Первое, что я столкнулся когда только попробовал - это сумматор в АЛУ БЭСМ6.

Как Леонид советовал, рекомендую сначала прочитать: ТО VI часть

2.5 Представление отрицательных мантисс 

            описана замудренная логика переноса из 41-го в 40-ой разряд

            запустил примерчик в dispak-е и выпал в осадок представление отрицательных чисел вроде должно быть в дополнительном коде? А это что?

           4060000000000000 -2

      4020000000000000 -1

      4050000000000000  1

      4110000000000000  2 

 2.6 Нормализация

           написано что мантисса результата может быть в диапазоне -2 <= (m + m)< 2. Это означает что 40-й бит это не 1 а 2-ка? Условия кода 11.0ХХ и 00.1ХХ  из 2.6 это про биты [2][1].[1/2][1/4][1/8][...]? и мы должны 40 бит "резервировать" на случай переполнения? тогда точность получается не 40 бит а 39, разве не так? Н и как-то опять с dispak-oм не сходиться выше.

2.7 Двухрядный код

         как Вы и говорили.

         интересный момент в конце - говориться что элементы XOR и AND  трехвходовые и можно начинать сложение не дожидаясь окончания переносов предыдущего, вот это реально ускоряет умножение!  Это очень интересно реализовать.

2.10 Переполнение и "нулевой результат" 

          описывается "нулевая яма" - все денормализованные результаты насильно заменяются "машинным 0" - все биты 0-вые 

3.1 Блок схема

          вид с птичьего полета, но помогает воссоздать реальную архитектуру:

          БАК - FIFO комманд для всего АЛУ

          АУМ - АЛУ мантиссы

          АУП - АЛУ порядков //я полагал реализовать все масками, но если их разделить может получиться проще

          УУАУ - реализация  FSM всего АЛУ

          УКАК - "устройство контроля" - прерывания по переполнению и т.п. непонятно почему с боку припеку а не часть FSM

          ---внешние блоки с которыми АЛУ соеденено---

          БРУС == БРЗ/БАЗ - Кеш данных БРЗ - значение БАЗ - адрес

          УУ - устройство управления там индексные регистры //и декодер команд процессора БЭСМ6?

          УВУ - устройсво ввода вывода - пичалька вот это не хотелось бы эмулировать, ввод вывод реализовать как-то поэффективней и без магнитных барабанов

3.3 БАК

          интересная подробность - FIFO состоит из 4-х регистров команд по  17бит //может помочь в реверсинге 

3.7 Типы операций

         биты 17,16, 9,8 задают тип операции  

         есть информация что что-то длится два такта, что-то полтора а что то один //полезно для реверсинга

         общем кладезь премудрости 

 3.8 Информационная структура кода команды

        17-бит ==0 -> 16ый признак МС операции биты 15-1 операнд

        17 и 16 бит == 0 -> 9 бит 1 признак НАК 15-10 код операции 7-1 операнд

        17 и 16 бит == 0 -> 8 бит 1 признак "запись"   7бит ==0  БРУС 7бит == 1 УКАУ

         17 и 16 бит == 0 -> 8  и 9 бит ==0 признак "чтение" 15-10 код операции 6-1 адрес БРУСа 

         17 бит == 1 -> УВУ 12бит 1 чтение 0 запись 11-1 адрес УВУ

  3.9-3.15 Краткое описание регистров АЛУ

   ...пропускаю...

 IУ. Выполнение операций

        самое мясо. хоть и очень кратко, описывается последовательность состояний автомата АЛУ для команд АЛУ

  4.15 Арифметическое умножение

        да описывается хитрое умножение 2х2 бита: если 0 на 0 пропуск если 1 - то выдаем Х если 2 то 2Х если 3 то выдаем -Х и запоминаем чтоб добавить 1 (тоесть 4) для следующего шага умножения 2х2

        РИС4.1 блок схема умножителя - весма подробно //полезно для реверсинга

4.16 Арифметическое деление

        без восстановления остатка 

        делитель может быть только нормализованным числом т.е. только плавающая запятая

страница 60-79 подробные схемы АЛУ - может возможно 100% восстановить на верилоге        

[Leo B.]

On Friday, September 12, 2025 at 2:46:37 PM UTC-7 oxy...@gmail.com wrote:

2.5 Представление отрицательных мантисс 

            описана замудренная логика переноса из 41-го в 40-ой разряд

            запустил примерчик в dispak-е и выпал в осадок представление отрицательных чисел вроде должно быть в дополнительном коде? А это что?

           4060000000000000 -2

      4020000000000000 -1

      4050000000000000  1

      4110000000000000  2 

Что не так-то? Например, минус единица - это 100_000_0/10_000 ... (между восьмеричными цифрами подчерки, между порядком и мантиссой слеш) - т. е поле порядка равно 64 (следовательно, порядок равен 64-64 == 0), мантисса читается как 41-разрядное целое в дополнительном коде, деленное на 2^40, т. е. является -2^40 / 2^40 == -1. Итого -1.
 

 2.6 Нормализация

           написано что мантисса результата может быть в диапазоне -2 <= (m + m)< 2. Это означает что 40-й бит это не 1 а 2-ка? Условия кода 11.0ХХ и 00.1ХХ  из 2.6 это про биты [2][1].[1/2][1/4][1/8][...]? и мы должны 40 бит "резервировать" на случай переполнения? тогда точность получается не 40 бит а 39, разве не так? Н и как-то опять с dispak-oм не сходиться выше.

Там написано с учётом невидимого временного дополнительного (42-го) знакового бита. Условие отсутствия переполнения - когда знаковые биты (дополнительный и настоящий) равны.

2.7 Двухрядный код

         как Вы и говорили.

         интересный момент в конце - говориться что элементы XOR и AND  трехвходовые и можно начинать сложение не дожидаясь окончания переносов предыдущего, вот это реально ускоряет умножение!  Это очень интересно реализовать.

ЕМНИП, у какой-то операции есть случай, когда для младшего бита имеется аж 4 слагаемых. Тогда одно из них на такт придерживается, и подается на вход после первого шага приведения.
 

2.10 Переполнение и "нулевой результат" 

          описывается "нулевая яма" - все денормализованные результаты насильно заменяются "машинным 0" - все биты 0-вые 

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

          УВУ - устройсво ввода вывода - пичалька вот это не хотелось бы эмулировать, ввод вывод реализовать как-то поэффективней и без магнитных барабанов

Как раз диски и барабаны - самое простое и эффективное. Терминалы (пока мы не восстановим код для работы с аппаратурой сопряжения) и АЦПУ будут проблематичнее. 
 

4.16 Арифметическое деление

        без восстановления остатка 

        делитель может быть только нормализованным числом т.е. только плавающая запятая

Да, иначе или очень медленно было бы, или FSM заметно усложнилась бы из-за необходимости уникальной пре-нормализации операнда на входном регистре влево (в остальных операциях пре-нормализация, если нужна, то вправо, а влево - пост-нормализация результата). Проще обязать программиста нормализовать делитель самостоятельно отдельной командой, когда известно, что делитель - целое.

 

[Michael Yaroslavtsev]

On Fri, Sep 12, 2025 at 2:46 PM Alex Loktionoff <oxy...@gmail.com> wrote:

...

          УВУ - устройсво ввода вывода - пичалька вот это не хотелось бы эмулировать, ввод вывод реализовать как-то поэффективней и без магнитных барабанов

Роль АУ тут минимальна. Операция 033 аналогична считыванию/записи.

11 разрядов Аисп передпются в УВУ.

В зависимости от 12-го разряда Аисп,

• '0': 24 младших рр. кода на сумматоре передаётся в УВУ
• '1': 24 разрядя принимаются из УВУ на ВР.

 

--

Thanks,
-- Michael

[Michael Yaroslavtsev]

On Fri, Sep 12, 2025 at 2:46 PM Alex Loktionoff <oxy...@gmail.com> wrote:

...

          БРУС == БРЗ/БАЗ - Кеш данных БРЗ - значение БАЗ - адрес

БРУС += БРЧ

--

Thanks,
-- Michael

[Leo B.]

On Friday, September 12, 2025 at 4:47:34 PM UTC-7 BOPOHOK wrote:

On Fri, Sep 12, 2025 at 2:46 PM Alex Loktionoff <oxy...@gmail.com> wrote:

...

          БРУС == БРЗ/БАЗ - Кеш данных БРЗ - значение БАЗ - адрес

БРУС += БРЧ

Аналогично, БРУС  -= БАЗ. БАЗ и БАС были в УУ, они там нужнее.

Не припомнишь, что было в нижнем ряду ТЭЗов БРУС? 
Там ничего достаточно крупным шрифтом не подписано.
https://upload.wikimedia.org/wikipedia/commons/c/cd/BESM-6_Politech_Museum_Moscow.jpg

[Michael Yaroslavtsev]

On Fri, Sep 12, 2025 at 5:18 PM Leo B. <leo...@gmail.com> wrote:

On Friday, September 12, 2025 at 4:47:34 PM UTC-7 BOPOHOK wrote:

On Fri, Sep 12, 2025 at 2:46 PM Alex Loktionoff <oxy...@gmail.com> wrote:

...

          БРУС == БРЗ/БАЗ - Кеш данных БРЗ - значение БАЗ - адрес

БРУС += БРЧ

Аналогично, БРУС  -= БАЗ. БАЗ и БАС были в УУ, они там нужнее.

Не припомнишь, что было в нижнем ряду ТЭЗов БРУС? 

МГРП + ГРП. 

Там ничего достаточно крупным шрифтом не подписано.
https://upload.wikimedia.org/wikipedia/commons/c/cd/BESM-6_Politech_Museum_Moscow.jpg

--
Данное сообщение отправлено Вам, как участнику группы "БЭСМ-6":
http://groups.google.com/group/besm6/topics
---
Вы получили это сообщение, поскольку подписаны на группу "БЭСМ-6".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес besm6+un...@googlegroups.com.
Чтобы посмотреть обсуждение, перейдите по ссылке https://groups.google.com/d/msgid/besm6/c75b04c3-f911-4686-b6b5-a07b7162f224n%40googlegroups.com.

--

Thanks,
-- Michael

[Alex Loktionoff]

 

суббота, 13 сентября 2025 г. в 01:32:18 UTC+2, Leo B.:

On Friday, September 12, 2025 at 2:46:37 PM UTC-7 oxy...@gmail.com wrote:

2.5 Представление отрицательных мантисс 

            описана замудренная логика переноса из 41-го в 40-ой разряд

            запустил примерчик в dispak-е и выпал в осадок представление отрицательных чисел вроде должно быть в дополнительном коде? А это что?

           4060000000000000 -2

      4020000000000000 -1

      4050000000000000  1

      4110000000000000  2 

Что не так-то? Например, минус единица - это 100_000_0/10_000 ... (между восьмеричными цифрами подчерки, между порядком и мантиссой слеш) - т. е поле порядка равно 64 (следовательно, порядок равен 64-64 == 0), мантисса читается как 41-разрядное целое в дополнительном коде, деленное на 2^40, т. е. является -2^40 / 2^40 == -1. Итого -1.

Да, днем действительно сходиться :)  

2e65 == -2

2e64 == -1

1e65 == 1

1e66 == 2

 ночью мне казалось, что -2 это 643777777777777, но похоже это одно и тоже, только нормализировать долго надо.

 2.6 Нормализация

           написано что мантисса результата может быть в диапазоне -2 <= (m + m)< 2. Это означает что 40-й бит это не 1 а 2-ка? Условия кода 11.0ХХ и 00.1ХХ  из 2.6 это про биты [2][1].[1/2][1/4][1/8][...]? и мы должны 40 бит "резервировать" на случай переполнения? тогда точность получается не 40 бит а 39, разве не так? Н и как-то опять с dispak-oм не сходиться выше.

Там написано с учётом невидимого временного дополнительного (42-го) знакового бита. Условие отсутствия переполнения - когда знаковые биты (дополнительный и настоящий) равны.

Вот чуяло мое сердце, что нужен 42 бит, только в документе его незаметно, там только есть какая-то странная логика переноса из 41-го в 40-ой.

Еще в АЛУ порядка есть дополнительный бит знака порядка, это Вы не перепутали? 

 

2.7 Двухрядный код

         как Вы и говорили.

         интересный момент в конце - говориться что элементы XOR и AND  трехвходовые и можно начинать сложение не дожидаясь окончания переносов предыдущего, вот это реально ускоряет умножение!  Это очень интересно реализовать.

ЕМНИП, у какой-то операции есть случай, когда для младшего бита имеется аж 4 слагаемых. Тогда одно из них на такт придерживается, и подается на вход после первого шага приведения.

С трехвходовыми элементами по прикидкам с однобитовым умножением работает очень шустро. Максимум где -то 41+41, а на малых числах где-то тактов 16 т.е. по ощущениям всего в два раза медленней чем сумма! А если брать по два бита за раз, трудно представить, и это на однобитовых по сути АЛУ! 

 

Я уже думаю над двухбитным умножением, при умножении на 11 там на сумматор видимо посылается операция вычитания /* 11 = 100 - 1*/, но вычитание это сложение с инверсией и еще +1, что как минимум два полутакта - что-то сомневаюсь что таким образом удавалось что-то экономить в тактах.

Не проще ли сейчас реализовать: 

00 - сдвигаем на два бита

01 - сдвигаем на два бита и выдаем Х на сумматор

10 - сдвигаем на два бита и выдаем Х сдвинутый в право

11 - сдвигаем на один бит и выдаем Ч на сумматор

По тактам не то-же выйдет как и с вычитанием?

 

2.10 Переполнение и "нулевой результат" 

          описывается "нулевая яма" - все денормализованные результаты насильно заменяются "машинным 0" - все биты 0-вые 

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

Мне бы сейчас сообразить как все это реализовать чтоб по тактам совпадало.

Если по тактам совпадет тогда уже будем думать.

 

 

          УВУ - устройсво ввода вывода - пичалька вот это не хотелось бы эмулировать, ввод вывод реализовать как-то поэффективней и без магнитных барабанов

Как раз диски и барабаны - самое простое и эффективное. Терминалы (пока мы не восстановим код для работы с аппаратурой сопряжения) и АЦПУ будут проблематичнее. 

Я все про такты, это уму не растяжимо, и сколько тактов должна быть такая команда на верилоге, я пока в непонятках? 

 

... 

[Leo B.]

On Saturday, September 13, 2025 at 9:06:39 AM UTC-7 oxy...@gmail.com wrote:

 

 2.6 Нормализация

           написано что мантисса результата может быть в диапазоне -2 <= (m + m)< 2. Это означает что 40-й бит это не 1 а 2-ка? Условия кода 11.0ХХ и 00.1ХХ  из 2.6 это про биты [2][1].[1/2][1/4][1/8][...]? и мы должны 40 бит "резервировать" на случай переполнения? тогда точность получается не 40 бит а 39, разве не так? Н и как-то опять с dispak-oм не сходиться выше.

Там написано с учётом невидимого временного дополнительного (42-го) знакового бита. Условие отсутствия переполнения - когда знаковые биты (дополнительный и настоящий) равны.

Вот чуяло мое сердце, что нужен 42 бит, только в документе его незаметно, там только есть какая-то странная логика переноса из 41-го в 40-ой.

Еще в АЛУ порядка есть дополнительный бит знака порядка, это Вы не перепутали? 

Написано же внизу страницы, озаглавленной "2.6 Нормализация", Для того, чтобы результат с мантиссой |m| > 1 (до нормализации) не приводил к потере знака, некоторые регистры арифметического устройства имеют два разряда слева от запятой.

С трехвходовыми элементами по прикидкам с однобитовым умножением работает очень шустро. Максимум где -то 41+41, а на малых числах где-то тактов 16 т.е. по ощущениям всего в два раза медленней чем сумма! А если брать по два бита за раз, трудно представить, и это на однобитовых по сути АЛУ! 

 

Минимальное время выполнения умножения в АУ (при выключенной нормализации и грубо говоря, при умножении на 0 или степень двойки, когда гарантированно нет никаких переносов, требующих приведения), согласно документации  - 15 тактов. Это 3 стандартных такта  на обработку операции в АУ + ceil(41/4) = 11 тактов на сдвиг-сложение множителя , и, видимо, ещё 1 на первоначальную установку регистров, специфичную для умножения.

В среднем умножение требует 18 тактов, т. е. 15 + (в среднем 6 приведений переносов)/2. При умножении нормализованных чисел с плавающей точкой завершающая нормализация влево обычно не требуется, при умножении целых она блокирована, а умножение числа с плавающей точкой на целое, видимо, сочтено достаточно редким, и не влияет на среднее.

 

Я уже думаю над двухбитным умножением, при умножении на 11 там на сумматор видимо посылается операция вычитания /* 11 = 100 - 1*/, но вычитание это сложение с инверсией и еще +1, что как минимум два полутакта - что-то сомневаюсь что таким образом удавалось что-то экономить в тактах.

Удавалось. Случай четырех слагаемых в младшем разряде описан, начиная с конца страницы 43 PDF. Там несколько сложнее, чем мне помнилось.

 

          УВУ - устройсво ввода вывода - пичалька вот это не хотелось бы эмулировать, ввод вывод реализовать как-то поэффективней и без магнитных барабанов

Как раз диски и барабаны - самое простое и эффективное. Терминалы (пока мы не восстановим код для работы с аппаратурой сопряжения) и АЦПУ будут проблематичнее. 

Я все про такты, это уму не растяжимо, и сколько тактов должна быть такая команда на верилоге, я пока в непонятках? 

Дело АУ - передать значение с сумматора в УВУ, где оно будет храниться на триггерах с мощным выходом, и всё.

Leo

[Alex Loktionoff]

суббота, 13 сентября 2025 г. в 19:49:50 UTC+2, Leo B.:

On Saturday, September 13, 2025 at 9:06:39 AM UTC-7 oxy...@gmail.com wrote:

 

 2.6 Нормализация

           написано что мантисса результата может быть в диапазоне -2 <= (m + m)< 2. Это означает что 40-й бит это не 1 а 2-ка? Условия кода 11.0ХХ и 00.1ХХ  из 2.6 это про биты [2][1].[1/2][1/4][1/8][...]? и мы должны 40 бит "резервировать" на случай переполнения? тогда точность получается не 40 бит а 39, разве не так? Н и как-то опять с dispak-oм не сходиться выше.

Там написано с учётом невидимого временного дополнительного (42-го) знакового бита. Условие отсутствия переполнения - когда знаковые биты (дополнительный и настоящий) равны.

Вот чуяло мое сердце, что нужен 42 бит, только в документе его незаметно, там только есть какая-то странная логика переноса из 41-го в 40-ой.

Еще в АЛУ порядка есть дополнительный бит знака порядка, это Вы не перепутали? 

Написано же внизу страницы, озаглавленной "2.6 Нормализация", Для того, чтобы результат с мантиссой |m| > 1 (до нормализации) не приводил к потере знака, некоторые регистры арифметического устройства имеют два разряда слева от запятой.

Да, действительно, мало того, я распечатал схему "Устройство мантиссы АУ", там ПР ВР ВРУ ПРУ РС2 42 бита, а РП2 вообще РП2. Но РОМ и РСМ по 41. Повешу на стенку над столом...  

 

С трехвходовыми элементами по прикидкам с однобитовым умножением работает очень шустро. Максимум где -то 41+41, а на малых числах где-то тактов 16 т.е. по ощущениям всего в два раза медленней чем сумма! А если брать по два бита за раз, трудно представить, и это на однобитовых по сути АЛУ! 

 

Минимальное время выполнения умножения в АУ (при выключенной нормализации и грубо говоря, при умножении на 0 или степень двойки, когда гарантированно нет никаких переносов, требующих приведения), согласно документации  - 15 тактов. Это 3 стандартных такта  на обработку операции в АУ + ceil(41/4) = 11 тактов на сдвиг-сложение множителя , и, видимо, ещё 1 на первоначальную установку регистров, специфичную для умножения.

В среднем умножение требует 18 тактов, т. е. 15 + (в среднем 6 приведений переносов)/2. При умножении нормализованных чисел с плавающей точкой завершающая нормализация влево обычно не требуется, при умножении целых она блокирована, а умножение числа с плавающей точкой на целое, видимо, сочтено достаточно редким, и не влияет на среднее.

Я сравнивал "свое" умножение по БЭСМовски на малых целых  и без учета порядка, может поэтому так оптимистично вышло, у меня все биты в низу - пара сдвигов и все. Сумматор БЭСМ-6 /*хотя я бы назвал его аккумулятором!*/ совсем не прост это два АУ мантиссы и порядка, я пока сосредоточусь на реализации АУ мантиссы, чтоб не ошалеть. /* я полагал что было одно "широкое" АЛУ на котором выполнялись все операции просто накладывая соответствующие "маски" битов для порядка/мантиссы, а это два разных заточных под свое дело АЛУ, причем подозреваю для порядка использовался не регистр а вообще реверсивный счетчик. Вот теперь непонимающ как _обычное_ циклическое суммирование 48 бит выполнялось, это надо два АУ засинхронизовать, пока отложу эту головоломку, буду думать только над мантиссами там и так то 41 то 42 то 43 бита */   

 

Я уже думаю над двухбитным умножением, при умножении на 11 там на сумматор видимо посылается операция вычитания /* 11 = 100 - 1*/, но вычитание это сложение с инверсией и еще +1, что как минимум два полутакта - что-то сомневаюсь что таким образом удавалось что-то экономить в тактах.

Удавалось. Случай четырех слагаемых в младшем разряде описан, начиная с конца страницы 43 PDF. Там несколько сложнее, чем мне помнилось.

Спасибо за наводку, еще раз перечитал ЛИСТ 83, и с третьего раза, обратил внимание в самом низу про 4-х равный код /* который мне уже припоминал Михаил! только я совсем не се сообразил */ как раз для этой младшей единицы это уже на ЛИСТ84! Только никакого 4рядного кода сумматор не принимает, он работает только с 3 ходовыми XOR  и AND т.е трехгранным кодом на входе /* внутри состояние 2-х равный код */ И ничего никто не ждет, просто при необходимости подачи дополнительного кода / * т.е. -Х */ насильно сбрасывается младший бит инверсии Х - если Х был четный, то дело в шляпе - мы прибавили 1, а вот если нечетный - то что то непонятно "СМ мантиссы сразу же после обращения гаситься"

Вроде есть идея как передать -Х за один такт, только не понял как с нечетным множимым быть?

Есть идеи?

[Alex Loktionoff]

Попробовал минимальное АЛУ для "трехрядного кода".

Что-то мне  ISE насинтезил, понять не в силах пока, наверняка где-то я накосячил, но этот дизайн "запустился" на частоте 350МГц.

[Leo B.]

Тесты-то проходит хоть? А то что-то там насинтезить, чтобы синтез написал какую-то там частоту - дело нехитрое.

[Alex Loktionoff]

среда, 10 сентября 2025 г. в 01:51:21 UTC+2, Leo B.:

On Tuesday, September 9, 2025 at 9:39:19 AM UTC-7 oxy...@gmail.com wrote:

На БЭСМ-6 выбор между "целым" и "плавающим" режимом сумматора делался переключением разряда блокировки нормализации в регистре режимов. Вся арифметическая логика была в единственном экземпляре. Даже странно, что на этом уровне дискуссии это приходится объяснять. :)

Ну не скажите, целочисленное я имел ввиду циклическое сложение всех 48 битов.

 

 

Leo

[Alex Loktionoff]

понедельник, 15 сентября 2025 г. в 18:25:08 UTC+2, Leo B.:

Тесты-то проходит хоть? А то что-то там насинтезить, чтобы синтез написал какую-то там частоту - дело нехитрое.

Ну, косячек со сдвигом я поправил, и простецкий тест сумма чисел серии 1..10 == 55 проходит.

Заменил всю мудреную 3-х рядную логику на простое  a <= a + d_ext; и тоже вышло 350МГц / 375МГц Макс.

А при переводе на  двухфазный волновой конвейер на защелках, в ISim симуляции все Ок, а timing constraints падает до 86/223МГц причем не все а только каких-то три.

Может как-то надо вешать constraints на wire внутри модуля сумматора? Подскажите, как это победить? Пока теоретически рассуждая для синхронного дизайна по фронту 3 слагаемых для минимального интервала, а для уровня всего два - Tprop + Thold, возможно ли "запустить" Spartan6 на 500МГц?

Ни новый Artix7 ни GoWin yt не поддерживают защелки по уровням. А старый Spartan6 может :-)

[Leo B.]

On Tuesday, September 16, 2025 at 1:28:27 PM UTC-7 oxy...@gmail.com wrote:

понедельник, 15 сентября 2025 г. в 18:25:08 UTC+2, Leo B.:

Тесты-то проходит хоть? А то что-то там насинтезить, чтобы синтез написал какую-то там частоту - дело нехитрое.

Ну, косячек со сдвигом я поправил, и простецкий тест сумма чисел серии 1..10 == 55 проходит.

Заменил всю мудреную 3-х рядную логику на простое  a <= a + d_ext; и тоже вышло 350МГц / 375МГц Макс.

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

 

А при переводе на  двухфазный волновой конвейер на защелках, в ISim симуляции все Ок, а timing constraints падает до 86/223МГц причем не все а только каких-то три.

Возможно, у защёлки довольно заметная задержка, так что лишний уровень хранящих элементов уменьшает максимальную теоретическую частоту.

Может как-то надо вешать constraints на wire внутри модуля сумматора? Подскажите, как это победить? Пока теоретически рассуждая для синхронного дизайна по фронту 3 слагаемых для минимального интервала, а для уровня всего два - Tprop + Thold, возможно ли "запустить" Spartan6 на 500МГц?

Такие детали я уже не знаю.
 

Ни новый Artix7 ни GoWin yt не поддерживают защелки по уровням. А старый Spartan6 может :-)

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

Вместо парафазных защёлок можно с тем же успехом использовать парафазные триггеры.

Leo

[Alex Loktionoff]

вторник, 16 сентября 2025 г. в 22:55:36 UTC+2, Leo B.:

On Tuesday, September 16, 2025 at 1:28:27 PM UTC-7 oxy...@gmail.com wrote:

понедельник, 15 сентября 2025 г. в 18:25:08 UTC+2, Leo B.:

Тесты-то проходит хоть? А то что-то там насинтезить, чтобы синтез написал какую-то там частоту - дело нехитрое.

Ну, косячек со сдвигом я поправил, и простецкий тест сумма чисел серии 1..10 == 55 проходит.

Заменил всю мудреную 3-х рядную логику на простое  a <= a + d_ext; и тоже вышло 350МГц / 375МГц Макс.

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

Что-то подозреваю, что для моего Спартака 375МГц это потолок :-(

 

А при переводе на  двухфазный волновой конвейер на защелках, в ISim симуляции все Ок, а timing constraints падает до 86/223МГц причем не все а только каких-то три.

Возможно, у защёлки довольно заметная задержка, так что лишний уровень хранящих элементов уменьшает максимальную теоретическую частоту.

Пичалька, это ломает почти весь смысл использования, защелок, если на них реально медленней.

 

Ни новый Artix7 ни GoWin yt не поддерживают защелки по уровням. А старый Spartan6 может :-)

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

А какие чипы поддерживают?

 

Вместо парафазных защёлок можно с тем же успехом использовать парафазные триггеры.

Это always @(posedge clk) begin + always @(negedge clk) begin?

Похоже это самый современный способ сделать cycle acurate реализацию БЭСМ-6 красно/синей логики?

Только такой подход никак не ускоряет FPGA /* а уже слюни потекли раскочегарить Спартан до 500МГц */ ведь все равно синхронный подход - T > Tprop + Thold + Tsetup 

Частота дизайна на FPGA падает в двое, можно подумать, что в сумме то на то и выходит, что за такт делаем в два раза больше.

Но в реальности пропускная способность конвейера у БЭСМ-1 1 элемент за такт, так что реальная производительность дизайна на FPGA упадет.

Теоретически если мы сделаем промежуточный не регистр а wire и будем все обрабатывать за один длинный такт, то скорость выйдет еще чуть больше чем обработка на обоих фронтах, так как логика может быть не идеально сбалансирована в обоих фазах, а так оптимизатор сольет все в один большой такт и усреднит. /* Tr+Tb < max(Ta, Tb)*2 */

Просто мне хотелось и рыбку съесть и вводу не лезть, чтоб иметь almost cycle acurate дизайн и чтоб он был максимально быстрым на FPGA. 

Leo

[Leo B.]

On Tuesday, September 16, 2025 at 2:58:20 PM UTC-7 oxy...@gmail.com wrote:

Возможно, у защёлки довольно заметная задержка, так что лишний уровень хранящих элементов уменьшает максимальную теоретическую частоту.

Пичалька, это ломает почти весь смысл использования, защелок, если на них реально медленней.

Ну так на принципиально разных технологиях соотношение задержек на элементах разное, это нормально. 

 

 

Ни новый Artix7 ни GoWin yt не поддерживают защелки по уровням. А старый Spartan6 может :-)

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

А какие чипы поддерживают?

КМК, любой LLM чатбот ответит на этот вопрос лучше меня. 

 

 

Вместо парафазных защёлок можно с тем же успехом использовать парафазные триггеры.

Это always @(posedge clk) begin + always @(negedge clk) begin?

Похоже это самый современный способ сделать cycle acurate реализацию БЭСМ-6 красно/синей логики?

Только такой подход никак не ускоряет FPGA /* а уже слюни потекли раскочегарить Спартан до 500МГц */ ведь все равно синхронный подход - T > Tprop + Thold + Tsetup 

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

Частота дизайна на FPGA падает в двое, можно подумать, что в сумме то на то и выходит, что за такт делаем в два раза больше.

Но в реальности пропускная способность конвейера у БЭСМ-1 1 элемент за такт, так что реальная производительность дизайна на FPGA упадет.

Теоретически если мы сделаем промежуточный не регистр а wire и будем все обрабатывать за один длинный такт, то скорость выйдет еще чуть больше чем обработка на обоих фронтах, так как логика может быть не идеально сбалансирована в обоих фазах, а так оптимизатор сольет все в один большой такт и усреднит. /* Tr+Tb < max(Ta, Tb)*2 */

Тоже правда.  

Просто мне хотелось и рыбку съесть и вводу не лезть, чтоб иметь almost cycle acurate дизайн и чтоб он был максимально быстрым на FPGA. 

 Может, всё-таки в конце концов выбрать, за каким из двух зайцев гнаться в первую очередь?

Leo

[Alex Loktionoff]

 

Вместо парафазных защёлок можно с тем же успехом использовать парафазные триггеры.

Это always @(posedge clk) begin + always @(negedge clk) begin?

Похоже это самый современный способ сделать cycle acurate реализацию БЭСМ-6 красно/синей логики?

Только такой подход никак не ускоряет FPGA /* а уже слюни потекли раскочегарить Спартан до 500МГц */ ведь все равно синхронный подход - T > Tprop + Thold + Tsetup 

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

Частота дизайна на FPGA падает в двое, можно подумать, что в сумме то на то и выходит, что за такт делаем в два раза больше.

Но в реальности пропускная способность конвейера у БЭСМ-1 1 элемент за такт, так что реальная производительность дизайна на FPGA упадет.

Теоретически если мы сделаем промежуточный не регистр а wire и будем все обрабатывать за один длинный такт, то скорость выйдет еще чуть больше чем обработка на обоих фронтах, так как логика может быть не идеально сбалансирована в обоих фазах, а так оптимизатор сольет все в один большой такт и усреднит. /* Tr+Tb < max(Ta, Tb)*2 */

Тоже правда.  

Просто мне хотелось и рыбку съесть и вводу не лезть, чтоб иметь almost cycle acurate дизайн и чтоб он был максимально быстрым на FPGA. 

 Может, всё-таки в конце концов выбрать, за каким из двух зайцев гнаться в первую очередь?

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

 

Leo

С умножением я так понял, что нужен сумматор 4 рядного кода - 4ый всего один бит. 

Но что-то я не нашел пока как умножение справляется с переполнением, у меня пока числи маленькие и 100 х 100 в 40 битов влазит, полагаю так и работает в БЭСМ-6 с блокировкой нормализации, а как с плавающей запятой? Полагаю что там просто инкрементируется порядок? Но тогда умножение с нормализацией и без нормализации это почти разные автоматы состоянии в устройстве управления? Где можно про это почитать?

[Leo B.]

On Thursday, September 18, 2025 at 9:15:51 AM UTC-7 oxy...@gmail.com wrote:

С умножением я так понял, что нужен сумматор 4 рядного кода - 4ый всего один бит. 

Но что-то я не нашел пока как умножение справляется с переполнением, у меня пока числи маленькие и 100 х 100 в 40 битов влазит, полагаю так и работает в БЭСМ-6 с блокировкой нормализации, а как с плавающей запятой? Полагаю что там просто инкрементируется порядок? Но тогда умножение с нормализацией и без нормализации это почти разные автоматы состоянии в устройстве управления? Где можно про это почитать?

А что, из 4-й части ТО непонятно?

Умножение вычисляет 81-разрядное (включая знак) произведение, которое помещается в сумматор + РМР; порядок произведения в АУ порядка образуется как сумма порядков сумматора и операнда минус 64 независимо от нормализации.
Потом, если нормализация  разрешена, полученное произведение нормализуется влево по стандартному механизму. Если в конце нормализации порядок всё ещё больше 127, фиксируется переполнение.

Еще можно смотреть в mesm6.

Leo

[Alex Loktionoff]

четверг, 18 сентября 2025 г. в 18:50:42 UTC+2, Leo B.:

On Thursday, September 18, 2025 at 9:15:51 AM UTC-7 oxy...@gmail.com wrote:

С умножением я так понял, что нужен сумматор 4 рядного кода - 4ый всего один бит. 

Но что-то я не нашел пока как умножение справляется с переполнением, у меня пока числи маленькие и 100 х 100 в 40 битов влазит, полагаю так и работает в БЭСМ-6 с блокировкой нормализации, а как с плавающей запятой? Полагаю что там просто инкрементируется порядок? Но тогда умножение с нормализацией и без нормализации это почти разные автоматы состоянии в устройстве управления? Где можно про это почитать?

А что, из 4-й части ТО непонятно?

Умножение вычисляет 81-разрядное (включая знак) произведение, которое помещается в сумматор + РМР; порядок

81-разрядное - вот это и непонятно, все регистры на схеме 41-43 бит, сумматор 42-х битный а получается 81-бит.

Неужели при умножении сумматор работает с РМР как с аккумулятором? / в СМ попадают старшие разряды /

Не пойму как с 42-х битным сумматором можно получить 81-бит сумму 

А при обычном суммировании вычитании с СМ? / в РМР попадают младшие разряды при нормализации/

[Serge Vakulenko]

On Thursday, September 18, 2025 at 11:33:26 AM UTC-7 oxy...@gmail.com wrote:

четверг, 18 сентября 2025 г. в 18:50:42 UTC+2, Leo B.:

Умножение вычисляет 81-разрядное (включая знак) произведение, которое помещается в сумматор + РМР; порядок

81-разрядное - вот это и непонятно, все регистры на схеме 41-43 бит, сумматор 42-х битный а получается 81-бит.

Неужели при умножении сумматор работает с РМР как с аккумулятором? / в СМ попадают старшие разряды /

Не пойму как с 42-х битным сумматором можно получить 81-бит сумму 

А при обычном суммировании вычитании с СМ? / в РМР попадают младшие разряды при нормализации/

В мэсм6 всё видно. Строка 271 файла mesm6_alu.sv.

https://github.com/besm6/mesm6/blob/master/rtl/mesm6_alu.sv#L271 

--Сергей

[Alex Loktionoff]

Спасибо, Сергей, вот уж не думал, что в МЕСМ6 можно подсмотреть реализацию БЭСМ-6!

// A*X: multiply in one cycle, then normalize.
                    {`FULLMANT, rmr[39:0]} <= amant * bmant;
                    `FULLEXP <= (a[47:41] + b[47:41] - 64);

Получается что при умножении сумматор работает с РМР, причем старшие биты попадают в СМ по сути сумматор на 81 разряд! 

А при сложении сумматор работает только с СМ, а РМР зануляется? 

// A+X, A-X, X-A or AMX instructions.
                    // acc gets the operand with the larger exponent, rail gets the other
                    if (a[47:41] > b[47:41]) begin
                        `FULLMANT <= add_val1;

У меня вопрос: А вообще тот ли это самый сумматор используется для умножения и сложения? Уж больно они разные!

И вообще откуда этот сумиатор на 81 разряд если все регистры 41-43 бита, я в шоке. На выходных буду по схеме искать...

четверг, 18 сентября 2025 г. в 20:42:21 UTC+2, serge.v...@gmail.com:

[Alex Loktionoff]

пятница, 19 сентября 2025 г. в 20:47:19 UTC+2, Alex Loktionoff:

Спасибо, Сергей, вот уж не думал, что в МЕСМ6 можно подсмотреть реализацию БЭСМ-6!

// A*X: multiply in one cycle, then normalize.
                    {`FULLMANT, rmr[39:0]} <= amant * bmant;
                    `FULLEXP <= (a[47:41] + b[47:41] - 64);

Получается что при умножении сумматор работает с РМР, причем старшие биты попадают в СМ по сути сумматор на 81 разряд! 

Понятно, что для двухрядного кода XOR и AND разрядность можно наращивать не напрягаясь, но проблема возникает с условием готовности результата - элемент 80NOR должен быть виден на схеме и "объединять" каких то два регистра.

80NOR  это даже FPGA не мыло тазику гонять, надо еще попробовать на сколько упадет частота.

А в те времена тем более,  количество входов было 3-4 у FPGA их и то 6.    

[Alex Loktionoff]

Хотя распечатки блок диаграмм АЛУ висят у меня на стене уже вторую неделю, следов 81NOR не обнаружено, пока.

/ * хотя откровенно говоря и 41NOR не видать, подозреваю что они внутри блоков с "СИГМой" на массовых цепях АУ */

Ну что-ж, будем переизобретать, как в свое время ЕС1020 по архитектуре IBM.

Возникла шальная идея правда, что можно обойтись как-то 41NOR /*или дважды по 41NOR*/ почти без потерь, так как при умножении последнего бита складываются только старшие биты 82-41. Но беспокоит "почти без потерь" где-то тактик на обьединение сигналов от двух 41NOR младших и старших разрядов нет-нет да и вылезет - уже расхождение с оригиналом.

Если у кого есть мысли по этому поводу, буду благодарен. /* сохранились ли где-то конкретные времянки умножения конкретных чисел? Есть ли где-то "свидетельства" того, что сигналы от 41NOR объединялись? */ 

суббота, 20 сентября 2025 г. в 08:46:21 UTC+2, Alex Loktionoff:

[Leo B.]

Выдвигаемые в РМР разряды уже полностью приведены, у РМР нет никакого второго ряда переносов, который надо сравнивать с нулём. 

Цепь сравнения сумматора с с нулём была "массовая", да.  Но при приведении переносов с нулём нужно сравнивать не сумму, а переносы - перечитайте ТО4 внимательно, как именно это было организовано.

Leo

[Alex Loktionoff]

Сергей, есть надежда на обновление схемы сумматора МЭСМ6 

https://github.com/besm6/mesm6/wiki/Microarchitecture#сумматор

Там вместо сумматора схема PC.

суббота, 27 сентября 2025 г. в 10:04:52 UTC+2, Alex Loktionoff:

[Serge Vakulenko]

On Sunday, September 28, 2025 at 6:14:06 AM UTC-7 oxy...@gmail.com wrote:

Сергей, есть надежда на обновление схемы сумматора МЭСМ6 

https://github.com/besm6/mesm6/wiki/Microarchitecture#сумматор

Там вместо сумматора схема PC.

Точно, был не тот рисунок. Исправил, спасибо.

--Сергей