Округление без нормализации

Leo B.

unread,

Apr 3, 2025, 12:23:03 PMApr 3

to БЭСМ-6

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

Например, чтобы получить из целого неотрицательного числа без порядка (рр. 48-41 == 0, остальные произвольные) единицу в младшем разряде, если число не равно нулю, и ноль, если равно, без использования условных переходов, достаточно сделать

РЖА 1 нормализация блокирована, округление - нет

УМН =M47B'1'B'1' единицы в 1-м и 48-м разрядах

РЖА режим вернуть нормальный режим

Это, правда, дольше, чем

РЖА 4+режим логическая группа

ПО L1

СЧ =В'1'

L1 ...

Но всё равно забавно. Судя по бинарному поиску на 2048, в М-80 кто-то пользовался этим режимом просто в смысле "блокировка нормализации" (в исходниках ОС/МС "Дубна" grep ', *NTR *, *1[^0-9]' dubna.dd dubna.ms ничего не находит

Или были более полезные функции, которые простым условным переходом не реализовать?

Leo

Michael Yaroslavtsev

unread,

Apr 3, 2025, 1:01:05 PMApr 3

to be...@googlegroups.com

On Thu, Apr 3, 2025 at 9:23 AM Leo B. <leo...@gmail.com> wrote:

Похоже, от режима с блокировкой нормализации, но без блокировки округления могла быть какая-то польза.
Например, чтобы получить из целого неотрицательного числа без порядка (рр. 48-41 == 0, остальные произвольные) единицу в младшем разряде, если число не равно нулю, и ноль, если равно, без использования условных переходов, достаточно сделать
РЖА 1 нормализация блокирована, округление - нет
УМН =M47B'1'B'1' единицы в 1-м и 48-м разрядах
РЖА режим вернуть нормальный режим

Это, правда, дольше, чем
РЖА 4+режим логическая группа
ПО L1
СЧ =В'1'
L1 ...

Милый трюк. Пользовался бы, если б знал в своё время.

Но всё равно забавно. Судя по бинарному поиску на 2048, в М-80 кто-то пользовался этим режимом просто в смысле "блокировка нормализации" (в исходниках ОС/МС "Дубна" grep ', *NTR *, *1[^0-9]' dubna.dd dubna.ms ничего не находит

Или были более полезные функции, которые простым условным переходом не реализовать?

Leo

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

--

Thanks,
-- Michael

Alex Loktionoff

unread,

Apr 3, 2025, 3:55:59 PMApr 3

to БЭСМ-6

Ну это круто, прямо как в С !!(condition) ? А почему медленней? Неужели JUMP быстрее?

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

четверг, 3 апреля 2025 г. в 18:23:03 UTC+2, Leo B.:

Leo B.

unread,

Apr 3, 2025, 4:22:26 PMApr 3

to БЭСМ-6

On Thursday, April 3, 2025 at 12:55:59 PM UTC-7 oxy...@gmail.com wrote:

Ну это круто, прямо как в С !!(condition) ?

Примерно ради того и затевалось :)

А почему медленней? Неужели JUMP быстрее?

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

Умножение: 3 такта в УУ, минимум 15 в АУ (без нормализации, но с округлением, видимо, будет 16).
Переход: 12-15 в УУ, 3 в АУ, сихронизация АУ и УУ где-то посередине тактов в УУ.

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

Т. к. переход всего через одну команду вперёд, предвыборка команд сделает этот переход мгновенным.

Leo

Alex Loktionoff

unread,

Apr 5, 2025, 3:08:48 AMApr 5

to БЭСМ-6

четверг, 3 апреля 2025 г. в 22:22:26 UTC+2, Leo B.:

On Thursday, April 3, 2025 at 12:55:59 PM UTC-7 oxy...@gmail.com wrote:
Ну это круто, прямо как в С !!(condition) ?

Примерно ради того и затевалось :)

А почему медленней? Неужели JUMP быстрее?

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

Умножение: 3 такта в УУ, минимум 15 в АУ (без нормализации, но с округлением, видимо, будет 16).
Переход: 12-15 в УУ, 3 в АУ, сихронизация АУ и УУ где-то посередине тактов в УУ.

