Ну почему пристрастный. Я на PDPшках (СМках, точней, -- но не суть) прилично программировал на асме, и, как уже сказал, считаю его лучшим из 16-разрядных. Просто там тоже свои извраты есть, как и везде.
А причём здесь WASM, кстати? Это ж не архитектура проца, чтоб иметь свою систему команд.
От красоты или уродства системы команд, как минимум, зависят сложность её декодирования (IA-32 -- кошмар, Система 360 -- прекрасно, ARM -- где-то посредине) и сложность создания эффективного кодогенератора для компиляторов.
А зачем сейчас столько дисков ставят? Хранение и обработка гигантских объёмов информации, естественно.
Канальные программы -- да, примитивные, но свою задачу (разгрузку ЦП от управления вводом-выводом) вполне себе выполняют.
Про конфликты с памятью вроде сказал уже. Если память разделена на несколько банков, то, пока обращения идут к разным банкам, их легко распараллелить средствами многопортового контроллера памяти; кстати говоря, на СМках с 4 Мбайтами память была двухпортовой: один порт для проца, второй -- для периферии. Просто в Системе 360 проще распараллеливать, поскольку память там является единственной общей точкой -- ну а в более привычных архитектурах процессор напрямую обращается к устройствам и ими управляет, что требует обеспечить соответствующую связь, т.е. делать или общую шину, или огромное количество соединений точка-точка с коммутаторами, -- первое медленно, когда устройств много (некритично для мини-ЭВМ, но недопустимо для мощного мэйнфрейма), второе -- очень сложно и затратно по железу.
Что же касается сравнения с VAXом, то с ним корректней уже будет сравнивать поздние варианты Системы 370, а не ранние Системы 360 -- ведь между ними 10, если не больше, лет разницы. "Общая" система команд у VAX приятней будет, в общем и целом; в отдельных вещах он лучше и в специальных случаях, а Система 370 -- в других (десятичную арифметику, кажется, никто лучше так и не сделал -- одна из причин доминирования мэйнфреймов в финансовом секторе). По вводу-выводу VAX сильно уступает -- как уступает и любая современная архитектура (попробуй подключить к ПК -- именно к ПК, не по локалке, -- тысячи дисков, и чтоб оно ещё и летало, -- ну а к мэйнфрейму z/Architecture -- запросто, если у тебя есть деньги на эти тысячи дисков :) ).
На поздней Системе 370 появился механизм двойного адресного пространства (впоследствии расширен до множества адресных пространств), что резко упрощает и ускоряет реализацию программ-серверов, обслуживающих программы-клиенты. Без этого механизма вызов подпрограммы в сервере надо производить через ядро ОС, с ним -- можно вызывать прямо, при этом привилегии у клиента и сервера разные, но всё контролируется и защищено. У VAX ничего подобного я не видел -- хотя с поздними вариантами не знаком. В IA-32 было "жалкое подобие левой руки" -- таблицы дескрипторов со шлюзами вызова позволяют, теоретически, добиться того же, но всё было спроектировано настолько криво, что этими возможностями никто не пользовался (и AMD выпилила их, делая 64-разрядный вариант архитектуры, -- что впоследствии скопировала Интел, провалившись со своей IA-64 aka Itanium). В общем, в плане системной архитектуры, на мой взгляд, Система 360 и её наследники -- лучшее, что было и есть. По системе команд -- VAX лучше, если не брать частности (которые в него вполне можно было бы добавить, конечно). По простоте реализации -- безусловное превосходство Системы 360 (ну, это неудивительно: в первой половине 1960-х развернуться было особо негде, железо ограничивало -- отсюда, кстати, ряд костылей и неудачных решений, и в первую очередь -- 24-разрядный адрес памяти; просто, похоже, никто не думал, что через 20 лет этого будет мало). По гибкости ввода-вывода -- превосходство VAX, но по пропускной способности -- Системы 360.
В общем, разные архитектуры друг друга не исключают, а дополняют. Ставить Систему 360 в качестве управляющей машины -- верх идиотизма, пытаться заменить один мэйнфрейм тыщей персоналок -- примерно то же самое. Надо исходить из задачи и выбирать адекватные средства.
Ну, система команд PDP-11, как по мне, -- лучшая среди 16-разрядных, а VAX-11 -- среди 32-разрядных, но, как говорится, есть нюансы.
Адресация у DECовских машин более гибкая и эффективная, что, естественно, способствует сокращению объёма программы и потенциально -- повышению производительности. В то же время базовая система команд Системы 360 более проста для реализации (пять чётких форматов команд, не имеющих значимых с точки зрения выборки-декодирования исключений, более простая адресация -- обычная сумма одного-двух регистров и смещения, без всяких модификаций регистров, косвенной адресации и т.п.), и её намного проще "положить на конвейер" -- уже первые старшие модели Системы 360, как и наша ЕС-1050, были конвейерными, и, понятно, по производительности рвали любую PDP-11 как тузик грелку. Сделать конвейерную PDPшку или VAX... можно, но значительно сложней (а соответственно, куда больше логики нужно -- и на тогдашнем технологическом уровне это было недостижимо из соображений стоимости и габаритов).
Кроме того, система команд у Системы 360 побогаче будет, а в дальнейшем она всё расширялась и продолжает расширяться -- при этом умудряются не сломать совместимость и поддерживать простоту кодирования (сейчас, например, какое-нибудь там шифрование выполняется одной командой -- и, естественно, обеспечивается намного более высокая производительность, чем у самого навороченного "обычного" процессора, где это надо делать программно). Наличие команд десятичной арифметики, например, резко упрощает жизнь разработчикам экономических приложений -- не надо никаких мер предосторожности, чтоб результаты получались такие же, как при ручных вычислениях (в двоичной возможны нюансы из-за округления; плюс диапазон представимых чисел -- госдолг США, как мы помним, стало возможным хранить лишь в 64-разрядном регистре, ну а в Системе 360 -- запросто, там двоично-десятичные числа лежат в памяти и могут иметь до 31 цифры плюс знак; в PDP-11, кстати, теоретически присутствовал "коммерческий набор команд" -- CIS, но, похоже, встречался крайне редко). Команда TRT (одна из "костыльных" в том плане, что один из операндов является неявным и лежит в строго определённом регистре -- полей для кодирования не хватало) резко упрощает написание программ разбора текста (на ней, грубо говоря, половина лексического анализатора любого ассемблера/компилятора держится). Есть пересылка сразу порции данных (до 256 байтов), а также логические операции над байтовыми полями переменной длины -- соответственно, обнулить память можно куда быстрей, чем чисто программно в цикле (во всяком случае, теоретически: зависит от особенностей реализации; скажем, продвинутая модель, увидев "исключающее или" с одним и тем же стартовым адресом, может просто обнулить эту память, причём, естественно, не побайтово, как предполагается концептуально, а на всю ширину физического доступа в конкретной модели).
Ещё один аспект -- ввод-вывод. У Системы 360 он логически отделён от процессора и свален на каналы, что потенциально, не выходя за рамки архитектуры. позволяет реализовать очень быстрый обмен. У PDPшки всё висит на единственной довольно медленной шине; интенсивный обмен с диском запросто затормозит работу процессора и т.д. (Понятно, что у младших, а отчасти и средних моделей Системы 360 та же проблема -- но она вытекает не из архитектуры, а из реализации; в старших моделях процессор и каналы работают подлинно параллельно и тормоза возникают лишь при одновременном обращении к одному и тому же, выражаясь более современными терминами, банку памяти, -- но там выручает кэш, который у старших моделей появился довольно быстро, хотя у самых первых ещё не было, вроде бы). Поэтому для управляющих применений (где надо постоянно опрашивать битики в регистрах устройств и т.п.) PDPшка или, скажем, современный ARM подходит куда лучше, но вот при обработке больших массивов информации -- наоборот. (Попутно замечу, что великолепнейшая виртуализация машины, реализованная ещё в начале 1970-х в VM/370, так и осталась непревзойдённой по сей день -- если не считать z/VM, конечно, но она -- наследница VM/370 и работает на z/Architecture, выросшей из Системы 360 и сохранившей с ней совместимость на прикладном уровне; во многом она достигнута именно благодаря унифицированному вводу-выводу: гипервизору ничего не нужно знать про работу внешних устройств, если с ними умеет работать гостевая ОС -- он просто преобразует канальные программы в плане физических адресов памяти да передаёт их каналам на выполнение; в той же PDPшке виртуализация... как минимум, проблематична, в IA-32 aka x86 и вовсе невозможна без специальный аппаратной поддержки из-за абсолютнейшей кривизны архитектуры -- Интел, кажется, смогла воплотить все мыслимые и немыслимые архитектурные ошибки...)
Добавьте к этому аппаратный контроль. У PDPшек контролировали разве что чётность оперативной памяти и памяти микропрограмм; у Системы 360 контроль намного более полный, причём во многих более поздних моделях имеются средства восстановления, зачастую позволяющие продолжить работу при случайных сбоях, а уж обнаруживать проблемы вообще в 100% случаев (в младших моделях, особенно ранних, -- в частности, в ЕС-1020, -- он не такой полный, поэтому некоторые сбои будут оставаться "незамеченными", но большинство вещей всё ж контролируется; в частности, АЛУ выполнено в двух экземплярах, и результаты его работы сравниваются -- вот и куда больший объём аппаратуры по сравнению с СМками, ведь тогдашнее АЛУ -- это половина процессора).
Система 360 изначально предполагала возможность построения многопроцессорных систем. Правда, в этой версии архитектуры это было проработано довольно плохо, но опыта-то не было. Когда набрались, многое переделали -- уже в Системе 370, и это сохраняется до сих пор (с некоторыми расширениями).
Насчёт костылей в системе команд Системы 360 не согласен :) Они там есть, конечно, но их, пожалуй, меньше, чем в PDP-11, и существенно меньше, чем у VAX, хотя система команд по функционалу богаче PDPшки. Например, команда XOR в PDPшке -- костыльная по сравнению с остальными, у неё один из операндов обязательно должен лежать в регистре; имеется совершенно дурацкая команда... ээээ... MARK, кажется (вроде б компилятором Фортрана используется, но уж не помню столь интимные подробности); нет логических сдвигов (только арифметические), ещё там что-то было... MMU на многих моделях не позволяет реализовать полноценную виртуальную память (с загрузкой/выгрузкой задач по частям -- поскольку не обеспечивает правильный "откат" при прерывании в процессе выполнения команды), а там, где позволяет (PDP-11/70, например), это делается программными плясками (ОС должна сама выполнить "откат", MMU просто сохраняет нужную для этого информацию в одном из своих регистров) -- ну а в мэйнфреймах, когда виртуальную память сделали (в Системе 370, причём не сразу -- но очень быстро), сразу сделали правильно (принципиально она ничем не отличается от современных архитектур -- те же самые таблицы переадресации в памяти).
ЕСки очень, Очень, ОЧЕНЬ сильно сложнее, чем СМки. Недаром процессор СМки -- один ящик в стойке, а ЕСки -- вся стойка, а у некоторых каналы -- ещё одна стойка.
Останов при срабатывании схем контроля -- это так называемый тяжёлый останов. Отличается от обычного, в частности, тем, что при нём нельзя процессор просто взять и запустить -- он будет стоять, пока не будут сброшены признаки ошибок. Архитектурой сие никак не регламентируется, так как является полностью зависящим от реализации. Ну а обычный останов -- это именно что архитектурное состояние, общее для любых моделей.
Это уже зависящее от реализации поведение. В общем случае процессор уходит в бесконечную цепочку прерываний, выйти из которой можно только сбросом (что тоже регламентируется архитектурой).
ЕС-2020 -- это процессор ЭВМ ЕС-1020, включая память и стойку питания. А процессор без памяти и питания -- ЕС-2420. Отсюда и двусмысленное восприятие фраз, где упоминается тот или иной шифр.
ADD. Поправил заголовок и этой статьи, и прошлой -- с чего-то пропустил ЭВМ. Спасибо, что пнули.
Агат-7 и -8 были несовместимы по графике вообще, насколько помню. Агат-9 вроде б совместим. Но голову на отсечение не дам: я с ним всё ж только в школе и вскоре после школы дело имел.
Скорей всего, знали -- одна из наиболее распространённых архитектур же была, её в ихних вузах преподавали, как и IBMовские оси... Ну а 6502 -- мой первый проц (на "Агате-7") :)
Ну, нельзя сказать, что выбора нет -- есть менторовский Экспедишн.
Кстати говоря, сидел я достаточно долго на нём (ломаном, естественно -- шеф всё собирался минимальную версию взять, да так и не взял). Потом я стал ИПшником и решил озаботиться лицензионным софтом (если возможно, стараюсь покупать; если нет возможности -- спокойно использую пиратское). Сделал платку в КиКАДе и пришёл к выводу: дешевле купить ПАДС Про, который по своей сути -- обрезанный Экспедишн. Купил, пользовался, пока Сименс всех русских пользователей не забанил. Поскольку лицензия действовать перестала (её надо каждый год скачивать с ихнего сайта, хотя право на использование купленной версии само по себе бессрочное) -- ну, я с чистой совестью вернулся на ломаный Экспедишн. С EDM, ага -- мне с ним удобней.
Реально это даже не ускоренный перенос в его классическом виде (как, скажем, для АЛУ SN74181, она же К155ИП3, с выходами генерации и распространения переноса, подаваемыми на схему ускоренного переноса) -- это просто выделенная цепь для распространения обычного последовательного переноса. Просто, поскольку она выделенная, в ней намного меньше мультиплексоров и прочего ПЛИСостроительного железа -- соответственно, задержка распространения переноса по ней много меньше, чем по обычным линиям, связывающим ЛУТы.
Что вопрос для обзора не особо принципиален, согласен. Просто я б написал, что, помимо ЛУТов, в реальных ПЛИС обычно есть дополнительные блоки, без которых можно обойтись (всё можно сделать на одних ЛУТах), но которые упрощают реализацию типичных задач. Как-то так :)
Сумматоры в ПЛИС не встречал -- вот дополнительный элемент "исключающее ИЛИ" вкупе со специальной цепью переноса, что позволяет намного легче строить сумматор, чем чисто на ЛУТах, -- это да (у Хилинха, в частности).
Ну, обычно ж пишут либо не очень грамотные технически люди, либо откровенно ангажированные, вот и превращается заимствование архитектуры (чем занимались в те годы все кому не лень) в слепое копирование всего вообще. Грамотному человеку понятно, что копирования быть не могло именно технически: ЕСки делались на микросхемах-аналогах (вот уж не знаю, точных копиях или созданных "по мотивам" -- в микроэлектронике некомпетентен) изделий Texas Instruments (ТТЛ) и Motorola (ЭСЛ), а IBMовские машины -- сначала на собственных IBMовских микросборках, потом на столь же собственных микросхемах, аналогов которым у нас не было. Так что, хошь не хошь, а реализацию приходилось делать самостоятельно.
Фактологический уровень весьма невысок, скажем так. В частности, первая советская ЭВМ -- не "Стрела", а МЭСМ, и появилась она в 1949 году. За ней последовала БЭСМ -- 1951 год. "Стрела" же стала первой серийной машиной -- их построили аж 7 штук, если память не изменяет.
Советских разработок полно было -- не всегда удачных, естественно, но в общем и целом вполне на уровне. И даже то, что часто (и безграмотно) называют копированием -- СМ ЭВМ и ЕС ЭВМ 1970-80-х годов, например, -- разрабатывалось в общем и целом здесь (заимствовались, главным образом, архитектуры, но не схемная реализация).
Ну, принципиальная разница в том, что в трансформаторном ПЗУ информацию не изменишь, не внеся физических изменений в конструкцию, ну а ферритовое -- именно ОЗУ, а не ПЗУ, просто оно не теряет информацию при отключении питания.
Почитал сообщения в той группе. Честно говоря, контактировать с такими деятелями не хочется: реальной технической информации от них вряд ли дождёшься, а вот вони... Да, я написал, что цифра 8 -- "оборудование связи", и да, я знаю, что во времена СССР писалось про "телеобработку данных". Многие сейчас поймут этот термин без пояснений? А оборудование связи понятно без особых пояснений. ГОСТ существует? Ну да, существует, и каждый, кто сталкивается с нормоконтролем, проклинает и ГОСТы, и нормоконтроль, и работу в госконторах, -- поскольку формализмом душат любую реальную работу. Вон, приятель работает в одном нашем типа НИИ -- разрабатывают электронику. Каждый слой печатной платы подавай им в виде pdf-документа с оформлением по ЕСКД и прочая. Нафига, спрашивается? Кто 16-слойную плату будет делать по бумажным чертежам? Для архива? Ну так для архива можно (и нужно) положить исходные файлы проекта плюс герберы и прочая, а не бесполезные pdf. Про блок питания ЕС-0821 -- я из книги и пишу, могу сканы предъявить, как говорится, никакой отсебятины в этих вопросах нет. (А там, где мои домыслы -- я так и пишу, что это мои домыслы). В общем, формальные придирки вижу, ничего существенно важного не вижу.
Не сомневаюсь, что есть -- я ж пишу по книжкам, собственный опыт весьма небольшой (самый-самый конец СССР) и на более новых машинах, чем описываю. А что за замечания?
Ну почему пристрастный. Я на PDPшках (СМках, точней, -- но не суть) прилично программировал на асме, и, как уже сказал, считаю его лучшим из 16-разрядных. Просто там тоже свои извраты есть, как и везде.
А причём здесь WASM, кстати? Это ж не архитектура проца, чтоб иметь свою систему команд.
От красоты или уродства системы команд, как минимум, зависят сложность её декодирования (IA-32 -- кошмар, Система 360 -- прекрасно, ARM -- где-то посредине) и сложность создания эффективного кодогенератора для компиляторов.
А зачем сейчас столько дисков ставят? Хранение и обработка гигантских объёмов информации, естественно.
Канальные программы -- да, примитивные, но свою задачу (разгрузку ЦП от управления вводом-выводом) вполне себе выполняют.
Про конфликты с памятью вроде сказал уже. Если память разделена на несколько банков, то, пока обращения идут к разным банкам, их легко распараллелить средствами многопортового контроллера памяти; кстати говоря, на СМках с 4 Мбайтами память была двухпортовой: один порт для проца, второй -- для периферии. Просто в Системе 360 проще распараллеливать, поскольку память там является единственной общей точкой -- ну а в более привычных архитектурах процессор напрямую обращается к устройствам и ими управляет, что требует обеспечить соответствующую связь, т.е. делать или общую шину, или огромное количество соединений точка-точка с коммутаторами, -- первое медленно, когда устройств много (некритично для мини-ЭВМ, но недопустимо для мощного мэйнфрейма), второе -- очень сложно и затратно по железу.
Что же касается сравнения с VAXом, то с ним корректней уже будет сравнивать поздние варианты Системы 370, а не ранние Системы 360 -- ведь между ними 10, если не больше, лет разницы. "Общая" система команд у VAX приятней будет, в общем и целом; в отдельных вещах он лучше и в специальных случаях, а Система 370 -- в других (десятичную арифметику, кажется, никто лучше так и не сделал -- одна из причин доминирования мэйнфреймов в финансовом секторе). По вводу-выводу VAX сильно уступает -- как уступает и любая современная архитектура (попробуй подключить к ПК -- именно к ПК, не по локалке, -- тысячи дисков, и чтоб оно ещё и летало, -- ну а к мэйнфрейму z/Architecture -- запросто, если у тебя есть деньги на эти тысячи дисков :) ).
На поздней Системе 370 появился механизм двойного адресного пространства (впоследствии расширен до множества адресных пространств), что резко упрощает и ускоряет реализацию программ-серверов, обслуживающих программы-клиенты. Без этого механизма вызов подпрограммы в сервере надо производить через ядро ОС, с ним -- можно вызывать прямо, при этом привилегии у клиента и сервера разные, но всё контролируется и защищено. У VAX ничего подобного я не видел -- хотя с поздними вариантами не знаком. В IA-32 было "жалкое подобие левой руки" -- таблицы дескрипторов со шлюзами вызова позволяют, теоретически, добиться того же, но всё было спроектировано настолько криво, что этими возможностями никто не пользовался (и AMD выпилила их, делая 64-разрядный вариант архитектуры, -- что впоследствии скопировала Интел, провалившись со своей IA-64 aka Itanium). В общем, в плане системной архитектуры, на мой взгляд, Система 360 и её наследники -- лучшее, что было и есть. По системе команд -- VAX лучше, если не брать частности (которые в него вполне можно было бы добавить, конечно). По простоте реализации -- безусловное превосходство Системы 360 (ну, это неудивительно: в первой половине 1960-х развернуться было особо негде, железо ограничивало -- отсюда, кстати, ряд костылей и неудачных решений, и в первую очередь -- 24-разрядный адрес памяти; просто, похоже, никто не думал, что через 20 лет этого будет мало). По гибкости ввода-вывода -- превосходство VAX, но по пропускной способности -- Системы 360.
В общем, разные архитектуры друг друга не исключают, а дополняют. Ставить Систему 360 в качестве управляющей машины -- верх идиотизма, пытаться заменить один мэйнфрейм тыщей персоналок -- примерно то же самое. Надо исходить из задачи и выбирать адекватные средства.
Ну, система команд PDP-11, как по мне, -- лучшая среди 16-разрядных, а VAX-11 -- среди 32-разрядных, но, как говорится, есть нюансы.
Адресация у DECовских машин более гибкая и эффективная, что, естественно, способствует сокращению объёма программы и потенциально -- повышению производительности. В то же время базовая система команд Системы 360 более проста для реализации (пять чётких форматов команд, не имеющих значимых с точки зрения выборки-декодирования исключений, более простая адресация -- обычная сумма одного-двух регистров и смещения, без всяких модификаций регистров, косвенной адресации и т.п.), и её намного проще "положить на конвейер" -- уже первые старшие модели Системы 360, как и наша ЕС-1050, были конвейерными, и, понятно, по производительности рвали любую PDP-11 как тузик грелку. Сделать конвейерную PDPшку или VAX... можно, но значительно сложней (а соответственно, куда больше логики нужно -- и на тогдашнем технологическом уровне это было недостижимо из соображений стоимости и габаритов).
Кроме того, система команд у Системы 360 побогаче будет, а в дальнейшем она всё расширялась и продолжает расширяться -- при этом умудряются не сломать совместимость и поддерживать простоту кодирования (сейчас, например, какое-нибудь там шифрование выполняется одной командой -- и, естественно, обеспечивается намного более высокая производительность, чем у самого навороченного "обычного" процессора, где это надо делать программно). Наличие команд десятичной арифметики, например, резко упрощает жизнь разработчикам экономических приложений -- не надо никаких мер предосторожности, чтоб результаты получались такие же, как при ручных вычислениях (в двоичной возможны нюансы из-за округления; плюс диапазон представимых чисел -- госдолг США, как мы помним, стало возможным хранить лишь в 64-разрядном регистре, ну а в Системе 360 -- запросто, там двоично-десятичные числа лежат в памяти и могут иметь до 31 цифры плюс знак; в PDP-11, кстати, теоретически присутствовал "коммерческий набор команд" -- CIS, но, похоже, встречался крайне редко). Команда TRT (одна из "костыльных" в том плане, что один из операндов является неявным и лежит в строго определённом регистре -- полей для кодирования не хватало) резко упрощает написание программ разбора текста (на ней, грубо говоря, половина лексического анализатора любого ассемблера/компилятора держится). Есть пересылка сразу порции данных (до 256 байтов), а также логические операции над байтовыми полями переменной длины -- соответственно, обнулить память можно куда быстрей, чем чисто программно в цикле (во всяком случае, теоретически: зависит от особенностей реализации; скажем, продвинутая модель, увидев "исключающее или" с одним и тем же стартовым адресом, может просто обнулить эту память, причём, естественно, не побайтово, как предполагается концептуально, а на всю ширину физического доступа в конкретной модели).
Ещё один аспект -- ввод-вывод. У Системы 360 он логически отделён от процессора и свален на каналы, что потенциально, не выходя за рамки архитектуры. позволяет реализовать очень быстрый обмен. У PDPшки всё висит на единственной довольно медленной шине; интенсивный обмен с диском запросто затормозит работу процессора и т.д. (Понятно, что у младших, а отчасти и средних моделей Системы 360 та же проблема -- но она вытекает не из архитектуры, а из реализации; в старших моделях процессор и каналы работают подлинно параллельно и тормоза возникают лишь при одновременном обращении к одному и тому же, выражаясь более современными терминами, банку памяти, -- но там выручает кэш, который у старших моделей появился довольно быстро, хотя у самых первых ещё не было, вроде бы). Поэтому для управляющих применений (где надо постоянно опрашивать битики в регистрах устройств и т.п.) PDPшка или, скажем, современный ARM подходит куда лучше, но вот при обработке больших массивов информации -- наоборот. (Попутно замечу, что великолепнейшая виртуализация машины, реализованная ещё в начале 1970-х в VM/370, так и осталась непревзойдённой по сей день -- если не считать z/VM, конечно, но она -- наследница VM/370 и работает на z/Architecture, выросшей из Системы 360 и сохранившей с ней совместимость на прикладном уровне; во многом она достигнута именно благодаря унифицированному вводу-выводу: гипервизору ничего не нужно знать про работу внешних устройств, если с ними умеет работать гостевая ОС -- он просто преобразует канальные программы в плане физических адресов памяти да передаёт их каналам на выполнение; в той же PDPшке виртуализация... как минимум, проблематична, в IA-32 aka x86 и вовсе невозможна без специальный аппаратной поддержки из-за абсолютнейшей кривизны архитектуры -- Интел, кажется, смогла воплотить все мыслимые и немыслимые архитектурные ошибки...)
Добавьте к этому аппаратный контроль. У PDPшек контролировали разве что чётность оперативной памяти и памяти микропрограмм; у Системы 360 контроль намного более полный, причём во многих более поздних моделях имеются средства восстановления, зачастую позволяющие продолжить работу при случайных сбоях, а уж обнаруживать проблемы вообще в 100% случаев (в младших моделях, особенно ранних, -- в частности, в ЕС-1020, -- он не такой полный, поэтому некоторые сбои будут оставаться "незамеченными", но большинство вещей всё ж контролируется; в частности, АЛУ выполнено в двух экземплярах, и результаты его работы сравниваются -- вот и куда больший объём аппаратуры по сравнению с СМками, ведь тогдашнее АЛУ -- это половина процессора).
Система 360 изначально предполагала возможность построения многопроцессорных систем. Правда, в этой версии архитектуры это было проработано довольно плохо, но опыта-то не было. Когда набрались, многое переделали -- уже в Системе 370, и это сохраняется до сих пор (с некоторыми расширениями).
Насчёт костылей в системе команд Системы 360 не согласен :) Они там есть, конечно, но их, пожалуй, меньше, чем в PDP-11, и существенно меньше, чем у VAX, хотя система команд по функционалу богаче PDPшки. Например, команда XOR в PDPшке -- костыльная по сравнению с остальными, у неё один из операндов обязательно должен лежать в регистре; имеется совершенно дурацкая команда... ээээ... MARK, кажется (вроде б компилятором Фортрана используется, но уж не помню столь интимные подробности); нет логических сдвигов (только арифметические), ещё там что-то было... MMU на многих моделях не позволяет реализовать полноценную виртуальную память (с загрузкой/выгрузкой задач по частям -- поскольку не обеспечивает правильный "откат" при прерывании в процессе выполнения команды), а там, где позволяет (PDP-11/70, например), это делается программными плясками (ОС должна сама выполнить "откат", MMU просто сохраняет нужную для этого информацию в одном из своих регистров) -- ну а в мэйнфреймах, когда виртуальную память сделали (в Системе 370, причём не сразу -- но очень быстро), сразу сделали правильно (принципиально она ничем не отличается от современных архитектур -- те же самые таблицы переадресации в памяти).
ЕСки очень, Очень, ОЧЕНЬ сильно сложнее, чем СМки. Недаром процессор СМки -- один ящик в стойке, а ЕСки -- вся стойка, а у некоторых каналы -- ещё одна стойка.
Останов при срабатывании схем контроля -- это так называемый тяжёлый останов. Отличается от обычного, в частности, тем, что при нём нельзя процессор просто взять и запустить -- он будет стоять, пока не будут сброшены признаки ошибок. Архитектурой сие никак не регламентируется, так как является полностью зависящим от реализации. Ну а обычный останов -- это именно что архитектурное состояние, общее для любых моделей.
Это уже зависящее от реализации поведение. В общем случае процессор уходит в бесконечную цепочку прерываний, выйти из которой можно только сбросом (что тоже регламентируется архитектурой).
ЕС-2020 -- это процессор ЭВМ ЕС-1020, включая память и стойку питания. А процессор без памяти и питания -- ЕС-2420. Отсюда и двусмысленное восприятие фраз, где упоминается тот или иной шифр.
ADD. Поправил заголовок и этой статьи, и прошлой -- с чего-то пропустил ЭВМ. Спасибо, что пнули.
Агат-7 и -8 были несовместимы по графике вообще, насколько помню. Агат-9 вроде б совместим. Но голову на отсечение не дам: я с ним всё ж только в школе и вскоре после школы дело имел.
Скорей всего, знали -- одна из наиболее распространённых архитектур же была, её в ихних вузах преподавали, как и IBMовские оси... Ну а 6502 -- мой первый проц (на "Агате-7") :)
Ну, нельзя сказать, что выбора нет -- есть менторовский Экспедишн.
Кстати говоря, сидел я достаточно долго на нём (ломаном, естественно -- шеф всё собирался минимальную версию взять, да так и не взял). Потом я стал ИПшником и решил озаботиться лицензионным софтом (если возможно, стараюсь покупать; если нет возможности -- спокойно использую пиратское). Сделал платку в КиКАДе и пришёл к выводу: дешевле купить ПАДС Про, который по своей сути -- обрезанный Экспедишн. Купил, пользовался, пока Сименс всех русских пользователей не забанил. Поскольку лицензия действовать перестала (её надо каждый год скачивать с ихнего сайта, хотя право на использование купленной версии само по себе бессрочное) -- ну, я с чистой совестью вернулся на ломаный Экспедишн. С EDM, ага -- мне с ним удобней.
Реально это даже не ускоренный перенос в его классическом виде (как, скажем, для АЛУ SN74181, она же К155ИП3, с выходами генерации и распространения переноса, подаваемыми на схему ускоренного переноса) -- это просто выделенная цепь для распространения обычного последовательного переноса. Просто, поскольку она выделенная, в ней намного меньше мультиплексоров и прочего ПЛИСостроительного железа -- соответственно, задержка распространения переноса по ней много меньше, чем по обычным линиям, связывающим ЛУТы.
Что вопрос для обзора не особо принципиален, согласен. Просто я б написал, что, помимо ЛУТов, в реальных ПЛИС обычно есть дополнительные блоки, без которых можно обойтись (всё можно сделать на одних ЛУТах), но которые упрощают реализацию типичных задач. Как-то так :)
Сумматоры в ПЛИС не встречал -- вот дополнительный элемент "исключающее ИЛИ" вкупе со специальной цепью переноса, что позволяет намного легче строить сумматор, чем чисто на ЛУТах, -- это да (у Хилинха, в частности).
Ну, обычно ж пишут либо не очень грамотные технически люди, либо откровенно ангажированные, вот и превращается заимствование архитектуры (чем занимались в те годы все кому не лень) в слепое копирование всего вообще. Грамотному человеку понятно, что копирования быть не могло именно технически: ЕСки делались на микросхемах-аналогах (вот уж не знаю, точных копиях или созданных "по мотивам" -- в микроэлектронике некомпетентен) изделий Texas Instruments (ТТЛ) и Motorola (ЭСЛ), а IBMовские машины -- сначала на собственных IBMовских микросборках, потом на столь же собственных микросхемах, аналогов которым у нас не было. Так что, хошь не хошь, а реализацию приходилось делать самостоятельно.
Фактологический уровень весьма невысок, скажем так. В частности, первая советская ЭВМ -- не "Стрела", а МЭСМ, и появилась она в 1949 году. За ней последовала БЭСМ -- 1951 год. "Стрела" же стала первой серийной машиной -- их построили аж 7 штук, если память не изменяет.
Советских разработок полно было -- не всегда удачных, естественно, но в общем и целом вполне на уровне. И даже то, что часто (и безграмотно) называют копированием -- СМ ЭВМ и ЕС ЭВМ 1970-80-х годов, например, -- разрабатывалось в общем и целом здесь (заимствовались, главным образом, архитектуры, но не схемная реализация).
Ну, принципиальная разница в том, что в трансформаторном ПЗУ информацию не изменишь, не внеся физических изменений в конструкцию, ну а ферритовое -- именно ОЗУ, а не ПЗУ, просто оно не теряет информацию при отключении питания.
Почитал сообщения в той группе. Честно говоря, контактировать с такими деятелями не хочется: реальной технической информации от них вряд ли дождёшься, а вот вони... Да, я написал, что цифра 8 -- "оборудование связи", и да, я знаю, что во времена СССР писалось про "телеобработку данных". Многие сейчас поймут этот термин без пояснений? А оборудование связи понятно без особых пояснений. ГОСТ существует? Ну да, существует, и каждый, кто сталкивается с нормоконтролем, проклинает и ГОСТы, и нормоконтроль, и работу в госконторах, -- поскольку формализмом душат любую реальную работу. Вон, приятель работает в одном нашем типа НИИ -- разрабатывают электронику. Каждый слой печатной платы подавай им в виде pdf-документа с оформлением по ЕСКД и прочая. Нафига, спрашивается? Кто 16-слойную плату будет делать по бумажным чертежам? Для архива? Ну так для архива можно (и нужно) положить исходные файлы проекта плюс герберы и прочая, а не бесполезные pdf. Про блок питания ЕС-0821 -- я из книги и пишу, могу сканы предъявить, как говорится, никакой отсебятины в этих вопросах нет. (А там, где мои домыслы -- я так и пишу, что это мои домыслы). В общем, формальные придирки вижу, ничего существенно важного не вижу.
Не сомневаюсь, что есть -- я ж пишу по книжкам, собственный опыт весьма небольшой (самый-самый конец СССР) и на более новых машинах, чем описываю. А что за замечания?
Угу, лента шириной полдюйма (12,7 мм) -- могла записываться на обычных НМЛ. Собсно, однажды для ЕС-1035 я так прикололся :)