Совершенно верно. Диспетчеры и RTOS в этом плане существенно проигрывают автоматному программированию.
Ассемблер (ASM) для AVR в вопросах и ответах
- Сообщения: 1495
- Зарегистрирован: Ср июн 25, 2008 15:19:44
[uquote="ARV",url="/forum/viewtopic.php?p=3704635#p3704635"]вы не видите разницу между командой ret или jmp и алгоритмом, в котором эти команды перемещают программный счетчик в неожиданное место, не отслеживаемое "разумом"? вы никогда не сможете предсказать, в каком состоянии находится программа, написанная при таком подходе, просто взглянув на её текущий "снимок" РОН и PC - .[/uquote]
Совершенно верно. Диспетчеры и RTOS в этом плане существенно проигрывают автоматному программированию.
Совершенно верно. Диспетчеры и RTOS в этом плане существенно проигрывают автоматному программированию.
- Реклама
ARV, поэтому, когда таким образом я реализую кооперативную мультизадачность, я отдаю себе отчёт, что не знаю через какой промежуток времени у какой задачи будет управление. Такова цена почти любой мультизадачности и ничего Вы с этим не сделаете
Я и сам не хочу с этим ничего делать, да и другим не советую. "Мультизадачность" по обычным прерываниям в 100500 раз проще и понятнее, менее проблема в отладке и без побочных эффектов.
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
Мой уютный бложик... заходите!
при взгляде на многих сверху ничего не меняется...
Мой уютный бложик... заходите!
"Чистый ассемблер" предусматривает ПОЛНОЕ ПЛАНИРОВАНИЕ ресурсов МК автором проекта.
Под Си есть естественные ограничения для ассемблера - планировка ресурсов, включая стек, модель регистров и проччее.
С одной стороны как проектировщику на ассемблере это "серпом по....", с другой - преимущества ЯВУ.
Ассемблерные вставки под Си допустимы и в спецслучаях весьма удобны... НО оные делаются уже ВНУТРИ правил, определяемых компилятором Си а это таки довольно жесткие рамочные правила. Да и приемы, являющиеся основой проектов под "чистым асмом" при работе с ассемблерными вставками часто просто НЕДОПУСТИМЫ.