Да интересно получается, сократим аппарат и удлиним змеевик, то на то получается.

У меня есть вопрос про синхронизацию АУ и команд, это не в этой ветке наверно.

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

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

Т. к. переход всего через одну команду вперёд, предвыборка команд сделает этот переход мгновенным.

Да, упакованные БЕСМ6 команды дают знать, этот JUMP может просто сделать выборку следующей команды.

Leo

Василий Долматов

unread,

Apr 5, 2025, 10:06:48 AMApr 5

to be...@googlegroups.com

5 апр. 2025 г., в 10:08, Alex Loktionoff <oxy...@gmail.com> написал(а):

четверг, 3 апреля 2025 г. в 22:22:26 UTC+2, Leo B.:
On Thursday, April 3, 2025 at 12:55:59 PM UTC-7 oxy...@gmail.com wrote:
Ну это круто, прямо как в С !!(condition) ?

Примерно ради того и затевалось :)

А почему медленней? Неужели JUMP быстрее?

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

Умножение: 3 такта в УУ, минимум 15 в АУ (без нормализации, но с округлением, видимо, будет 16).
Переход: 12-15 в УУ, 3 в АУ, сихронизация АУ и УУ где-то посередине тактов в УУ.
Да интересно получается, сократим аппарат и удлиним змеевик, то на то получается.

У меня есть вопрос про синхронизацию АУ и команд, это не в этой ветке наверно.
Где можно почитать посмотреть как это было реализовано в железе, и сколько стоило в тактах.

В 9-й книге…

Сама синхронизация - не стоила нисколько - это просто сигнал готовности, который разрешал дальнейшее выполнение…

А вот сколько тактов ждать этой готовности - сильно зависело от предыдущей набивки команд АУ в БАК…

Хоть сотню таков… :)

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

Т. к. переход всего через одну команду вперёд, предвыборка команд сделает этот переход мгновенным.
Да, упакованные БЕСМ6 команды дают знать, этот JUMP может просто сделать выборку следующей команды.

Leo

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

Чтобы посмотреть обсуждение, перейдите по ссылке https://groups.google.com/d/msgid/besm6/cbdd6e00-ecb9-4fe7-986e-e9673c16127cn%40googlegroups.com.

Василий Долматов

unread,

Apr 5, 2025, 10:10:04 AMApr 5

to be...@googlegroups.com

5 апр. 2025 г., в 17:06, Василий Долматов <vdol...@gmail.com> написал(а):

5 апр. 2025 г., в 10:08, Alex Loktionoff <oxy...@gmail.com> написал(а):

четверг, 3 апреля 2025 г. в 22:22:26 UTC+2, Leo B.:
On Thursday, April 3, 2025 at 12:55:59 PM UTC-7 oxy...@gmail.com wrote:
Ну это круто, прямо как в С !!(condition) ?

Примерно ради того и затевалось :)

А почему медленней? Неужели JUMP быстрее?

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

Умножение: 3 такта в УУ, минимум 15 в АУ (без нормализации, но с округлением, видимо, будет 16).
Переход: 12-15 в УУ, 3 в АУ, сихронизация АУ и УУ где-то посередине тактов в УУ.
Да интересно получается, сократим аппарат и удлиним змеевик, то на то получается.

У меня есть вопрос про синхронизацию АУ и команд, это не в этой ветке наверно.
Где можно почитать посмотреть как это было реализовано в железе, и сколько стоило в тактах.
В 9-й книге…
Сама синхронизация - не стоила нисколько - это просто сигнал готовности, который разрешал дальнейшее выполнение…

А вот сколько тактов ждать этой готовности - сильно зависело от предыдущей набивки команд АУ в БАК…
Хоть сотню таков… :)

Проще всего разбирать по выполнению команды УИ (040), которая будет «зависать» в УУ, пока данные на сумматоре не будут полностью готовы для заноса в индекс-регистр.

И таких команд есть еще несколько (навскидку - WTC (23) ), в народе назывались «затыкающими водопровод»… :)

Reply all

Reply to author

Forward