Да? Не знал. А у СМ-4 что, тоже FIS , а FPU только на 1420 и М6/Э-85 и свежее?Цитата:
Сообщение от form
Вид для печати
Да? Не знал. А у СМ-4 что, тоже FIS , а FPU только на 1420 и М6/Э-85 и свежее?Цитата:
Сообщение от form
Видимо так.Цитата:
Сообщение от AFZ
Тогда (ближе к теме) вопрос: кто-нибудь реально запускал RT-11 на сабжевом процессоре? Как она его видит. Ведь 11/34 FPU тоже ни разу не положен, максимум, FIS. И что она скажет, увидев FPU ?
Блин, какого хрена эти орлы не сделали обращение к слову по нечетному адресу подобно ВМ1/2 ?
Вполне себе положен FP11-A. Опционально вроде.Цитата:
Сообщение от AFZ
- - - Добавлено - - -
У DEC тоже такие процы есть где можно.Цитата:
Сообщение от AFZ
А на УК-НЦ к слову даже есть фрагмент прошивки где используется словное обращение к нечетному адресу, и это обязательно - иначе работать не будет :)
11/03, 11/23... И, когда клепали ВМ1-2 явно поглядывали в сторону 11/03. Было бы логично, делая ВМ3, посмотреть в сторону 11/23, а изба фигвам.Цитата:
Сообщение от form
А в итоге, мой любимый PACM6, который написали "буржуи" Климов, Сторожевых, на ВМ3 не идет. И еще пара PAC-MAN'ов.
И, кстати, какой высокий смысл в том? Зачем обращаться к словам по нечетному адресу? Специально сделать программу, которая работает на Э-60 и не работает на "больших" машинках? Я лет, так, 15 назад, в приступе ностальгии, начал запускать PACM6 на ВМ3 (не было под рукой ни ВМ2, ни Э-60). По каждому Trap to 4 анализировал ситуацию и правил DESS'ом. Последняя пара правок была как бы не при смене лабиринта. Заработал, однако колбасит его по-тяжелому, что-то в нем таки испортилось.
Да никакого. Просто накосячили да не заметили. SD помогает вылавливать такие вещи.Цитата:
Сообщение от AFZ
Полез проверять. Странно. А почему Макро не ругается, когда пишешь TST B1, где B1 явно имеет нечетный адрес? Это же ошибка, которая легко проверяется во время ассемблирования. Да, я (по ошибке) написал TST вместо TSTB. Но в среднем половина таких ошибок выявится сразу при ассемблировании, если это проверять, а Макро-11 не проверяет. Ладно, не ошибку, так хоть предупреждение выдай! Так нет, молчит, как партизан на допросе...Цитата:
Сообщение от form
Это не его задача. Тут же не ошибка компиляции и не неоднозначность. Может именно это и требуется написать (к слову в программах RT-11 используется как раз для проверки факта прервания). Вот если написать .WORD на нечетном адресе - тут ругнется.Цитата:
Сообщение от AFZ
Да и ошибки адресации чаще делают при косвеной адресации или смещениям по регистру.
Не будет он и возражать против JMP R0 к примеру - опять же может захотелось. Вот на JMP (R0)+ уже Z поставит.
Его-его. Задача компилятора - найти и показать программисту максимально возможное количество ошибочных и подозрительных ситуаций в его программе до этапа выполнения и даже до линковки. А ситуация, как минимум неоднозначная: на "больших" машинках это вылет по 4 вектору, на LSI-11 - вообще хрен поймет что, но наверняка не то, о чем думал программист, объявляя байт по нечетному адресу отдельной переменной. Как пример - тот самый PACM6. Будь эта проверка в Макро, эту ошибку убрали бы одной из первых.Цитата:
Сообщение от form
ИМХО, все проще. Поначалу DEC'овцы облажались, забыли об этой проверке, позже объявили этот баг фичей и на этом успокоились.
В том PACM6 смещения были от 7-го регистра.Цитата:
Сообщение от form
Вот-вот, явный намёк на "строгость" проверки. А на самом деле строгости-то и не оказалось. Вон, Система-360 молча выравнивала данные на нужную границу и не жужжала напоминаниями. У них там еще этих выравниваний аж 3 шт - на границу полуслова (2 байта), слова (4) и двойного слова (8), и даже нет отдельной директивы выравнивания, просто пишешь константу (описываешь поле) нужного типа и она автоматически выравнивается на нужную границу. А при неочевидной потребности выравнять (например, байт на границу двойного слова), писали константу нужного типа с коэффициентом повторения НОЛЬ.Цитата:
Сообщение от form
Но ситуация подозрительной не является - это штатный код причем даже для обычной жизни - он может транслироваться программой перед выполнением. При том нет смысла тратить ресурсы компилятора, проверяя 1% возможностей данной ситуации без возможности проверить 99%.Цитата:
Сообщение от AFZ
В таком случае "облажались" все - такой проверки нет вообще ни у кого ;)Цитата:
Сообщение от AFZ
Никакого намека. Это явная ошибка компиляции. TST @#1 же к римеру ошибки компиляции не вызывает и является штатным кодом. Не важно, что он на большинстве процессоров вызовет ошибку. Если докапываться до всего, то надо ругаться и на команды RTT. SOB, SXT, MARK, не говорю уже про EIS/FIS...Цитата:
Сообщение от AFZ
- - - Добавлено - - -
Так поступают все компиляторы высокого уровня (например на том же интеле, хотя там это не всегда критично). Но ассебмлер - это ассемблер - что написал то и получил :)Цитата:
Сообщение от AFZ