Под Си есть естественные ограничения для ассемблера - планировка ресурсов, включая стек, модель регистров и проччее.
С одной стороны как проектировщику на ассемблере это "серпом по....", с другой - преимущества ЯВУ.
Ассемблерные вставки под Си допустимы и в спецслучаях весьма удобны... НО оные делаются уже ВНУТРИ правил, определяемых компилятором Си а это таки довольно жесткие рамочные правила. Да и приемы, являющиеся основой проектов под "чистым асмом" при работе с ассемблерными вставками часто просто НЕДОПУСТИМЫ.
ARV, проще, но менее универсальна. Она применима только в случае, если во всем коде есть только один длительный расчет, способный занять ресурсы CPU на длительное время. Если же необходимость в таких расчетах возникает асинхронно, то приходится реализовывать мультизадачность. А кооперативная мультизадачность, при всех ее недостатках, экономит и память, и ресурсы CPU, в сравнении с мультизадачностью по таймеру.
Добавлено after 5 minutes 1 second:
BOB51, когда требуется даже 32-битная арифметика, не говоря уже об арифметике с фиксированной точкой с ее алгебраическими функциями, кодировать это на ассемблере, вместо использования ЯВУ - совершенно неоправданная трата времени. Оптимальнее того же GCC все равно вряд ли напишете, а времени потратите в разы больше.
Добавлено after 5 minutes 1 second:
BOB51, когда требуется даже 32-битная арифметика, не говоря уже об арифметике с фиксированной точкой с ее алгебраическими функциями, кодировать это на ассемблере, вместо использования ЯВУ - совершенно неоправданная трата времени. Оптимальнее того же GCC все равно вряд ли напишете, а времени потратите в разы больше.
- Реклама
Я, в конце 80-х - начале 90-х, писал по такому принципу драйвера для наших клонов PDP-11 (Электроника-60, ДВК), для ОС RT-11. В той системе команд это получалось изящно и элегантно. Но, в принципе, оно работоспособно на любом процессоре, где вызов CALL помещает адрес возврата в стек и его оттуда можно достать не только RETURN'ом, но и обычным добыванием числа из стека, вроде команды POP. В частности, оно неплохо получалось и под MS-DOS, хотя там я так толком и не освоил АСМ - не смог преодолеть рвотный барьер при переходе от изящной архтиектуры PDP-11 к убожеству х86.Demiurg писал(а):Хотелось бы увидеть вашу реализацию.
Здесь, в смысле с AVR, я тоже попробовал программировать, используя этот прием, и тоже получилось неплохо, но боевой задачи у меня не было, только учебно-тренировочная. Убедился, что получается хорошо, и забросил. А затем и вообще утратил интерес к AVR и переключился на STM32, а там на асме толком не попрограммируешь. Зато Си вспомнил...
В общем, если надо, могу прислать что-нибудь из драйверов PDP-11, это законченные программы, в отличие от пробных вещей на AVR.
Не помню, зачем мне понадобилось включить в проект на АСМе вычисление по какой-то довольно сложной формуле. Написал раз, что-то не то. Второй - тоже. Плюнул, написал этот кусок на Фортране, оттранслировал его компилятором уровня H с предельной оптимизацией и с выдачей ассемблерного текста, после чего вырезал нужную часть и включил ее в свою программу на АСМе. Дело было году в 83-85, ЕС ЭВМ aka Система 360.ПростоНуб писал(а):когда требуется даже 32-битная арифметика, не говоря уже об арифметике с фиксированной точкой с ее алгебраическими функциями, кодировать это на ассемблере, вместо использования ЯВУ
Это с одной стороны. С другой, существует куча действий, которые невозможно выразить на ЯВУ, но элементарно делаемых на асме. Тот же самый мой пример.
Кто мешает тебе выдумать порох непромокаемый? (К. Прутков, мысль № 133)
afz, во-первых, уже в начале 80-х, найти IBM/360 было нереально. MVT почило в бозе раньше и везде уже были, как минимум, IBM/370 с поддержкой виртуальной памяти и, как минимум, под SVS, если не TKS или даже VM/SP или СВМ. А ассемблер под SVS, особенно при общении с каналами ввода-вывода с их абсолютной адресацией памяти - совершенно иная задача, чем под MVT/MFT/DOS, где виртуальной памяти не было в помине.
Во-вторых, мне совершенно непонятно, нахрена было усложнять сборку проекта преобразованием объектного кода выдаваемого компилятором в ассемблерный исходный код на каком-то убогом REXX, если этот код можно было и так без проблем слинковать с ассемблерным объектным файлом. Или вы после каждой правки в Fortran или PL/I вручную таскали этот код, без автоматизации сборки?
Во-вторых, мне совершенно непонятно, нахрена было усложнять сборку проекта преобразованием объектного кода выдаваемого компилятором в ассемблерный исходный код на каком-то убогом REXX, если этот код можно было и так без проблем слинковать с ассемблерным объектным файлом. Или вы после каждой правки в Fortran или PL/I вручную таскали этот код, без автоматизации сборки?
упомянутые принципы широко и повсеместно использют вирусописатели, а так же всевозможные самомодифицирующиеся программы. в МК это менее полезно. и, при всем том, что так делать МОЖНО, я продолжаю говорить, что делать так НЕ НУЖНО.
всё, коллеги, более не смею вас загружать моим мнением - я его вполне конкретно и однозначно высказал, переубеждать меня не надо. себе в ногу можете стрелять сколько угодно.
всё, коллеги, более не смею вас загружать моим мнением - я его вполне конкретно и однозначно высказал, переубеждать меня не надо. себе в ногу можете стрелять сколько угодно.
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
Мой уютный бложик... заходите!
при взгляде на многих сверху ничего не меняется...
Мой уютный бложик... заходите!
Ага, два раза. Первую ЕС-ку, конкретно - ЕС 1022, наш Политех получил около 77-го, с 256К ферритовой памяти и двумя болгарскими клонами IBM2311, диски 6.25М, не помню, как их звали у нас. Вторую, тоже 1022, в 80-м. Чуть поновее - с 512К электронной памяти ( куча м/с К565РУ1) и тремя ЕС5061, болгарский клон IBM2314, диски 29М. А первую из Ряда 2 - кажется 1036, точно не помню, я уже там не работал - в 86 или 87. И наш Политех был довольно продвинутый: на ВЦ ПО Карагандауголь - самая наша крутизна тех времен - были те же самые машинки, только числом поболее.ПростоНуб писал(а):во-первых, уже в начале 80-х, найти IBM/360 было нереально.
Это было разовое действие, была какая-то "железная" формула, что-то связанное с учетом заданий в ДОС ЕС aka DOS/TOS 360, подробностей совсем не помню. А цеплять туда куски фортрановской ран-тайм системы и соблюдать соглашения о связях не было ни малейшего желания.ПростоНуб писал(а):Во-вторых, мне совершенно непонятно, нахрена было усложнять сборку проекта
2All: Чего еще не хватает большинству ЯВУ - это "внутренних подпрограмм", т е. возможности выполнить кусок программы, как подпрограмму, в общем контексте. Я знаю два таких языка - классический Бейсик (оператор GOSUB) и ДИАМС, в котором оператор DO может выполнить что угодно - от внешней программы до нескольких специально отмеченных строк за ним. А на асме, опять же, без вопросов. Вот, например, для AVR:
Код: Выделить всё
; R4 to HEX
; Вход: R4 - исходный байт
; Выход - два байта по X+
; Рабочий регистр - R18
HEX:
add r2,r4
mov r18,r4
swap r18
rcall hex1
mov r18,r4
HEX1: andi r18,0x0F
cpi r18,10
brlt hex2
subi r18,('0'-'A'+10)
HEX2: subi r18,0xD0 ; -'0'
st x+,r18
ret
Последний раз редактировалось afz Сб сен 21, 2019 21:20:03, всего редактировалось 1 раз.
Кто мешает тебе выдумать порох непромокаемый? (К. Прутков, мысль № 133)
в ЯВУ почти никогда не возникает такой необходимости, так как его назначение несколько иное. да и в ассемблере показанный вами пример полезен только при острой нехватке памяти... или при "спортивном" программированииafz писал(а):Какой ЯВУ на такое способен?
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
Мой уютный бложик... заходите!
при взгляде на многих сверху ничего не меняется...
Мой уютный бложик... заходите!
afz, 1036 - это уже ряд-3 или IBM/380. Она выпускалась с 1983 по 1989 год. Ряд-2 или IBM/370 начался с ЕС1035, выпускавшейся с 1977 по 1986. Вы же указали 1983-86 годы, когда ряд-1 уже почил в бозе. Я же в 1984 уже 1046 осваивал.
И вы так и не объяснили необходимость ручных операций при сборке проекта. К тому же уж с математикой на ассемблере IBM/370 проблем не было. 64-битный блок арифметики с плавающей запятой легко позволял вычислять что угодно машинными командами. Это не 8-битный AVR без аппаратной операции деления, где элементарные математические операции с 32-битными операндами уже представляют собой проблему.
И вы так и не объяснили необходимость ручных операций при сборке проекта. К тому же уж с математикой на ассемблере IBM/370 проблем не было. 64-битный блок арифметики с плавающей запятой легко позволял вычислять что угодно машинными командами. Это не 8-битный AVR без аппаратной операции деления, где элементарные математические операции с 32-битными операндами уже представляют собой проблему.
- Сообщения: 2567
- Зарегистрирован: Вт май 01, 2018 19:44:47
[uquote="afz",url="/forum/viewtopic.php?p=3704999#p3704999"]И какого размера у вас выйдет программуля, исполняющая ту же функцию, но написанная на ЯВУ ?[/uquote]А давай попробуем? Мне на ЯВУ не надо сохранять результат через X+, поэтому прокрутим через регистры
Листинг
По размеру на несколько команд больше (в прошивку линкер сами функции не добавит, компилятор их заинлайнил), а по скорости выполнения, которая зачастую важнее, я бы даже поспорил.
Добавлено after 49 minutes 29 seconds:
[uquote="afz",url="/forum/viewtopic.php?p=3704999#p3704999"]Какой ЯВУ на такое способен?[/uquote]Вот ты на малюсеньком кусочке кода обошёл ЯВУ. И то, чистую победу я бы тут не отдал. А способен ты сделать это на реальном проекте? Ведь оптимизатор ЯВУ без устали молотит каждую строку кода. И даже разные единицы компиляции на этапе lto дооптимизирует.
Добавлено after 24 minutes 56 seconds:
А теперь берём и лёгким движерием руки переносим этот код на STM8, к примеру. Или может на STM32? Засекаем время или результат понятен?
Код: Выделить всё
#include <ioavr.h>
#include <stdint.h>
uint8_t NibleToHex(uint8_t x)
{
return x<10?x+'0':x+'A'-10;
}
uint16_t ToHex(uint8_t x)
{
return (NibleToHex(x>>4)<<8) + NibleToHex(x&0xF);
}
int main()
{
return ToHex(PINB);
}Спойлер
Код: Выделить всё
//uint8_t NibleToHex(uint8_t x)
??NibleToHex:
//{
// return x<10?x+'0':x+'A'-10;
CPI R16, 10
BRCC ??NibleToHex_1
SUBI R16, 208
RET
??NibleToHex_1:
SUBI R16, 201
RET
//}
//uint16_t ToHex(uint8_t x)
??ToHex:
//{
// return (NibleToHex(x>>4)<<8) + NibleToHex(x&0xF);
MOV R17, R16
SWAP R17
ANDI R17, 0x0F
CPI R17, 10
BRCC ??ToHex_1
SUBI R17, 208
RJMP ??ToHex_2
??ToHex_1:
SUBI R17, 201
??ToHex_2:
ANDI R16, 0x0F
CPI R16, 10
BRCC ??ToHex_3
SUBI R16, 208
RET
??ToHex_3:
SUBI R16, 201
RET
//}
//int main()
main:
//{
// return ToHex(PINB);
IN R18, 0x16
MOV R17, R18
SWAP R17
ANDI R17, 0x0F
CPI R17, 10
BRCC ??main_0
SUBI R17, 208
RJMP ??main_1
??main_0:
SUBI R17, 201
??main_1:
ANDI R18, 0x0F
CPI R18, 10
BRCC ??main_2
SUBI R18, 208
RJMP ??main_3
??main_2:
SUBI R18, 201
??main_3:
MOV R16, R18
RET
//}Добавлено after 49 minutes 29 seconds:
[uquote="afz",url="/forum/viewtopic.php?p=3704999#p3704999"]Какой ЯВУ на такое способен?[/uquote]Вот ты на малюсеньком кусочке кода обошёл ЯВУ. И то, чистую победу я бы тут не отдал. А способен ты сделать это на реальном проекте? Ведь оптимизатор ЯВУ без устали молотит каждую строку кода. И даже разные единицы компиляции на этапе lto дооптимизирует.
Добавлено after 24 minutes 56 seconds:
А теперь берём и лёгким движерием руки переносим этот код на STM8, к примеру. Или может на STM32? Засекаем время или результат понятен?
Ну, в общем-то, да, хотя однажды, когда я что-то впихивал в какую-то мелкую тиньку, это было в тему. Кстати, этот приём я не сам сочинил. Так вполне официалльно рекомендовалось делать в руководстве по программированию для PDP-11, но годится оно практически, для любой машинки со стеком.ARV писал(а):да и в ассемблере показанный вами пример полезен только при острой нехватке памяти... или при "спортивном" программировании
А тот прием, с которого я включился в дискуссию - выход из драйвера путем вызова процедуры выхода, как сопрограммы с манипуляциями стеком, я сочинил сам, модифицируя драйвер простого матричного принтера для наших клонов PDP-11. Казалось бы банальность: отправил в порт данных очередной байт, и жди следующего прерывания. Как говорит молодёжь, "Ага, щазз!.." Во-первых оно буферизованное, т.е., пока не забит буфер, только переслал байт, оно уже готово к приему следующего, а, значит, выходить и ждать прерывания - напрасная потеря времени.
Во-вторых, есть некоторые служебные символы и пр ним нужны некоторые специфические действия. Тот же символ горизонтальной табуляции (HT), который может либо отрабатываться аппаратно и тогда его надо просто отослать на принтер, либо программно, тогда вместо него надо выдать от одного до восьми пробелов. Или символ "новая страница" (FF) - надо отдать либо его, либо прогнать лист символами перевода строки.
А, в третьих, появились принтеры с другими кодировками и понадобилось перекодировать русские буквы. А еще у них была графика, и там, естественно, никаких перекодировок быть не должно. И вот, получили мы прерывание, спрашивается, что пересылать? Ладно, HT и FF там в оригинале как-то прикрутили, но разбираться с графикой и перекодировкой тем же способом - застрелиться. Прикручивать машину состояний - но там возникают сложности во взаимодействии с системой. В общем, я сочинил вот этот вариант с вызовом, подобным сопрограмме и стало все просто. Спокойно разбираю входной поток, как будто это простая линейная программа, когда надо, вызываю программу выхода, не заботясь о том, что где-то работают какие-то другие программы, где-то есть какие-то прерывания и пр.
Во-первых, я указал 83-85. И при этом погорячился, надо было указать 83-84. Поскольку (вспомнил точнее) в первой половине 84-го я уже переключился на Электронику-60 (PDP-11/рус.) и за ЕС-ками больше не следил. Во-вторых, мало ли что-то где-то выпускалось? Я рассказал реальное положение, которое было в нашей глубинке в 84-м.1036 - это уже ряд-3 или IBM/380. Она выпускалась с 1983 по 1989 год. Ряд-2 или IBM/370 начался с ЕС1035, выпускавшейся с 1977 по 1986. Вы же указали 1983-86 годы, когда ряд-1 уже почил в бозе. Я же в 1984 уже 1046 осваивал.
Ага, больше всего в полтора раза.VladislavS писал(а):По размеру на несколько команд больше (в прошивку линкер сами функции не добавит, компилятор их заинлайнил), а по скорости выполнения, которая зачастую важнее, я бы даже поспорил.
И, конечно, задачка фиговая, компилятор в процессе оптимизации, фактически, повторил дважды (почти) одни и те же действия. Будь этих действий не пара, а, хотя бы, десятка два, и пришел бы литовский праздник Обломайтис.
Кто мешает тебе выдумать порох непромокаемый? (К. Прутков, мысль № 133)
- Сообщения: 2567
- Зарегистрирован: Вт май 01, 2018 19:44:47
[uquote="afz",url="/forum/viewtopic.php?p=3705354#p3705354"]Ага, больше всего в полтора раза.
11 команд против 16.[/uquote]Это называется манипуляция данными. При таком малом размере кода одна команда даёт дикий прирост в процентах. А если будет код хотя бы в сотню строк? Зато код из-под компилятора выполняется быстрее и это за частую куда важнее. Я то всегда могу галку с оптимизации по скорости переставить в оптимизацию по размеру, а ты?
[uquote="afz",url="/forum/viewtopic.php?p=3705354#p3705354"]моя программа получает байт сразу в R4, а ты его еще добываешь откуда-то.[/uquote]Интересно получается, у тебя программа из воздуха получает данные, а моя добывает? Я же показал, точно так же в регистре R18 данные пришли, читай внимательней.
[uquote="afz",url="/forum/viewtopic.php?p=3705354#p3705354"]И, конечно, задачка фиговая, компилятор в процессе оптимизации, фактически, повторил дважды (почти) одни и те же действия. Будь этих действий не пара, а, хотя бы, десятка два, и пришел бы литовский праздник Обломайтис.[/uquote]Ну будет цикл на два десятка и чё? И весь твой хитрый поиём превратится в тыкву. Или у тебя не будет цикла? Зато при оптимизации по скорости компилятор сам развернёт цикл если он не очень большой, только галочку поставь.
ЗЫ: Поверь, нет никакого желания холиварить. Просто ты так сказал, будто там компилятор ужас-ужас сделает. Нет, всё вполне сопотавимо и никакой убийственной разницы нет. Это как раз та небольшая плата за все преимущества ЯВУ, и она вполне адекватна.
[uquote="afz",url="/forum/viewtopic.php?p=3705354#p3705354"]моя программа получает байт сразу в R4, а ты его еще добываешь откуда-то.[/uquote]Интересно получается, у тебя программа из воздуха получает данные, а моя добывает? Я же показал, точно так же в регистре R18 данные пришли, читай внимательней.
[uquote="afz",url="/forum/viewtopic.php?p=3705354#p3705354"]И, конечно, задачка фиговая, компилятор в процессе оптимизации, фактически, повторил дважды (почти) одни и те же действия. Будь этих действий не пара, а, хотя бы, десятка два, и пришел бы литовский праздник Обломайтис.[/uquote]Ну будет цикл на два десятка и чё? И весь твой хитрый поиём превратится в тыкву. Или у тебя не будет цикла? Зато при оптимизации по скорости компилятор сам развернёт цикл если он не очень большой, только галочку поставь.
ЗЫ: Поверь, нет никакого желания холиварить. Просто ты так сказал, будто там компилятор ужас-ужас сделает. Нет, всё вполне сопотавимо и никакой убийственной разницы нет. Это как раз та небольшая плата за все преимущества ЯВУ, и она вполне адекватна.
Тогда компилятор не станет его разворачивать дважды, а сгенерит два нормальных вызова. Не знаю, учтет ли он, что не нужны массовые сохранения/восстановления регистров и пр.VladislavS писал(а):А если будет код хотя бы в сотню строк?
....
Собственно, сейчас вопрос: писать или не писать на асме в общем-то и не встает. На асме сейчас имеет смысл писать только что-то в сверхмелкий камушек с полукилобайтом флеши или куда-то еще в том же духе, поскольку совет "возьми камень потолще" трудно отменить.
Я же не зря ссылаюсь не древние системы. Допустим, та же PDP-11. На ее младших моделях применялась ОС RT-11, целиком написанная на асме. Драйвера и служебные программы для нее писались тоже на асме, всякое управляющее хозяйство - то, для чего сейчас применяются МК - тоже писалось на асме. Нет, Си для нее был (на ней его и сочинили), но программы из-под него выходили слишком уж тяжеловесными, а остальные ЯВУ вообще для этого не годились.
И при написании драйверов под нее жестко экономили каждый байт - то, что ты займешь своим драйвером, отнимется у программы пользователя, ведь у младших моделей было всего 56К памяти, даже не 64 - последние 8К занимала страница ввода-вывода.
Сейчас всё это, конечно, на фиг не нужно - написал пару-тройку мелких программуль на асме, чтобы прочувствовать новый камень, и хватит, дальше есть СИ.
Хотя лично мне тот старый опыт программирования на асме для PDP-11 и DOS-360 временами весьма помогает. В частности, многие решения, подсмотренные в недрах тех старых операционок, актуальны до сих пор.
Кто мешает тебе выдумать порох непромокаемый? (К. Прутков, мысль № 133)
- Сообщения: 2567
- Зарегистрирован: Вт май 01, 2018 19:44:47
У меня первым был вот такой двухпроцессорный PDP-11 зверь.

