1801ВМ3 + 1801ВМ4= как?

[AFZ]

Там нет FPU, там FIS.

Да? Не знал. А у СМ-4 что, тоже FIS , а FPU только на 1420 и М6/Э-85 и свежее?

[form]

а FPU только на 1420 и М6/Э-85 и свежее?

Видимо так.

[AFZ]

Тогда (ближе к теме) вопрос: кто-нибудь реально запускал RT-11 на сабжевом процессоре? Как она его видит. Ведь 11/34 FPU тоже ни разу не положен, максимум, FIS. И что она скажет, увидев FPU ?

Блин, какого хрена эти орлы не сделали обращение к слову по нечетному адресу подобно ВМ1/2 ?

[form]

Ведь 11/34 FPU тоже ни разу не положен

Вполне себе положен FP11-A. Опционально вроде.

- - - Добавлено - - -

обращение к слову по нечетному адресу подобно ВМ1/2

У DEC тоже такие процы есть где можно.
А на УК-НЦ к слову даже есть фрагмент прошивки где используется словное обращение к нечетному адресу, и это обязательно - иначе работать не будет

[AFZ]

У DEC тоже такие процы есть где можно.

11/03, 11/23... И, когда клепали ВМ1-2 явно поглядывали в сторону 11/03. Было бы логично, делая ВМ3, посмотреть в сторону 11/23, а изба фигвам.

А в итоге, мой любимый PACM6, который написали "буржуи" Климов, Сторожевых, на ВМ3 не идет. И еще пара PAC-MAN'ов.

И, кстати, какой высокий смысл в том? Зачем обращаться к словам по нечетному адресу? Специально сделать программу, которая работает на Э-60 и не работает на "больших" машинках? Я лет, так, 15 назад, в приступе ностальгии, начал запускать PACM6 на ВМ3 (не было под рукой ни ВМ2, ни Э-60). По каждому Trap to 4 анализировал ситуацию и правил DESS'ом. Последняя пара правок была как бы не при смене лабиринта. Заработал, однако колбасит его по-тяжелому, что-то в нем таки испортилось.

[form]

И, кстати, какой высокий смысл в том?

Да никакого. Просто накосячили да не заметили. SD помогает вылавливать такие вещи.

[AFZ]

Да никакого. Просто накосячили да не заметили.

Полез проверять. Странно. А почему Макро не ругается, когда пишешь TST B1, где B1 явно имеет нечетный адрес? Это же ошибка, которая легко проверяется во время ассемблирования. Да, я (по ошибке) написал TST вместо TSTB. Но в среднем половина таких ошибок выявится сразу при ассемблировании, если это проверять, а Макро-11 не проверяет. Ладно, не ошибку, так хоть предупреждение выдай! Так нет, молчит, как партизан на допросе...

[form]

А почему Макро не ругается, когда пишешь TST B1

Это не его задача. Тут же не ошибка компиляции и не неоднозначность. Может именно это и требуется написать (к слову в программах RT-11 используется как раз для проверки факта прервания). Вот если написать .WORD на нечетном адресе - тут ругнется.
Да и ошибки адресации чаще делают при косвеной адресации или смещениям по регистру.
Не будет он и возражать против JMP R0 к примеру - опять же может захотелось. Вот на JMP (R0)+ уже Z поставит.

[AFZ]

Это не его задача. Тут же не ошибка компиляции и не неоднозначность.

Его-его. Задача компилятора - найти и показать программисту максимально возможное количество ошибочных и подозрительных ситуаций в его программе до этапа выполнения и даже до линковки. А ситуация, как минимум неоднозначная: на "больших" машинках это вылет по 4 вектору, на LSI-11 - вообще хрен поймет что, но наверняка не то, о чем думал программист, объявляя байт по нечетному адресу отдельной переменной. Как пример - тот самый PACM6. Будь эта проверка в Макро, эту ошибку убрали бы одной из первых.

ИМХО, все проще. Поначалу DEC'овцы облажались, забыли об этой проверке, позже объявили этот баг фичей и на этом успокоились.

Да и ошибки адресации чаще делают при косвеной адресации или смещениям по регистру.

В том PACM6 смещения были от 7-го регистра.

Вот если написать .WORD на нечетном адресе - тут ругнется.

Вот-вот, явный намёк на "строгость" проверки. А на самом деле строгости-то и не оказалось. Вон, Система-360 молча выравнивала данные на нужную границу и не жужжала напоминаниями. У них там еще этих выравниваний аж 3 шт - на границу полуслова (2 байта), слова (4) и двойного слова (8), и даже нет отдельной директивы выравнивания, просто пишешь константу (описываешь поле) нужного типа и она автоматически выравнивается на нужную границу. А при неочевидной потребности выравнять (например, байт на границу двойного слова), писали константу нужного типа с коэффициентом повторения НОЛЬ.

[form]

подозрительных ситуаций

Но ситуация подозрительной не является - это штатный код причем даже для обычной жизни - он может транслироваться программой перед выполнением. При том нет смысла тратить ресурсы компилятора, проверяя 1% возможностей данной ситуации без возможности проверить 99%.

Поначалу DEC'овцы облажались

В таком случае "облажались" все - такой проверки нет вообще ни у кого

Вот-вот, явный намёк на "строгость" проверки.

Никакого намека. Это явная ошибка компиляции. TST @#1 же к римеру ошибки компиляции не вызывает и является штатным кодом. Не важно, что он на большинстве процессоров вызовет ошибку. Если докапываться до всего, то надо ругаться и на команды RTT. SOB, SXT, MARK, не говорю уже про EIS/FIS...

- - - Добавлено - - -

молча выравнивала данные на нужную границу

Так поступают все компиляторы высокого уровня (например на том же интеле, хотя там это не всегда критично). Но ассебмлер - это ассемблер - что написал то и получил