Небольшая поправка: СМ-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 Кбайт.
Я думаю, что всё ж отечественное, иначе трудно объяснить проблемы с качеством первых партий микросхем (если б оборудование было буржуйское, то и техпроцессы и прочая уже были бы отлажены). Но это именно моё мнение, с фактами не знаком.
Тогда обе проблемы стояли. Компоненты (155-ю и ряд других серий) тоже сдирали "в процессе". Просто тогда проблему выпуска худо-бедно, но за несколько лет всё-таки решили, а сейчас перспективы, скажем так, очень туманны...
Ну, полную совместимость на прикладном уровне, в общем-то, обеспечили. Во времена Системы 360 были колебания относительно "генеральной линии" (из-за чего появился ряд не полностью совместимых или вообще не совместимых машин), но затем таки стали относиться к этому строго -- и в результате прикладное ПО середины 60-х может работать и на современных мэйнфреймах.
Насчёт ОС -- согласен. Хотя у IBM было уважительное обстоятельство: похоже, ОС/360 стала вообще первой "большой" ОС в истории, так что не приходится удивляться, сколько там проблем было. А вот лучше VM/370 системы виртуальных машин так и не сделали (z/VM современная -- это её продолжение, так что не считается) -- правда, не столько из-за гениальности разработчиков ОС (там свои припадки имеются), сколько из-за прямизны архитектуры Системы 370 и последующих по сравнению, скажем, с IA-32.
Насчёт CDC 7600 правильно помните :) И тоже архитектурно тупиковая ветка, в конце концов ушедшая в историю, -- хотя, безусловно, очень эффективная числодробилка, и, кажется, первая в истории машина с суперскалярным процессором (кстати, по производительности рвала БЭСМ-6 как тузик грелку, хотя появилась в том же 1967-м). Ну а что не жаловались... Пользователям важен результат, а не то, что у машины внутри :) Но я-то оцениваю в данном случае как "архитектор", а не пользователь.
Со старшими ЕСками -- да, проблема на проблеме. Микроэлектроника не поспевала, так как, похоже, внимания этой теме уделяли совершенно недостаточно и, опять-таки, предпочитали продолжать копировать, что становилось всё сложней и сложней по мере усложнения техпроцессов.
Кто мог, зачастую покупал себе б/у IBMовские мэйнфреймы. Но зачастую особых денег и возможностей не было, а что до энергии... Круглосуточно ж гонять машину не требуется. У нас вот заменили ЕС-1035 на ЕС-1130, которая жрала раз в 5 меньше, а заодно перестали кондиционеры включать летом и отопление зимой -- но машина работала (а персоналки зимой не заводились -- диски примерзали, похоже, без отопления-то :))) ). Ну а пока СССР ещё был жив, ЕС-1035 часто вообще на ночь не отключали -- формально третья смена была, на которой сидел (а точней, спал) дежурный инженер и я: машина в полном распоряжении, что хошь, то и делай :)
Производились, да -- вот только в мизерных количествах (355 штук, как утверждает Вика -- за 20+ лет; сравните с тысячами, а то и десятками тысяч ЕСок; например, ЕС-1060 всего за 5 лет производства -- с 1983 по 1988 г. -- наштамповали 566 штук) и не развивалась -- ибо тупиковой была. ЕСки кое-где работали ещё в 2000-х, ну а сама архитектура, как я уже говорил, жива и развивается до сих пор.
ADD. В принципе, можно рассматривать Эльбрус как развитие БЭСМ-6, но он позиционировался уже чисто как супер-ЭВМ -- т.е. явно не для народнохозяйственного применения (в отличие от ЕСок), периферию тоже ЕСовскую стали цеплять...
А что Вас в Системе 360 не устраивает? Не для холивара, просто интересно знать чужое мнение. Ну а БЭСМ-6 с её 48-разрядным словом -- тупик; её не приспособить под байтовую адресацию, так как для этого нужна кратность машинного слова степени двойки (собственно, поэтому 16-, 32- и 64-разрядные архитектуры всех в итоге и вытеснили). Плюс, её система команд малоэффективна (что послужило одним из аргументов пользу Системы 360), но этот недостаток можно было бы исправить, вероятно (чтоб точно сказать, надо проанализировать внимательно и посмотреть, какие были б варианты), -- если не полностью, то в значительной мере.
Небольшая поправка: СМ-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 Кбайт ОЗУ.
Я думаю, что всё ж отечественное, иначе трудно объяснить проблемы с качеством первых партий микросхем (если б оборудование было буржуйское, то и техпроцессы и прочая уже были бы отлажены). Но это именно моё мнение, с фактами не знаком.
Тогда обе проблемы стояли. Компоненты (155-ю и ряд других серий) тоже сдирали "в процессе". Просто тогда проблему выпуска худо-бедно, но за несколько лет всё-таки решили, а сейчас перспективы, скажем так, очень туманны...
Ну, полную совместимость на прикладном уровне, в общем-то, обеспечили. Во времена Системы 360 были колебания относительно "генеральной линии" (из-за чего появился ряд не полностью совместимых или вообще не совместимых машин), но затем таки стали относиться к этому строго -- и в результате прикладное ПО середины 60-х может работать и на современных мэйнфреймах.
Насчёт ОС -- согласен. Хотя у IBM было уважительное обстоятельство: похоже, ОС/360 стала вообще первой "большой" ОС в истории, так что не приходится удивляться, сколько там проблем было. А вот лучше VM/370 системы виртуальных машин так и не сделали (z/VM современная -- это её продолжение, так что не считается) -- правда, не столько из-за гениальности разработчиков ОС (там свои припадки имеются), сколько из-за прямизны архитектуры Системы 370 и последующих по сравнению, скажем, с IA-32.
Насчёт CDC 7600 правильно помните :) И тоже архитектурно тупиковая ветка, в конце концов ушедшая в историю, -- хотя, безусловно, очень эффективная числодробилка, и, кажется, первая в истории машина с суперскалярным процессором (кстати, по производительности рвала БЭСМ-6 как тузик грелку, хотя появилась в том же 1967-м). Ну а что не жаловались... Пользователям важен результат, а не то, что у машины внутри :) Но я-то оцениваю в данном случае как "архитектор", а не пользователь.
Со старшими ЕСками -- да, проблема на проблеме. Микроэлектроника не поспевала, так как, похоже, внимания этой теме уделяли совершенно недостаточно и, опять-таки, предпочитали продолжать копировать, что становилось всё сложней и сложней по мере усложнения техпроцессов.
Кто мог, зачастую покупал себе б/у IBMовские мэйнфреймы. Но зачастую особых денег и возможностей не было, а что до энергии... Круглосуточно ж гонять машину не требуется. У нас вот заменили ЕС-1035 на ЕС-1130, которая жрала раз в 5 меньше, а заодно перестали кондиционеры включать летом и отопление зимой -- но машина работала (а персоналки зимой не заводились -- диски примерзали, похоже, без отопления-то :))) ). Ну а пока СССР ещё был жив, ЕС-1035 часто вообще на ночь не отключали -- формально третья смена была, на которой сидел (а точней, спал) дежурный инженер и я: машина в полном распоряжении, что хошь, то и делай :)
Производились, да -- вот только в мизерных количествах (355 штук, как утверждает Вика -- за 20+ лет; сравните с тысячами, а то и десятками тысяч ЕСок; например, ЕС-1060 всего за 5 лет производства -- с 1983 по 1988 г. -- наштамповали 566 штук) и не развивалась -- ибо тупиковой была. ЕСки кое-где работали ещё в 2000-х, ну а сама архитектура, как я уже говорил, жива и развивается до сих пор.
ADD. В принципе, можно рассматривать Эльбрус как развитие БЭСМ-6, но он позиционировался уже чисто как супер-ЭВМ -- т.е. явно не для народнохозяйственного применения (в отличие от ЕСок), периферию тоже ЕСовскую стали цеплять...
А что Вас в Системе 360 не устраивает? Не для холивара, просто интересно знать чужое мнение. Ну а БЭСМ-6 с её 48-разрядным словом -- тупик; её не приспособить под байтовую адресацию, так как для этого нужна кратность машинного слова степени двойки (собственно, поэтому 16-, 32- и 64-разрядные архитектуры всех в итоге и вытеснили). Плюс, её система команд малоэффективна (что послужило одним из аргументов пользу Системы 360), но этот недостаток можно было бы исправить, вероятно (чтоб точно сказать, надо проанализировать внимательно и посмотреть, какие были б варианты), -- если не полностью, то в значительной мере.