ЕС-1036, насколько знаю, -- несколько осовремененная ЕС-1035; основное техническое отличие -- прикрутили кэш-память, что позволило поднять производительность.
Ну а как именно работали средства взаимодействия машины с СВМ, сказать могут только разработчики, надо полагать: это не документировалось в тех руководствах, что попадали простым эксплуатантам. Более того, даже обычное расширение системы команд (Система 370 на месте ж не стояла, ну и мы "догоняли", но не "перегоняли") не документировалось; скажем, пришла к нам ЕС-1130, у которой был ряд новых команд, в частности, TPROT -- а информации нуль. Логику некоторых из них я по микропрограммам и схемам восстанавливал, тырнетов же не было, чтоб просто скачать IBMовскую документацию.
Ферритовое -- оно, вообще-то, ОЗУ :) Хотя можно и чистое ПЗУ сделать, но устройство у него будет другим. Ну а вся поддержка имелась прямо в осях, а не на "дискетах". Кстати говоря, благодаря особенностям системы ввода-вывода мэйнфреймов, можно было подключить неизвестное для ОС устройство и нормально с ним работать из прикладной программы -- есно, это была задача не для рядового прикладного программиста, но технически решалась без проблем.
Для СВМ ЕС, она же VM/370, машина могла предоставлять средства поддержки, ускорявшие некоторые аспекты виртуализации. Что-то было, например, уже в ЕС-1035, но доступная мне версия СВМ (более поздняя) этим пользоваться не умела. Технически могли и специализированные версии микропрограмм выпускать для тех машин, где микропрограммная память загружаемая. Но виртуализация работала и без какой-либо поддержки -- просто некоторые вещи выполнялись медленнее (это на IA-32 aka x86 без специальной железной поддержки виртуализация вообще невозможна -- из-за жуткой кривизны архитектуры).
У вояк много что древнего есть. Я вот был несколько лет назад сильно удивлён, что американцы сняли с производства ферритовую память вот считай только сейчас -- эти самые несколько лет назад. Где она могла ещё использоваться-то? Ну а микросхемы 1960-х они производят до сих пор -- достаточно, например, посмотреть на сайте TI информацию по классической рассыпухе серии SN74. В общем, в том, что древняя техника кое-где дожила до наших дней и работает, ничего особо удивительного нет.
А упоминаемый в той же статье контроллер дисков 2841 -- это прообраз нашего ЕС-5551. Но был ли наш содран, или мы лишь подглядывали за буржуями, но делали его в общем и целом сами, -- без понятия, и без документации не скажешь.
Но, что интересно, в документации на ранние модели Системы 360 говорится уже про конденсаторную память. Может, в разных моделях использовали разную?..
О, увидел в этом посте: "The TROS module I have was used on the low-end System/360 Model 20 computer..." -- т.е. речь у него о модели 20, на которую я вообще не смотрел -- это "недосистема 360", сия модель несовместима с настоящими машинами Системы 360, поэтому я и не пытался вникать в документацию на неё.
Первой ЕСкой с загружаемыми микропрограммами была ЕС-1035, а это конец 1970-х. В ЕС-1045 часть микропрограммной памяти была загружаемой, часть -- постоянной, но с этой машиной я, можно считать, не работал. Ну а про ЕС-1046 только слышал.
Именно исключением повторов компиляции при мелких ошибках и объяснялась сия фича; кроме того, она не была "безмолвной": компилятор уведомлял о проблеме в любом случае. Но толком её развить не успели, так как стали доступны терминалы, что позволило резко ускорить разработку (не надо было утром сдавать колоду перфокарт, а вечером приходить за распечаткой).
Честно? Без понятия :) Я не застал столь старые машины и имел дело уже только с ПЗУ на микросхемах. Правда, подозреваю, что древние контроллеры дисков ЕС-5551, доставшиеся "по наследству" нашим ЕС-1035 от ЕС-1022 вместе с 16 дисководами ЕС-5052 и ЕС-5056 (сами старые машины отправили в утиль ещё до моего прихода, а вот периферию оставили), были тоже микропрограммными, но внутрь их я никогда не лазил: за те лет 5, что они работали в моём присутствии, ни одной поломки не было, а соответственно, открывать их стойки не было нужды (работает -- не трожь!).
Вроде как он -- первая попытка создать универсальный язык программирования на все случаи жизни, до этого были лишь более-менее специализированные -- скажем, Фортран и Алгол для научных задач и Кобол -- для экономических.
Надо отсканировать как-нибудь свои запасы бумажных документов... В частности, есть все тома по ПЛ/1 для ОС ЕС. Практической пользы 0, но исторический интерес представляют.
Небольшая поправка: СМ-3 могла адресовать 64 Кбайта памяти -- шина адреса ж 16-разрядная. Просто старшие 8 Кбайт адресного пространства отведены под регистры внешних устройств, поэтому доступный объём ОЗУ ограничен 56 Кбайтами. Точно так же, на СМ-4 адресное пространство 256 Кбайт, но ОЗУ -- до 248 Кбайт.
В те годы трансформаторы были дешевле диодов -- особенно учитывая, что характеристики у них были никакие (им не требовалось передавать, скажем, большой ток) и они штамповались автоматом. Ну и меньше было надо, да -- в данном случае в 128 раз.
ЕС-1061 -- это уже 1980-е годы, ферритовая память уже ушла. Как конкретно там реализовано, я не знаю -- с ними дела не имел и даже не видел. Но уже у ЕС-1035 (конец 1970-х) управляющая (микропрограммная, грубо говоря) память -- мало того, что полупроводниковая, но ещё и на ОЗУ.
Если кратко -- нельзя, нужна та или иная изоляция выходов дешифратора друг от друга, чтоб на вход регистра данных (регистра микрокоманды, в данном случае) поступал сигнал, соответствующий лишь одной линии дешифратора. Можно сделать ПЗУ на, скажем, диодах и перемычках -- только в те годы оно стоило бы многократно дороже трансформаторной (или конденсаторной, как у IBM) конструкции.
Зависит от того, как писать. Он, конечно, сложней для восприятия, чем чисто линейный синхронный код, -- но значительно эффективней почти во всех случаях, кроме хелловорлда (если его грамотно использовать, конечно).
Спасибо за наводку, почитаю на досуге. Помню, в своё время (конец 1980-х или самое начало 1990-х -- ещё при Союзе, в общем) дико плевался, поглядев на API Unix (какого-то из советских клонов) -- как раз из-за отсутствия асинхронщины. Производительность её, кстати, была ниже плинтуса по сравнению с RSX-11, когда дело доходило до интенсивных вызовов API, а памяти она жрала под себя выше крыши :) Обе системы гоняли на СМ-1420 -- написали тестовый набор программ, которые интенсивно взаимодействовали друг с другом, используя ОС, -- очевидно, что обычная расчётная задача, работающая "внутри себя", от эффективности ОС вообще никак не зависит, и хотелось проверить именно качества системы. Правда, что творилось в тесте для Unix, я не знаю, -- делал не я, моё дело было писать под RSX-11 (точней, под её советский клон -- ОС-РВ).
Но, в любом случае, отсутствие поддержки стандартных средств (POSIX в полном объёме), конечно, удручает...
Реальным решением является асинхронный ввод-вывод (поток запускает операцию, а по её завершении ОС устанавливает некое событие, которое может быть проверено потоком, и/или дёргает процедуру обратного вызова). Однако он не везде есть (стандартом POSIX предусмотрен -- но как необязательный; вот Винде всю жизнь был и есть, поскольку унаследован от VAX/VMS, а той -- от RSX-11). Неблокирующий ввод-вывод асинхронным в этом смысле не является: он не оповещает о моменте завершения операции, он лишь говорит о готовности начать новую операцию. Кроме того, где-то встречал, что, по крайней мере, линуховый poll для дисковых операций всегда возвращает готовность (если не прав -- поправьте, я с Линухом не работаю, поэтому не копался в его вызовах).
Угу, лента шириной полдюйма (12,7 мм) -- могла записываться на обычных НМЛ. Собсно, однажды для ЕС-1035 я так прикололся :)
ЕС-1036, насколько знаю, -- несколько осовремененная ЕС-1035; основное техническое отличие -- прикрутили кэш-память, что позволило поднять производительность.
Ну а как именно работали средства взаимодействия машины с СВМ, сказать могут только разработчики, надо полагать: это не документировалось в тех руководствах, что попадали простым эксплуатантам. Более того, даже обычное расширение системы команд (Система 370 на месте ж не стояла, ну и мы "догоняли", но не "перегоняли") не документировалось; скажем, пришла к нам ЕС-1130, у которой был ряд новых команд, в частности, TPROT -- а информации нуль. Логику некоторых из них я по микропрограммам и схемам восстанавливал, тырнетов же не было, чтоб просто скачать IBMовскую документацию.
Ферритовое -- оно, вообще-то, ОЗУ :) Хотя можно и чистое ПЗУ сделать, но устройство у него будет другим. Ну а вся поддержка имелась прямо в осях, а не на "дискетах". Кстати говоря, благодаря особенностям системы ввода-вывода мэйнфреймов, можно было подключить неизвестное для ОС устройство и нормально с ним работать из прикладной программы -- есно, это была задача не для рядового прикладного программиста, но технически решалась без проблем.
Для СВМ ЕС, она же VM/370, машина могла предоставлять средства поддержки, ускорявшие некоторые аспекты виртуализации. Что-то было, например, уже в ЕС-1035, но доступная мне версия СВМ (более поздняя) этим пользоваться не умела. Технически могли и специализированные версии микропрограмм выпускать для тех машин, где микропрограммная память загружаемая. Но виртуализация работала и без какой-либо поддержки -- просто некоторые вещи выполнялись медленнее (это на IA-32 aka x86 без специальной железной поддержки виртуализация вообще невозможна -- из-за жуткой кривизны архитектуры).
У вояк много что древнего есть. Я вот был несколько лет назад сильно удивлён, что американцы сняли с производства ферритовую память вот считай только сейчас -- эти самые несколько лет назад. Где она могла ещё использоваться-то? Ну а микросхемы 1960-х они производят до сих пор -- достаточно, например, посмотреть на сайте TI информацию по классической рассыпухе серии SN74. В общем, в том, что древняя техника кое-где дожила до наших дней и работает, ничего особо удивительного нет.
А упоминаемый в той же статье контроллер дисков 2841 -- это прообраз нашего ЕС-5551. Но был ли наш содран, или мы лишь подглядывали за буржуями, но делали его в общем и целом сами, -- без понятия, и без документации не скажешь.
Но, что интересно, в документации на ранние модели Системы 360 говорится уже про конденсаторную память. Может, в разных моделях использовали разную?..
О, увидел в этом посте: "The TROS module I have was used on the low-end System/360 Model 20 computer..." -- т.е. речь у него о модели 20, на которую я вообще не смотрел -- это "недосистема 360", сия модель несовместима с настоящими машинами Системы 360, поэтому я и не пытался вникать в документацию на неё.
Первой ЕСкой с загружаемыми микропрограммами была ЕС-1035, а это конец 1970-х. В ЕС-1045 часть микропрограммной памяти была загружаемой, часть -- постоянной, но с этой машиной я, можно считать, не работал. Ну а про ЕС-1046 только слышал.
Именно исключением повторов компиляции при мелких ошибках и объяснялась сия фича; кроме того, она не была "безмолвной": компилятор уведомлял о проблеме в любом случае. Но толком её развить не успели, так как стали доступны терминалы, что позволило резко ускорить разработку (не надо было утром сдавать колоду перфокарт, а вечером приходить за распечаткой).
Честно? Без понятия :) Я не застал столь старые машины и имел дело уже только с ПЗУ на микросхемах. Правда, подозреваю, что древние контроллеры дисков ЕС-5551, доставшиеся "по наследству" нашим ЕС-1035 от ЕС-1022 вместе с 16 дисководами ЕС-5052 и ЕС-5056 (сами старые машины отправили в утиль ещё до моего прихода, а вот периферию оставили), были тоже микропрограммными, но внутрь их я никогда не лазил: за те лет 5, что они работали в моём присутствии, ни одной поломки не было, а соответственно, открывать их стойки не было нужды (работает -- не трожь!).
Вроде как он -- первая попытка создать универсальный язык программирования на все случаи жизни, до этого были лишь более-менее специализированные -- скажем, Фортран и Алгол для научных задач и Кобол -- для экономических.
Надо отсканировать как-нибудь свои запасы бумажных документов... В частности, есть все тома по ПЛ/1 для ОС ЕС. Практической пользы 0, но исторический интерес представляют.
Небольшая поправка: СМ-3 могла адресовать 64 Кбайта памяти -- шина адреса ж 16-разрядная. Просто старшие 8 Кбайт адресного пространства отведены под регистры внешних устройств, поэтому доступный объём ОЗУ ограничен 56 Кбайтами. Точно так же, на СМ-4 адресное пространство 256 Кбайт, но ОЗУ -- до 248 Кбайт.
В те годы трансформаторы были дешевле диодов -- особенно учитывая, что характеристики у них были никакие (им не требовалось передавать, скажем, большой ток) и они штамповались автоматом. Ну и меньше было надо, да -- в данном случае в 128 раз.
ЕС-1061 -- это уже 1980-е годы, ферритовая память уже ушла. Как конкретно там реализовано, я не знаю -- с ними дела не имел и даже не видел. Но уже у ЕС-1035 (конец 1970-х) управляющая (микропрограммная, грубо говоря) память -- мало того, что полупроводниковая, но ещё и на ОЗУ.
Если кратко -- нельзя, нужна та или иная изоляция выходов дешифратора друг от друга, чтоб на вход регистра данных (регистра микрокоманды, в данном случае) поступал сигнал, соответствующий лишь одной линии дешифратора. Можно сделать ПЗУ на, скажем, диодах и перемычках -- только в те годы оно стоило бы многократно дороже трансформаторной (или конденсаторной, как у IBM) конструкции.
Ну, я пишу потихоньку про тогдашнее железо -- окучиваю, так сказать, свои запасы литературы. Можно и по древним осям что-нибудь написать.
Зависит от того, как писать. Он, конечно, сложней для восприятия, чем чисто линейный синхронный код, -- но значительно эффективней почти во всех случаях, кроме хелловорлда (если его грамотно использовать, конечно).
Спасибо за наводку, почитаю на досуге. Помню, в своё время (конец 1980-х или самое начало 1990-х -- ещё при Союзе, в общем) дико плевался, поглядев на API Unix (какого-то из советских клонов) -- как раз из-за отсутствия асинхронщины. Производительность её, кстати, была ниже плинтуса по сравнению с RSX-11, когда дело доходило до интенсивных вызовов API, а памяти она жрала под себя выше крыши :) Обе системы гоняли на СМ-1420 -- написали тестовый набор программ, которые интенсивно взаимодействовали друг с другом, используя ОС, -- очевидно, что обычная расчётная задача, работающая "внутри себя", от эффективности ОС вообще никак не зависит, и хотелось проверить именно качества системы. Правда, что творилось в тесте для Unix, я не знаю, -- делал не я, моё дело было писать под RSX-11 (точней, под её советский клон -- ОС-РВ).
Но, в любом случае, отсутствие поддержки стандартных средств (POSIX в полном объёме), конечно, удручает...
Реальным решением является асинхронный ввод-вывод (поток запускает операцию, а по её завершении ОС устанавливает некое событие, которое может быть проверено потоком, и/или дёргает процедуру обратного вызова). Однако он не везде есть (стандартом POSIX предусмотрен -- но как необязательный; вот Винде всю жизнь был и есть, поскольку унаследован от VAX/VMS, а той -- от RSX-11). Неблокирующий ввод-вывод асинхронным в этом смысле не является: он не оповещает о моменте завершения операции, он лишь говорит о готовности начать новую операцию. Кроме того, где-то встречал, что, по крайней мере, линуховый poll для дисковых операций всегда возвращает готовность (если не прав -- поправьте, я с Линухом не работаю, поэтому не копался в его вызовах).
Именно она, о чём дальше пишу.