Оффтопик, конечно...
Спойлер
А я под него недавно сочинил контроллер псевдодиска на карточке микро-SD. STM32F407VET6 + логика и мелкие ПЛИС для связи с Q-bus/МПИ. Собственно, я сочинил схему и софтину в STM-ку, а СуперМакс развел два варианта плат - сначала для "больших" клонов этой LSI-11, т.е. наших ДВК, а потом и для вот этой самой машинки. Вот здесь. Там, собственно, сам контроллер, а на первой страницы той темы есть куча ссылок на смежные темы.Кто мешает тебе выдумать порох непромокаемый? (К. Прутков, мысль № 133)
О, подтянулись бывшие коллеги. Мне тоже довелось с DEC-овскими клонами (СМ-4, ДВК-2,3) потрудиться. Сделали ооочень серьезную АСК для негражданских
. На асме. Почему не на Фортране, к примеру ? Исполняющую систему, конечно, без асма никак, микросекунды экономили. Но компилятор можно было бы и на Фортране (Си появился, по крайней мере, у нас несколько позже, на ДВК). Не знаю.
Как смешные воспоминания с той поры (расцвет заката социализма и одновременно фирмы DEC) остался межмашинный интерфейс СМ-4 и ДВК, слепленный за день в железе и софтово, и Бейсик, которого я учил выполнять программы пользователя в реальном времени, скармливая ему машинный код.
Щас другие времена и другие песни, и потому всыпят нам по самое не могу за оффтоп. Ну мне не привыкать...
Как смешные воспоминания с той поры (расцвет заката социализма и одновременно фирмы DEC) остался межмашинный интерфейс СМ-4 и ДВК, слепленный за день в железе и софтово, и Бейсик, которого я учил выполнять программы пользователя в реальном времени, скармливая ему машинный код.
Щас другие времена и другие песни, и потому всыпят нам по самое не могу за оффтоп. Ну мне не привыкать...
Вообще-то те, кому интересна PDP-11 и наши ее клоны, тусуются вот здесь. И коллекционеры, и профи тех времен, и просто любители... Welcome!
Кто мешает тебе выдумать порох непромокаемый? (К. Прутков, мысль № 133)
afz, меня как-то от PDP-11 бог миловал. Нет, конечно экзамен по ее программированию на ассемблере я сдал. Но непосредствнно на ДВК-2 я провел на 2-3 порядка меньше времени, чем на IBM/370 (ЕС-1035/61/46). Ну и на 1-2 порядка меньше, чем на ZX Spectrum. Даже инженерная графика была на СМ-1800 (i8080) или СМ-1700(VAX).



