Комментарии 84
Ассемблер PDP-11 — до сих пор самый любимый.
это было нечто, приятно вспомнить…
НЛО прилетело и опубликовало эту надпись здесь
Я понимаю, что формулировка «любимый» в общем-то субъективная, и не всегда предполагает сравнение, и все-таки спрошу — в сравнении с чем?
В смысле — это не из серии «раньше трава была зеленее, лето длиннее в два раза, а синус достигал значения 4»? :)
В смысле — это не из серии «раньше трава была зеленее, лето длиннее в два раза, а синус достигал значения 4»? :)
ну, по сравнению с 6502, 8080/z80, x86, 48/51, pic16… ну и ЯСК Минск-32, который можно тоже отнести к ассемблерам
Это в том смысле, что огромное количество действий, логически оформляемых программистом как отдельная операция, ложилось ровно на одну команду. Не нужно было делать всякие предварительные загрузки и последующие выгрузки, укладки в конкретные регистры (за редкими несущественными исключениями), и так далее. Это в первую очередь за счёт ортогональности операций операндам. В результате, программа на ассемблере была максимально читаемой в целевых понятиях — ни одна из архитектур до того и большинство после такого не достигали.
Да, сейчас понятно, чем это плохо для процессора (кстати, непонятно, почему в статье PDP-11 сравнивается с RISC; она была CISC в чистом виде). Последующие архитектуры, которые довели эту идею до абсурда (как VAX или M68k), сдохли где-то как раз тогда, когда OoO начало приходить в мини- и микропроцессоры. Но на 70-80-е годы это было очень хорошим решением.
Мне из нынешнего взгляда на PDP-11 с учётом, разумеется, поправки на время, видится достаточно немного ошибок: например, не надо было давать обновление флагов по MOV. (Все архитектуры разработки после — этого уже не делают.); можно было вычеркнуть режимы адресации 3 и 5, их использование было редчайшим (в VAX так и сделали, для 5-го)…
Да, сейчас понятно, чем это плохо для процессора (кстати, непонятно, почему в статье PDP-11 сравнивается с RISC; она была CISC в чистом виде). Последующие архитектуры, которые довели эту идею до абсурда (как VAX или M68k), сдохли где-то как раз тогда, когда OoO начало приходить в мини- и микропроцессоры. Но на 70-80-е годы это было очень хорошим решением.
Мне из нынешнего взгляда на PDP-11 с учётом, разумеется, поправки на время, видится достаточно немного ошибок: например, не надо было давать обновление флагов по MOV. (Все архитектуры разработки после — этого уже не делают.); можно было вычеркнуть режимы адресации 3 и 5, их использование было редчайшим (в VAX так и сделали, для 5-го)…
Ну наконец-то нормальное обсуждение пошло, которого хотелось. А то задаешь нормальный вопрос, за что и в сравнении с чем вы это любили, прибегает кто-то, молча ставит минус, и молча убегает :)
Насчет CISC — согласен, не было там RISC нигде. По-моему в то время и понятие такое еще не появилось?
Насчет CISC — согласен, не было там RISC нигде. По-моему в то время и понятие такое еще не появилось?
> Насчет CISC — согласен, не было там RISC нигде. По-моему в то время и понятие такое еще не появилось?
Ну да, формализация RISC прошла в середине 80-х (Патерсон и компания). До этого реализации с заметным уклоном в сторону RISC были, но они считаются «донаучными» эмпирическими подходами. Тот же S/360 мог читать из памяти, но писать — нет, и это уже частичный наклон туда. Также прото-RISC считаются разработки типа 6502. У них в эту сторону «смотрит» отсутствие или минимум сложных операций, выполнение всего в одно неразлагаемое действие «взял команду — раскодировал — прочитал аргументы — подсчитал — записал результаты». PDP-11 с дополнительными вложенными «а тут ещё прочитаем память согласно регистру, а тут ещё её запишем, а теперь модифицируем адресный регистр» никак в это не вкладывался — зато человеку действие такое действие представлялось единым.
И у начальных RISC была серьёзная проблема сделать эффективную компиляцию; существующие подходы на CISC ложились лучше. SSA в заметной мере появился как раз в ответ на этот вызов.
Ну да, формализация RISC прошла в середине 80-х (Патерсон и компания). До этого реализации с заметным уклоном в сторону RISC были, но они считаются «донаучными» эмпирическими подходами. Тот же S/360 мог читать из памяти, но писать — нет, и это уже частичный наклон туда. Также прото-RISC считаются разработки типа 6502. У них в эту сторону «смотрит» отсутствие или минимум сложных операций, выполнение всего в одно неразлагаемое действие «взял команду — раскодировал — прочитал аргументы — подсчитал — записал результаты». PDP-11 с дополнительными вложенными «а тут ещё прочитаем память согласно регистру, а тут ещё её запишем, а теперь модифицируем адресный регистр» никак в это не вкладывался — зато человеку действие такое действие представлялось единым.
И у начальных RISC была серьёзная проблема сделать эффективную компиляцию; существующие подходы на CISC ложились лучше. SSA в заметной мере появился как раз в ответ на этот вызов.
по-моему в так и сделали в MSP430 (пожертвовали не используемыми режимами адресации) для увеличения числа регистров и добавили некоторые расширения, как генератор констант.
P.S. Кстати процессор с системой команд PDP-11 был и в калькуляторах «Электроника-85/90/92» Влияние PDP-11 можно увидеть и в системе команд Motorola 68000
Электроника-85 потреблялa 20мА на 6В ~ 3.3 мА (тактовая, наверное, при этом была в районе 500 КГц т.к. был режим турбо в 4-5 раз быстрее) для экономии часовых элементов питания.
P.S. Кстати процессор с системой команд PDP-11 был и в калькуляторах «Электроника-85/90/92» Влияние PDP-11 можно увидеть и в системе команд Motorola 68000
Электроника-85 потреблялa 20мА на 6В ~ 3.3 мА (тактовая, наверное, при этом была в районе 500 КГц т.к. был режим турбо в 4-5 раз быстрее) для экономии часовых элементов питания.
Там очень простая, гибкая и мощная структура машинных команд — всё читается в восьмеричных кодах. Первая восьмеричная цифра код операции, потом режимы адресации и номера регистров. Счётчик команд — полноправный регистр, и, насколько я помню, адресация по непострественному адресу делалась как-то через косвенную адресацию к этому регистру. Детали за древностию лет из памяти уже стёрлись, но то, как легко было читать и писать машкоды в простом восьмеричном редакторе, и каким шоком («а я думал, это должно быть логично») после этого было знакомство с системой команд i8086 (ещё далеко не 386) — такое не забывается.
Кстати, вот восьмеричные коды — это как раз то, что мне никогда не нравилось. Довольно непривычно было иметь 16 битовое слово, где правый и левый байт показаны в 8-ричном коде по-разному, при том что значения одинаковые. Так к этому и не привык, все время напрягало немного.
Ну уже тогда всё идеально в такую схему не укладывалось; как минимум:
1) Команды, на которые не хватило опкодов на представление обоих аргументов с адресацией — XOR, MUL, DIV, ASHC;
2) Команды с 8-битным аргументом — условные переходы, EMT, TRAP; 4-битным — CLx, STx;
3) дополнительные наборы (FIS, FPP), которые работали или со стеком (FIS), или на регистрах (FPP).
Основная масса, да, укладывается в упомянутую вами схему (у меня все эти 02ssdd в голове прочно засели;))
> после этого было знакомство с системой команд i8086
Вообще эта идеальная схема уже на VAX не масштабировалась и была сломана там напрочь.
А 8086, как раз, можно было легче читать в восьмеричном виде. Например, типовой уточняющий байт «7:6 — mod, 5:3 — reg, 2:0 — r/m» лучше читался, например, как 360 — reg=SI, r/m=AX — чем в 16ричной. Но почему-то это уже не использовали.
1) Команды, на которые не хватило опкодов на представление обоих аргументов с адресацией — XOR, MUL, DIV, ASHC;
2) Команды с 8-битным аргументом — условные переходы, EMT, TRAP; 4-битным — CLx, STx;
3) дополнительные наборы (FIS, FPP), которые работали или со стеком (FIS), или на регистрах (FPP).
Основная масса, да, укладывается в упомянутую вами схему (у меня все эти 02ssdd в голове прочно засели;))
> после этого было знакомство с системой команд i8086
Вообще эта идеальная схема уже на VAX не масштабировалась и была сломана там напрочь.
А 8086, как раз, можно было легче читать в восьмеричном виде. Например, типовой уточняющий байт «7:6 — mod, 5:3 — reg, 2:0 — r/m» лучше читался, например, как 360 — reg=SI, r/m=AX — чем в 16ричной. Но почему-то это уже не использовали.
Абсолютно и полностью с вами соглашусь, как-то пришлось разобраться с VAX, чтобы помочь сыну маминой подруги с лабами, не ожидал, что ассемблер может быть настолько удобным и многофункциональным.
Вы видели ассемблер S/360?
Я видел. Существенные недостатки по сравнению с PDP-11 и наследниками:
1. Неприятные костыли с IAR-based адресацией (BALR 15,0 / USING *,15 и т.п.) В PDP-11 адресация по %7 предельно естественна и даёт к тому же вкусные режимы без дополнительных сущностей. В VAX это повторено.
2. Резко ограниченные и, самое неприятное, неотрицательные смещения в командах. (Частично исправлено в S/390, ценой расширения на Y-варианты с удлинением команд.) Понятно, что они были почти первые, но больше такой ошибки с беззнаковостью смещений никто не повторял.
Но сейчас запомнить, где у каких команд есть G, Y, F, прочие расширенные варианты, как они совмещаются, очень сложно.
3. Проблемы с загрузкой произвольных констант, что очень неприятно для ручного кодинга. Фактически, если не из памяти, то для этого годилась только LA и давала 0..4095. Всякие IIHF, LLILF это уже S/390.
4. Ограниченная схема condition codes. Схема NZVC, появившаяся в PDP-11, создана гением, даже если он это сделал ненамеренно. Не зря она тиражировалась потом всеми, кто вообще использовал CC. То, что в S/360, требовало постоянного выворота сознания при использовании.
5. Странные костыли с LPR, LNR… вы хоть раз применение LNR вживую видели? ;)
6. Десятичная арифметика на памяти, упакованная и распакованная — при отсутствии нормального динамического управления памятью на этом можно было слегка повеситься. Туда же всякие EDMK.
В остальном, да, достаточно неплохо сработано :)
1. Неприятные костыли с IAR-based адресацией (BALR 15,0 / USING *,15 и т.п.) В PDP-11 адресация по %7 предельно естественна и даёт к тому же вкусные режимы без дополнительных сущностей. В VAX это повторено.
2. Резко ограниченные и, самое неприятное, неотрицательные смещения в командах. (Частично исправлено в S/390, ценой расширения на Y-варианты с удлинением команд.) Понятно, что они были почти первые, но больше такой ошибки с беззнаковостью смещений никто не повторял.
Но сейчас запомнить, где у каких команд есть G, Y, F, прочие расширенные варианты, как они совмещаются, очень сложно.
3. Проблемы с загрузкой произвольных констант, что очень неприятно для ручного кодинга. Фактически, если не из памяти, то для этого годилась только LA и давала 0..4095. Всякие IIHF, LLILF это уже S/390.
4. Ограниченная схема condition codes. Схема NZVC, появившаяся в PDP-11, создана гением, даже если он это сделал ненамеренно. Не зря она тиражировалась потом всеми, кто вообще использовал CC. То, что в S/360, требовало постоянного выворота сознания при использовании.
5. Странные костыли с LPR, LNR… вы хоть раз применение LNR вживую видели? ;)
6. Десятичная арифметика на памяти, упакованная и распакованная — при отсутствии нормального динамического управления памятью на этом можно было слегка повеситься. Туда же всякие EDMK.
В остальном, да, достаточно неплохо сработано :)
На мой взгляд, вы это все говорите про архитектуру машины, а не про ассемблер. Я бы не путал эти две вещи. В остальном согласен, хотя особой мороки с 3 не припомню. Да и остальных кроме 1 пожалуй тоже.
> На мой взгляд, вы это все говорите про архитектуру машины, а не про ассемблер. Я бы не путал эти две вещи.
Они обычно смешиваются, но я имел в виду, думаю, то же самое, что собеседник: систему команд. Сам ассемблер как набор конкретных слов и методов текстовой записи команд, или его всякие условные, циклические и макроконструкции тут не так важны, потому что универсальны и достаточно сходны у всех.
> В остальном согласен, хотя особой мороки с 3 не припомню.
Её ассемблер частично брал на себя — что универсально для многих реализаций (например, так же делают на ARM, MIPS...)
> Да и остальных кроме 1 пожалуй тоже.
Ну я пытался через десятичную арифметику пробрался… ниасилил по молодости.
Они обычно смешиваются, но я имел в виду, думаю, то же самое, что собеседник: систему команд. Сам ассемблер как набор конкретных слов и методов текстовой записи команд, или его всякие условные, циклические и макроконструкции тут не так важны, потому что универсальны и достаточно сходны у всех.
> В остальном согласен, хотя особой мороки с 3 не припомню.
Её ассемблер частично брал на себя — что универсально для многих реализаций (например, так же делают на ARM, MIPS...)
> Да и остальных кроме 1 пожалуй тоже.
Ну я пытался через десятичную арифметику пробрался… ниасилил по молодости.
>То, что в S/360, требовало постоянного выворота сознания при использовании
У меня это был первый ассемблер, так что не требовало. Зашло как данность, видимо.
У меня это был первый ассемблер, так что не требовало. Зашло как данность, видимо.
> У меня это был первый ассемблер, так что не требовало. Зашло как данность, видимо.
У меня тоже. Но увидев NZVC забыл схему S/360 как страшный сон.
У меня тоже. Но увидев NZVC забыл схему S/360 как страшный сон.
Хм. Ну не знаю. Меня реально ничто не напрягало. Я просто никогда не упарывался с производительностью, потому что по тем временам железо имелось (и на ЕС-ках оно было сильно более мощное в среднем), а для задач бизнеса, условно, ты пишешь так как привычно, и так как научился по образцам. А образцы, грубо говоря, это исходники тех же OS/360 (ограничено) или VM/SP (доступна практически вся). Ну и макросредства на мой взгляд, были сильно получше. Были макро переменные, включая массивы, а где массивы — там стек, а где стек — там можно было сделать реализацию IF/THEN/ELSE и DO/WHILE на макросах. Мы как-то прикидывали, можно ли это сделать без массивов, пришли к выводу, что вроде можно — но упороться придется знатно ;)
«Многие пользователи программировали на языке ассемблера без удобных редакторов и IDE, файловых систем и отладчиков, доступных на больших системах.»
В 1985 году, когда я пришел учиться в МЭИ, на кафедре стояла Электроника 100/25, аналог PDP 11/40 с операционной системой RSX-11M v4.1. И в ней действительно не было привычного сейчас редактора с IDE, как впрочем и компилятора Си.
А вот в 1986 году на ней появился Микромир (MIM), в котором редактор уже был, как и интерактивная работа с файловой системой. И одновременно с ним редактор TED, более продвинутый, но тяжеловесный в использовании. Надо понимать, что для работы использовались терминалы с последовательным портом на 9600 бит/сек, что сильно замедляло ввод/вывод, особенно в многопользовательской среде.
В 1985 году, когда я пришел учиться в МЭИ, на кафедре стояла Электроника 100/25, аналог PDP 11/40 с операционной системой RSX-11M v4.1. И в ней действительно не было привычного сейчас редактора с IDE, как впрочем и компилятора Си.
А вот в 1986 году на ней появился Микромир (MIM), в котором редактор уже был, как и интерактивная работа с файловой системой. И одновременно с ним редактор TED, более продвинутый, но тяжеловесный в использовании. Надо понимать, что для работы использовались терминалы с последовательным портом на 9600 бит/сек, что сильно замедляло ввод/вывод, особенно в многопользовательской среде.
А Микромир был портирован под 8086, я его последний раз видел запущенным на NT4.
Так что, возможно, его еще даже можно «пощупать».
Примечательно, что Микромир был уже IDE, и имел функцию инлайн компиляции на Паскале (или Фортране?)
Так что, возможно, его еще даже можно «пощупать».
Примечательно, что Микромир был уже IDE, и имел функцию инлайн компиляции на Паскале (или Фортране?)
Была СМ4 с памятью на ферритовых кольцах, ребята заменили на память от Электорники 60
поставили последовательные порты. РАФОС — многотерминальный режим по полной…
сначала смотрел с удивлением, как ребята писали программки в машинных кодах прямо с клавиатуры (не большие, тестовые), потом сам освоил — оказалось намного проще чем для 580проца, потом Макро11 для кристалла 1806ВМ1 (если память не изменяет, тот который с током потребления мкА)… и всё из PDP11
А когда появились первые PC — появилась и «персоналка» на чем-то с системой команд PDP11, с жесткими дисками 10мегабайт. Не чуть не хуже PC.
поставили последовательные порты. РАФОС — многотерминальный режим по полной…
сначала смотрел с удивлением, как ребята писали программки в машинных кодах прямо с клавиатуры (не большие, тестовые), потом сам освоил — оказалось намного проще чем для 580проца, потом Макро11 для кристалла 1806ВМ1 (если память не изменяет, тот который с током потребления мкА)… и всё из PDP11
А когда появились первые PC — появилась и «персоналка» на чем-то с системой команд PDP11, с жесткими дисками 10мегабайт. Не чуть не хуже PC.
Да, редактор, встроенный в RSX-11М (ОС РВ), был строковый «EDIT». Основной режим работы в нём был таков:
1. Вывести заданное число строк,
2. Найти проблему
3. Ввести команду исправления.
4. Вывести те же строки и проверить.
Что интересно, работать в нём было одно удовольствие. И писать в нём было ничуть не медленнее, чем в приближённом к современным TED. Раньше задачи были реальными, не шаблонными интернет-магазинами и «обращениями пользователей», и требовалось помыслить, прежде чем сделать. И режим «EDIT» прекрасно подходил под такой режим работы.
Отладка было ТОЛЬКО с помощью дополнительного вывода промежуточных значений на печать при исполнении программы. И её хватало для достижения результата. Символьные отладчики в концу 1980-х тоже появлялись, но работали очень медленно.
Общий принцип был: пиши программу так, чтобы она сразу заработала, максимально анализируй её по тексту. Ошибок синтаксических должно быть минимальное ко-во. И этот подход нравится много больше чем современный тяп-ляп: а-а-а, ничего страшного, ну, сделаем останов, ну, посмотрим состояние переменных… и исправим как надо…
1. Вывести заданное число строк,
2. Найти проблему
3. Ввести команду исправления.
4. Вывести те же строки и проверить.
Что интересно, работать в нём было одно удовольствие. И писать в нём было ничуть не медленнее, чем в приближённом к современным TED. Раньше задачи были реальными, не шаблонными интернет-магазинами и «обращениями пользователей», и требовалось помыслить, прежде чем сделать. И режим «EDIT» прекрасно подходил под такой режим работы.
Отладка было ТОЛЬКО с помощью дополнительного вывода промежуточных значений на печать при исполнении программы. И её хватало для достижения результата. Символьные отладчики в концу 1980-х тоже появлялись, но работали очень медленно.
Общий принцип был: пиши программу так, чтобы она сразу заработала, максимально анализируй её по тексту. Ошибок синтаксических должно быть минимальное ко-во. И этот подход нравится много больше чем современный тяп-ляп: а-а-а, ничего страшного, ну, сделаем останов, ну, посмотрим состояние переменных… и исправим как надо…
Строчный редактор ED был такой не потому что это круто, а потому что видимо ноги у него росли из дотерминальной эпохи, когда устройством ввода-вывода была АЦПУ с клавой, типа CONSUL и прочие... На бумаге не поредактируешь, можно только один раз напечатать.
Вы правы, полагаю. Насчёт консольного вывода (дотерминального). Но вспоминаю его всё равно как весьма полезный инструмент, идеально приспособленный к разработке тех времён. И требующий дисциплины мышления, что важно.
Но нём были написаны многие весьма мощные программы, что говорит о его соответствии задачам.
В т.ч. весьма и весьма интерактивные, с использованием статических меню, например, для того же алфавитно-цифрового дисплея (24 х 80 символов). Шаблоны меню рисовались на экране с помощью клавиш перемещения курсора и символов в нужных местах. И оживлялись уже в коде.
Основной сервисный код писался на ассемблере. С вставками модулей на Фортране, при математических расчётах.
И EDIT (>EDI) вполне удовлетворял.
Позже появился TED, переделанный на терминал VT100 с VT52. Он, наверное, добавил гибкости, особенно в использовании коротких команд и редактирования на месте. Но EDIT был первым.
О! Мой первый компьютер — ДВК на архитектуре PDP-11 и операционкой RJ.
а мой любимый СМ1420 с 16 процессорами (основной, арифметический и матрица 4х4), 6 винтами, 4 магнитофонами (2 ес-вских), барабанный и настольный плоттеры, графический векторный дисплей и пара рабочих терминалов.
Я сам на 1420 не работал, только видел… Коллега, который дневал и ночевал на ВЦ, стойки, в которых она размещалась, называл «пивной конструктив». Когда первый раз увидел — понял почему, высота стойки была ему до подмышки, и бокал с пивом было очень удобно туда ставить :)
А вообще классный был аппарат!!! Ну по тем временам конечно…
А вообще классный был аппарат!!! Ну по тем временам конечно…
RT11 она была. Однозадачная версия имела ядро, «системный монитор» кажется назывался, RT11SJ. Еще были версии RT11FB — с фоновыми задачами, RT11MX (кажется) и самая многозадачная — RT11TS.
Какая-то из версий RT11 была переперта на русский язык, включая диагностику ошибок, но не системные команды. И была полная документация полностью переведенная на русский язык, включая книги по MACRO и FORTRAN. Называлась эта перепертая версия — «РАФОС».
Какая-то из версий RT11 была переперта на русский язык, включая диагностику ошибок, но не системные команды. И была полная документация полностью переведенная на русский язык, включая книги по MACRO и FORTRAN. Называлась эта перепертая версия — «РАФОС».
А ещё выпускался калькулятор Электроника-85
О да. Я про него уже писал: https://habr.com/ru/post/400409/
А я начинал на Электронике-60 (если память не изменяет, аналог какой то модели из серии LSI-11), с 4К слов памяти (8 Кб), перфоленточным вводом, перфолентоынм выводом и консолью Consul-260 (по сути дела — электрическая печатающая машинка) :)
Из ПО — только ассемблер (на перфоленте же). Загружаешь с ленты ассемблер, потом ему с ленты скармливаешь программу на MACRO-11, он на ленту выплевывает объектный модуль. Потому с ленты загружаешь линковщик, ему скармливаешь все объектные модули…
Романтика :)
Из ПО — только ассемблер (на перфоленте же). Загружаешь с ленты ассемблер, потом ему с ленты скармливаешь программу на MACRO-11, он на ленту выплевывает объектный модуль. Потому с ленты загружаешь линковщик, ему скармливаешь все объектные модули…
Романтика :)
Про БК-0010, 0011 и УКНЦ забыли.
Читал как Библию.
Авраам родил Исаака; Исаак родил Иакова; Иаков родил Иуду и братьев его…
...UNIX пришёл в Беркли в 1974 году, ленту привёз Кен Томпсон…
...NextSTEP и производная от BSD стали основой Darwin, OSX и iOS…
… Дэйв Катлер, [...] ушёл в Microsoft в 1988, приведя с собой всю свою команду, и возглавил разработку Windows NT…
Авраам родил Исаака; Исаак родил Иакова; Иаков родил Иуду и братьев его…
...UNIX пришёл в Беркли в 1974 году, ленту привёз Кен Томпсон…
...NextSTEP и производная от BSD стали основой Darwin, OSX и iOS…
… Дэйв Катлер, [...] ушёл в Microsoft в 1988, приведя с собой всю свою команду, и возглавил разработку Windows NT…
А я вот, не очень хорошо знаю ассемблер PDP-11, ведь у меня его не было на БК0010-01, однако, я до сих пор помню почти все коды команд и методики расчета смещения для условных переходов и команды SOB, так как писал прямо в машинных кодах.
Меня вот давно интересует, был ли у архитектуры набора команд PDP-11 один автор, или это плод коллективного творчества? Просто она мне со времен БК-0010 и до сих пор кажется гениальной в своей простоте.
Вспоминается Система Малых ЭВМ (мне посчастливилось программировать на СМ-4)
Процессоры КР1801-ВМ(1,2,3)
Да был MACRO-11 for PDP-11, однако, на доступной ДВК-1 не было дисковода — а в ПЗУ только жуткий basic И ГЛАВНОЕ, возможность писАть в кодах…
Процессоры КР1801-ВМ(1,2,3)
Да был MACRO-11 for PDP-11, однако, на доступной ДВК-1 не было дисковода — а в ПЗУ только жуткий basic И ГЛАВНОЕ, возможность писАть в кодах…
1801 была классная серия… Причем, насколько я помню, полных зарубежных аналогов ВМ-1/2/3 не было. А на БМК из серии 1801 было разработано много контроллеров. Я как то на Ангстреме дорвался до шкафа, в котором была документация на эти разработки — чего там только не было :)
А еще был аналог серии 1801 — серия 1806 на k-mop, исполнения в металлокерамике и бескорпусное. Среди прочего, на 1806ВМ2 был сделана одна из бортовых ЭВМ для станции МИР. А мы на базе бескорпусного варианта разработали БГИС для нашего оборудования :)
А еще был аналог серии 1801 — серия 1806 на k-mop, исполнения в металлокерамике и бескорпусное. Среди прочего, на 1806ВМ2 был сделана одна из бортовых ЭВМ для станции МИР. А мы на базе бескорпусного варианта разработали БГИС для нашего оборудования :)
О, у нас в универе к похожему компьютеру был промышленный робот подключен, только и комп, и робот были советские. И мы вводили программы в машинных кодах на терминале, а потом они исполнялись. Все эти регистры 77хххх: в один регистр пишешь 1 — запускается двигатель, с другого регистра в цикле считываешь состояние концевого выключателя — как 1 пришла — стоп, еще в одном значение пройденного пути от крыльчатки на винтовой передаче.
Хорошая статья. Но я чуть не пропустил ее из-за фразы «ретроспектива компьютерного дизайна». Да еще картинка какого-то модного гаджета с красными тумблерами… Я понимаю, что выражения типа «архитектура ЭВМ» не так красиво звучит как «компьютерный дизайн», но речь в статье идет ведь не о дизайне.
Моей первой была СМ-3, которая в составе ИВК-1 с CAMAC. Работал с ней несколько лет. FORTRAN, ассемблер, Pascal, Modula-2, C… Чего только не было. Восстановление информации на диске, на котором в куче секторов как-то всё «съехало» на один бит, ремонт процессора из-за перегоревшей микросхемы К155-й серии, которую удалось найти, благодаря наличию принципиальной схемы процессора и тщательному анализу выполнения инструкций на уровне микрокоманд. А ещё помню — сделал как-то в RT-11 обработчик прерывания по выключению питания, чтобы сохранять регистры в стеке — память-то ферритовая — энергонезависимая, и после этого можно было не загружать компьютер каждый раз… Но, правда, этим старался не пользоваться. Да, интересное было время…
Тут совсем олды ностальгируют, тем не менее добавлю — приходилось учить данную аппаратуру в университете, и даже делать под нее простые лабораторки на микрокодах в некотором эмуляторе, который скорее всего тоже студенты делали. Спорные впечатления: с одной стороны респект за компактность инструкций и приобретенные знания, а с другой пугающая сложность программирования в микрокодах, от которых мозги закипали…
Наверное, всё же на ассемблере, а не в микрокода, это несколько разные вещи.
Сложность есть, но язык С для того и был создан, чтобы не писать на ассемблере. Хотя в институте я тоже писал на ассемблере под ВМ80 и немного под 8086.
Вот нет, команды мы вводили октетами в восьмиричной системе. А преподаватель без справочника "запускал" код с распечатанной бумаги и говорил, где ошибка (она почти всегда была).
Понятно, вы вводили программу в машинном коде.
Микрокод, это другое. Микрокод, это программа внутри процессора, и пользователю она совершенно недоступна.
Микрокод, это другое. Микрокод, это программа внутри процессора, и пользователю она совершенно недоступна.
Система команд микроконтроллера MSP-430 от TI сделана с большим уважением к наследию PDP-11, да и в том же процессоре Motorola 68000 можно увидеть много похожего на команды PDP-11.
Электроника-60 (клон PDP-11) использовался при производстве одной из линеек ЧПУ станков в СССР и другого производственного оборудования.
P.S. а ++ — += -= в Си языке сделаны для прямой поддержки системы команд PDP-11.
да и * (звёздочки) и & (амперсанды) пришли в Си оттуда же, сделав его эффективным языком.
Тут же появилась и реализация Форт (Forth) языка (FIG-Forth) www.stackosaurus.com/figforth.html
Электроника-60 (клон PDP-11) использовался при производстве одной из линеек ЧПУ станков в СССР и другого производственного оборудования.
P.S. а ++ — += -= в Си языке сделаны для прямой поддержки системы команд PDP-11.
да и * (звёздочки) и & (амперсанды) пришли в Си оттуда же, сделав его эффективным языком.
Тут же появилась и реализация Форт (Forth) языка (FIG-Forth) www.stackosaurus.com/figforth.html
БК, УКНЦ, Дворец Пионеров, кружок информатики. Тоже начинал с них, система команд — это… нечто.
А интересно, где сейчас TI и MSP-430? Проиграли ARM-ам и AVR-ам? Да, первые — 32-разрядные, вторые — классика восьмибита, а 16-битникам выходит что, нет места в современном мире?
А интересно, где сейчас TI и MSP-430? Проиграли ARM-ам и AVR-ам? Да, первые — 32-разрядные, вторые — классика восьмибита, а 16-битникам выходит что, нет места в современном мире?
MSP430 являются 16-битными и вполне выпускаются и сейчас. TI — что вы имеете в виду? Это вообще компания, она много чего выпускает, в том числе и MSP430 и микроконтроллеры/процессоры на ядрах ARM, и на собственных ядрах тоже.
MSP-430 сейчас с памятью FRAM, но т.к. они в целом дороже линейки AVR, STM32 то и популярность в России у них и доступность не такая высокая.
www.mt-system.ru/news/texas-instruments/mikrokontrollery-msp430-c-128-kb-fram
www.mt-system.ru/news/texas-instruments/mikrokontrollery-msp430-c-128-kb-fram
:) Ностальжи
На 3 курсе писали коллективную курсовую на РАФОСЕ — сокурсники ваяли файловую систему с заполнением пустых пространств (аналог FAT), а я — оконный файловый менеджер, сильно «похожий» на NC :), русифицированный :)))
P.S. Это 90-91 год…
На 3 курсе писали коллективную курсовую на РАФОСЕ — сокурсники ваяли файловую систему с заполнением пустых пространств (аналог FAT), а я — оконный файловый менеджер, сильно «похожий» на NC :), русифицированный :)))
P.S. Это 90-91 год…
мы на RSX11 умудрились выполнить первую DoS-атаку…
был в библиотеке вызов — отправка запроса на ввод с клавиатуры терминала. Но т.к. мы были молодыми и глупыми — не знали, как именно он работает, и сделали его в цикле (ну, типа «опроса клавиатуры»). поэтому вся очередь забивалась этими запросами. выдавалось знаменитое сообщение «низкий пул», и система падала… хацкеры™, тудыть…
был в библиотеке вызов — отправка запроса на ввод с клавиатуры терминала. Но т.к. мы были молодыми и глупыми — не знали, как именно он работает, и сделали его в цикле (ну, типа «опроса клавиатуры»). поэтому вся очередь забивалась этими запросами. выдавалось знаменитое сообщение «низкий пул», и система падала… хацкеры™, тудыть…
ДВК-3М с КГД – как первая любовь, запомнился на всю жизнь.
О! А ДВК-4 с КЦГД (с цветным дисплеем) — там контроллер дисплея был программируемым. В нём тоже что-то 1801ВМ стояло и по какому-то ESC коду через последовательный порт туда можно было грузить код и оттуда напрямую обращаться в графическую память. Тогда уже компилятор C появился под RT-11 и я писал на нём модули, которые после компиляции грузились в контроллер дисплея. Было дело, добавляли к этому дисплею команды векторной и растровой графики, чтобы быстрее отрисовывалось.
Да, эти я тоже застал, но на всем факультете их 2 шт. было, ходил вокруг облизывался. Но мы и на КГД хорошо программировали на ассемблере, довольно шустро получалось. Но зато у нас в ТИАСУРЕ были мега крутые персоналки «Электроника-0585» с 5 Мб жестким диском, 512 кб памяти и 32 кб видеопамяти. Правда не было документации по ее программированию )) После ДВК-3 она воспринималась как суперЭВМ )
1986 год. Тема «Прибор 86». ДВК-2М, программу разрабатывали на Паскаль Рафос.
Память на гибких дисках.
Память на гибких дисках.
НЛО прилетело и опубликовало эту надпись здесь
СМ3, СМ1407, СМ1420, Электроника79, Электроника60,MERA660, завод Ленина,… ностальгия…
НЛО прилетело и опубликовало эту надпись здесь
Нет, не взлетит. Причина в том, что в архитектуре PDP-11 возможен доступ к памяти из любой команды (так как для любого операнда мы можем выбирать один из многих режимов адресации). «Ортогональность» системы команд по отношению к режимам адресации обеспечила этой системе бешеную популярность в то время, потому что это очень удобно как для программирования на ассемблере, так и для компиляции программ на С.
Но в современных системах процессор работает на порядки быстрее, чем происходит доступ к памяти (поэтому и используется 2-3 уровня кэша). Это делает бессмысленным частый доступ к памяти. Поэтому в современных архитектурах доступ к памяти ограничен выделенными командами Load и Store (LD/ST), а остальные команды могут оперировать только с регистрами или константами.
PDP-11 на современных технологиях будет работать на порядок медленнее RISC-процессора на той же технологии и с той же частотой, потому что большую часть времени будет просто простаивать, ожидая загрузки данных из памяти.
Но в современных системах процессор работает на порядки быстрее, чем происходит доступ к памяти (поэтому и используется 2-3 уровня кэша). Это делает бессмысленным частый доступ к памяти. Поэтому в современных архитектурах доступ к памяти ограничен выделенными командами Load и Store (LD/ST), а остальные команды могут оперировать только с регистрами или константами.
PDP-11 на современных технологиях будет работать на порядок медленнее RISC-процессора на той же технологии и с той же частотой, потому что большую часть времени будет просто простаивать, ожидая загрузки данных из памяти.
а разве в этом случае кэш работать не будет? ведь обращение к памяти идет не по всему адресному пространству рандомно-равномерно, а более-менее упорядоченно…
> Поэтому в современных архитектурах доступ к памяти ограничен выделенными командами Load и Store (LD/ST), а остальные команды могут оперировать только с регистрами или константами.
1. В x86 никто не устраняет команды типа add [rax], ebx. Внутри они, да, транслируются в load+op(reg,reg,reg)+store, но то внутри. И простой от этого не возникает.
PDP-11 затранслировался бы не хуже.
Ещё есть ARM с его пре- и пост-модификациями индексных регистров, причём даже гибче, чем в PDP-11 (на любое смещение в пределах 12 бит).
2. Есть атомарные операции. x86 использует стиль CAS (cmpxchg, xadd...) Да, это типа не RISC, но и у SPARC — CAS, и совершенно новый RISC-V тоже его использует (всё семейство amoswap, amoadd, и так далее), несмотря на то, что обычных операций такого рода у них нет.
Со внутренней трансляцией CISC-команд это всё работало бы не хуже.
А вот что делает неизменную PDP-11 неэффективной, кроме собственно разрядности памяти и регистров (предположим, что мы с ней как-то справились не сломав систему команд совсем) — просто недостаток регистров. Также есть немного более мелких факторов типа модификации флагов условий командой MOV — все новые разработки после этого не повторяли эту диверсию. Вообще тут лучше всего на сейчас или стиль ARM/SPARC — флаги модифицируются только командами с явным указанием модификации (и не всех есть такие варианты), или стиль MIPS/Alpha/RISC-V — явных флагов просто нет
1. В x86 никто не устраняет команды типа add [rax], ebx. Внутри они, да, транслируются в load+op(reg,reg,reg)+store, но то внутри. И простой от этого не возникает.
PDP-11 затранслировался бы не хуже.
Ещё есть ARM с его пре- и пост-модификациями индексных регистров, причём даже гибче, чем в PDP-11 (на любое смещение в пределах 12 бит).
2. Есть атомарные операции. x86 использует стиль CAS (cmpxchg, xadd...) Да, это типа не RISC, но и у SPARC — CAS, и совершенно новый RISC-V тоже его использует (всё семейство amoswap, amoadd, и так далее), несмотря на то, что обычных операций такого рода у них нет.
Со внутренней трансляцией CISC-команд это всё работало бы не хуже.
А вот что делает неизменную PDP-11 неэффективной, кроме собственно разрядности памяти и регистров (предположим, что мы с ней как-то справились не сломав систему команд совсем) — просто недостаток регистров. Также есть немного более мелких факторов типа модификации флагов условий командой MOV — все новые разработки после этого не повторяли эту диверсию. Вообще тут лучше всего на сейчас или стиль ARM/SPARC — флаги модифицируются только командами с явным указанием модификации (и не всех есть такие варианты), или стиль MIPS/Alpha/RISC-V — явных флагов просто нет
А что именно, по-вашему, осталось бы от PDP-11, если её осовременить?
64 бита адрес и данные? Значит, старый метод «константа в потоке данных» неэффективен — придётся делать минимум команду в 64 бита, оно того явно не стоит. На самом деле уже VAX-11 сломал этот принцип.
6 общих регистров (SP, PC не считаем)? Мало, надо расширять (минимум 12-13, а лучше 15-20).
Что остаётся? Общий принцип произвольной адресации? Ну x86 же справляется с чуть менее гибкой системой команд, и тут справились бы (хотя и ещё дороже).
Просто это примерно как редизайн Запорожца в Мерседес S600. Просто двигатель не поменять, нужно расширять моторный отсек, усиливать тормоза, одно это достаточно, чтобы все узлы перекроить, хоть и понемногу. Ну так у нас есть сейчас x86, ARM, MIPS и десятки прочих…
64 бита адрес и данные? Значит, старый метод «константа в потоке данных» неэффективен — придётся делать минимум команду в 64 бита, оно того явно не стоит. На самом деле уже VAX-11 сломал этот принцип.
6 общих регистров (SP, PC не считаем)? Мало, надо расширять (минимум 12-13, а лучше 15-20).
Что остаётся? Общий принцип произвольной адресации? Ну x86 же справляется с чуть менее гибкой системой команд, и тут справились бы (хотя и ещё дороже).
Просто это примерно как редизайн Запорожца в Мерседес S600. Просто двигатель не поменять, нужно расширять моторный отсек, усиливать тормоза, одно это достаточно, чтобы все узлы перекроить, хоть и понемногу. Ну так у нас есть сейчас x86, ARM, MIPS и десятки прочих…
.
Опечатки:
«2,5 битную кодировку инструкций» – судя по контексту, имелась в виду «2,5-словная кодировка» (40 бит – это 2,5 16-битных слова).
«использует 6 бит на регистр» – правильно «на регистрЫ» (потому что 2 регистра по 3 бита каждый).
«2,5 битную кодировку инструкций» – судя по контексту, имелась в виду «2,5-словная кодировка» (40 бит – это 2,5 16-битных слова).
«использует 6 бит на регистр» – правильно «на регистрЫ» (потому что 2 регистра по 3 бита каждый).
1. Исправил.
2. Про 6 бит на регтстр, там не всё так просто, потому что регистр кодируется 3 битами, и ещё 3 бита — режим адресации. И код команды может быть разного размера для разных операций. Пусть останется так пока, кому интересно, могут скачать описание системы команд и почитать.
Просьба в следующий раз писать про найденные ошибки в личку, в соответствии с правилами сайта.
2. Про 6 бит на регтстр, там не всё так просто, потому что регистр кодируется 3 битами, и ещё 3 бита — режим адресации. И код команды может быть разного размера для разных операций. Пусть останется так пока, кому интересно, могут скачать описание системы команд и почитать.
Просьба в следующий раз писать про найденные ошибки в личку, в соответствии с правилами сайта.
В школе был класс с ДВК и БКшками.В 2004 году, в ВУЗе писал на листке бумаги, код на Ассемблере, потом переводил в машинный код и кнопками загружал в память микропроцессорного комплекта, на отечественном аналоге PDP. В 2006, уже на работе, в военке, столкнулся 1806ВМ2, в платы в кассетах.
Я понимаю любовь народа к PDP-11, сам такой же, но .... причем тут RISC? PDP-11 не является RISC-ом ни под каким соусом, ее виды адресации с аутоинкрементом и аутодекрементом, двухоперандные команды, которые смешивают арифметику с доступом к памяти - это совсем не RISC. Эти штучки вносят тонну конфликтов при конвейерной реализации процессора. Это наоборот, один из классических примеров CISC, а вовсе не RISC.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Чему нас научила PDP-11?