Но, что интересно, в документации на ранние модели Системы 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 для дисковых операций всегда возвращает готовность (если не прав -- поправьте, я с Линухом не работаю, поэтому не копался в его вызовах).
А вот using namespace использовать не следует никогда. Ну т.е. вообще никогда. Его использование разрушает саму идею пространств имён -- разделить имена по категориям, так сказать, а не валить всё в огромную кучу. И лучше приучаться всё аккуратно разделять с самого начала, с первых примитивных проектов.
Помнится, играл на СМ-1420. Правда, там управление было двумя кнопками: повернуть вправо и влево (относительно текущего направления движения). Один раз получил в итоге плакат "Кролики кончились" :)
Ну, если надо на современном ПК запустить классическую OS/360 с соответствующим прикладным ПО, то производительность окажется выше топового мэйнфрейма 70-х :) Но, боюсь, современные бизнес-приложения на жабе даже ползти на нём будут медленнее дохлой сороконожки.
В 4.1 и 6.1 -- да, так и есть. Насчёт самых ранних версий ОС/360 не в курсе, так что допускаю, что первый MFT мог бы на 64 Кбайтах работать, но всё равно сомневаюсь: ему подавай же минимум два раздела под задачи (иначе это не MFT, а PCP), и они должны быть разумного размера, чтоб в один влезла хотя б программа системного вывода (14-16 Кбайт, насколько помню), а во вторую -- программа системного ввода (в поздних вариантах она килобайт на 40-50 вроде б тянула, в более ранних, может, и меньше, но вряд ли: основная её работа -- разбирать JCL и писать в очередь заданий, а эти функции принципиально не менялись с самой первой версии системы). Поэтому я и думаю, что 64 Кбайта -- чисто для PCP, но не для MFT.
Ну а если вспомнить, что младший вариант модели 30 вообще имел 8 Кбайт памяти, то будет понятно, что IBM его рассматривала и как машину, работающую вообще без ОС -- что тогда было ещё вполне распространено, хотя потихоньку уже уходило. Ну а мы создавали первые ЕСки на 5 лет позже, так что могли смотреть на американский опыт -- поэтому даже в младшей модели обеспечили до 256 Кбайт.
Я думаю, что всё ж отечественное, иначе трудно объяснить проблемы с качеством первых партий микросхем (если б оборудование было буржуйское, то и техпроцессы и прочая уже были бы отлажены). Но это именно моё мнение, с фактами не знаком.
Но, что интересно, в документации на ранние модели Системы 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 для дисковых операций всегда возвращает готовность (если не прав -- поправьте, я с Линухом не работаю, поэтому не копался в его вызовах).
Именно она, о чём дальше пишу.
А вот using namespace использовать не следует никогда. Ну т.е. вообще никогда. Его использование разрушает саму идею пространств имён -- разделить имена по категориям, так сказать, а не валить всё в огромную кучу. И лучше приучаться всё аккуратно разделять с самого начала, с первых примитивных проектов.
Помнится, играл на СМ-1420. Правда, там управление было двумя кнопками: повернуть вправо и влево (относительно текущего направления движения). Один раз получил в итоге плакат "Кролики кончились" :)
Ну, если надо на современном ПК запустить классическую OS/360 с соответствующим прикладным ПО, то производительность окажется выше топового мэйнфрейма 70-х :) Но, боюсь, современные бизнес-приложения на жабе даже ползти на нём будут медленнее дохлой сороконожки.
В 4.1 и 6.1 -- да, так и есть. Насчёт самых ранних версий ОС/360 не в курсе, так что допускаю, что первый MFT мог бы на 64 Кбайтах работать, но всё равно сомневаюсь: ему подавай же минимум два раздела под задачи (иначе это не MFT, а PCP), и они должны быть разумного размера, чтоб в один влезла хотя б программа системного вывода (14-16 Кбайт, насколько помню), а во вторую -- программа системного ввода (в поздних вариантах она килобайт на 40-50 вроде б тянула, в более ранних, может, и меньше, но вряд ли: основная её работа -- разбирать JCL и писать в очередь заданий, а эти функции принципиально не менялись с самой первой версии системы). Поэтому я и думаю, что 64 Кбайта -- чисто для PCP, но не для MFT.
Ну а если вспомнить, что младший вариант модели 30 вообще имел 8 Кбайт памяти, то будет понятно, что IBM его рассматривала и как машину, работающую вообще без ОС -- что тогда было ещё вполне распространено, хотя потихоньку уже уходило. Ну а мы создавали первые ЕСки на 5 лет позже, так что могли смотреть на американский опыт -- поэтому даже в младшей модели обеспечили до 256 Кбайт.
В PCP -- да, это, собственно, стартёр и есть. В MFT, насколько знаю, всегда минимальными требованиями было 128 Кбайт ОЗУ.
Я думаю, что всё ж отечественное, иначе трудно объяснить проблемы с качеством первых партий микросхем (если б оборудование было буржуйское, то и техпроцессы и прочая уже были бы отлажены). Но это именно моё мнение, с фактами не знаком.