Comments 84
Ассемблер PDP-11 — до сих пор самый любимый.
это было нечто, приятно вспомнить…
UFO just landed and posted this here
Я понимаю, что формулировка «любимый» в общем-то субъективная, и не всегда предполагает сравнение, и все-таки спрошу — в сравнении с чем?
В смысле — это не из серии «раньше трава была зеленее, лето длиннее в два раза, а синус достигал значения 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М, программу разрабатывали на Паскаль Рафос.
Память на гибких дисках.
Память на гибких дисках.
UFO just landed and posted this here
СМ3, СМ1407, СМ1420, Электроника79, Электроника60,MERA660, завод Ленина,… ностальгия…
UFO just landed and posted this here
Нет, не взлетит. Причина в том, что в архитектуре 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.
Sign up to leave a comment.
Чему нас научила PDP-11?