Что-то странное в БЕМШе творится

[Leo B.]

Я внезапно обнаружил, что БЕМШ неоптимально компилирует команду ПВ:

    МАКРО-БЕМШ ВЕР.06/78      МОДУЛЬ   СТР 0001
ОШИБКИ   НПК  СВОБ ПЕРЕМ АДРЕС КОМАНДА    А ИСП N ГЕН N ИСХ МЕТКА  ОПЕРАЦИЯ ОПЕРАНД   КОММЕНТАРИЙ
                                                 0001  0001 МОДУЛЬ СТАРТ ’1’
         001             00001 00 010 0000       0002  0002        СЧ
                               04 31 00173       0003  0003        ПВ    123(4)
                         00002 00 22
                               04 31 00173       0004  0004        ПВ    123(4)
                         00003 04 31 00173       0005  0005        ПВО   123(4)
                               00 010 0000       0006  0006        СЧ
                                                 0007  0007        ФИНИШ

По адресу 2 хотелось бы видеть команду ПВ в левом полуслове, а пустышку - в правом, чтобы не тратилось время на её выполнение.  И это не ошибка в эмуляторе, так на самом деле было (я поискал по коду Диспака на 2053).

Псевдокоманда ПВО (ПВ очередная), хоть и может ставить ПВ в левое полуслово, но не делает выравнивания на слово после команды (в чём тогда польза от этого ПВО?) 

Не могли же люди 20 лет не обращать на это внимание, тем более что Мадлен ведёт себя ожидаемо?

Как, интересно, авторы БЕМШа аргументировали такое решение? 

Leo

[Michael Yaroslavtsev]

Сначала подумал, просто не обратили внимания.

Однако, очевидно, что ассемблер предпринимает специальные действия, чтобы разместить ПВ именно в правой половине.

Значит, был какой-то неочевидный мотив.

Лечится несложно - макрос ПВ, состоящий из ПВО и "ПАМ 0".

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

--

Thanks,
-- Michael

[Leo B.]

Похоже, им не удалось красиво вписать в базовый алгоритм логику, выполняющую конкретно для ПВ выравнивание именно после команды (а не перед отработкой помеченной команды или КОНД)

и они забили на эффективность.

По умолчанию ПВ  - всегда правая команда, ПВЛ - всегда левая, а ПВО - просто команда.

Макрос работает, и жаль, что его в Диспаке не было. Сколько часов машинного времени бы сэкономили!

Leo

[Michael Yaroslavtsev]

On Tue, Feb 8, 2022 at 2:00 AM Leo B. <leo...@gmail.com> wrote:

Похоже, им не удалось красиво вписать в базовый алгоритм логику, выполняющую конкретно для ПВ выравнивание именно после команды (а не перед отработкой помеченной команды или КОНД)

А с экстракодами как? 

Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/besm6/ce0b5e3b-99d1-49d1-8f3d-424d38baecd7n%40googlegroups.com.

--

Thanks,
-- Michael

[Leo B.]

On Tuesday, February 8, 2022 at 4:38:03 AM UTC-8 BOPOHOK wrote:

On Tue, Feb 8, 2022 at 2:00 AM Leo B. <leo...@gmail.com> wrote:

Похоже, им не удалось красиво вписать в базовый алгоритм логику, выполняющую конкретно для ПВ выравнивание именно после команды (а не перед отработкой помеченной команды или КОНД)

А с экстракодами как? 

Экстракоды всегда правые; кроме, разумеется, Э66, который всегда левый.

Leo

[Макаров-Землянский Николай]

Два ответа:

1. Про ПВ. Очень удобно передавать параметры в вызываемую процедуру.

СЧ АААА

ПВ ИМЯ(14)

в АААА - адрес параметров

Думаю, этим мало кто пользовался.

2. Про машинное время. Как-то я попросил Е.И.Гуревича увеличить частоту 19 р ГРП до 600 (1200) ГЦ. Сказано - сделано. Где-то через месяц он мне говорит - БЭСМ-6 тратит 30% времени на обработку терминалов. Я ответил - хрен с ним (временем), зато пользователям удобнее.

 

08.02.2022, 02:00, "Leo B." <leo...@gmail.com>:

Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/besm6/ce0b5e3b-99d1-49d1-8f3d-424d38baecd7n%40googlegroups.com.

[Leo B.]

Продолжая тему, вот тут https://github.com/besm6/besm6.github.io/blob/master/sources/mars/re-mars.txt

лежит БЕМШ-распечатка дизассемблированного МАРСа (БАНк Данных И Текстов, БАНДИТ), ЗОНГП-идентичная натуральному.

Весь код совершенно перемещаемый, базированный по М4, установленному на начало листа МАРСа (УПОТР БАНДИТ(М4)).

Код активно пользуется структурой данных (BDVECT) из 200+ слов за пределами этого листа. Адрес структуры передаётся на М13, адресуется много разных смещений.

Я для удобства написал в конце программы 

         пам     '32000'

bdvect   пам        1

* и далее объявления прочих полей

и УПОТР BDVECT(M13) в начале программы. Большинство обращений к полям этой структуры правильно базируется по М13, но для команд МОДА и МОД всё равно выбирается М4 в качестве базового,

и в нескольких десятках случаев пришлось явно писать нечто-BDVECT(M13), чтобы результат сошёлся с оригиналом. Хотя по-хорошему должен выбираться тот из базовых регистров, который даёт минимальное положительное смещение.

Что я делаю не так?

Leo

[Michael Yaroslavtsev]

В ядре ОС похожих ситуаций чуть более, чем дофига.

Второй УПОТР никогда не писали, всё прописывали вручную, типа

ЭКВВОД ВНЕШ ЭКВЫХ,ПРОЦ

...

Э      ЭКВ  ЭКВВОД

...

       ПБ   ЭКВЫХ-Э(М7)

а то и

       МОДА ПРОЦ-Э(М7)

       ПВ   (М15)

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

Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/besm6/2399a37e-1be0-46fe-b32b-ca85643baefbn%40googlegroups.com.

--

Thanks,
-- Michael

[Leo B.]

Понятно, спасибо. Значит, в реализации множественных УПОТР была ошибка. В IBM-овском USING всё как надо:

When two ranges overlap, the assembler computes displacements from the base address that gives the smallest non-negative displacement;