Ну, по сравнению с оригинальной IBMовской техникой, -- да, формально устаревшее, с отставанием лет на 5 (к концу СССР, правда, отставание стало нарастать), но машины тогда каждый год, как айфоны, не меняли -- служили и по 10 лет, и по 15 что у нас, что у них, так что критического в этом ничего не было. По сравнению с полностью отечественными разработками -- большой шаг вперёд; у нас из архитектурного хаоса 1 и 2 поколений так и не выбрались самостоятельно. Нет, в конечном итоге, пришли бы к тому же -- к необходимости иметь небольшое количество архитектур и разрабатывать совместимые машины (собственно, уже пришли -- по крайней мере, в серии "Минск"; просто сами архитектуры оставались ещё примитивными и малоэффективными, что было общим для техники 1-2 поколения во всех странах), но потратили бы куда больше времени, делая всё (в первую очередь, системное и околосистемное ПО) с нуля. В общем, лично моё мнение -- правильно, что скопировали весьма неплохую архитектуру, это позволило нам совершить быстрый рывок; основные ошибки начались позже -- когда разработку "по мотивам" стали заменять тупым копированием всего подряд, что вкупе с неэффективным расходованием и так не очень больших ресурсов и привело к ещё большему отставанию. Но это уже не техника, а политика и экономика...
Ну почему заменяли... Были на ЕСках и принтеры, и мониторы с клавиатурами. Но в качестве консольного терминала пишмашка часто была удобнее: протокол сохранялся. А что она печатала максимум 10 символов в секунду, то какая нужда-то для консоли печатать быстро? (Ну а принтеры в зависимости от модели -- от 500 до 1200 строк по 128-132 символа в минуту; из-за высокой скорости и низких эксплуатационных расходов их потом к ПК присобачивали).
Ага, в обычной официальной документации вроде б не упоминается, но без проблем отыскивается в системной макробиблиотеке. Правда, её использование, в принципе, можно запретить беспарольным заданиям, но обычно с этим не заморачивались.
Если кратко -- делая что-то, надо включать мозги и смотреть, какие правила, рекомендации и т.п. полезны для данного случая, а какие -- вредны, а не следовать им, "потому что так правильно". Скажем, был у меня коллега, который прошивку одного промышленного прибора на микроконтроллере (какой-то из младших STM32) писал примерно как положено по чистому коду: с классами, виртуальными функциями и прочим -- в общем, как уместно было бы, скажем, в игровом движке, где заранее невозможно предсказать, какие расширения "каркаса" потребуются при создании множества продуктов на его основе разными людьми и, вероятно, на протяжении очень длительного времени. Но здесь-то -- не игровой движок, а прошивка промышленной железяки под вполне определённую задачу, которую один раз написал и, скорей всего, больше к ней возвращаться не будешь -- работает и работает, что-то измеряет, какие-то циферки показывает, что-то куда-то передаёт по вполне определённым интерфейсам...
Ну а что здесь удивительного? Процессор формировал канальные программы и запускал их, всё остальное делалось без его участия: контроллер дисков сам управлял накопителями, позиционируя головки и затем записывая разметку на дорожки. Естественно, время от времени процессор и канал конфликтовали при доступе к ОП, что слегка подтормаживало работу процессора, но не более того.
Да, было такое -- экономили место, но не в кодовых таблицах (пустого места в EBCDIC было предостаточно), а на барабанах принтеров, в первую очередь. Из-за этого сортировка в ОС ЕС была доработана: при запуске можно было указать, сортировать по-русски или по-английски.
Ну, для чего АСВТ нужна была, понятно. Непонятно, почему в её рамках разрабатывали машину верхнего уровня в виде той же самой ЕСки, вид сбоку -- вместо того, чтоб делать всё ИБМ-совместимое в рамках одного проекта, PDP-совместимое -- в другом, HP-совместимое -- в третьем (а два последних в итоге смешали в одну кучу). Ничто ведь не мешало использовать ЕСки вместе с машинами из АСВТ и СМками -- как, собственно, и бывало на практике; да и в качестве управляющих в строгом смысле слова они никогда не годились -- слишком большие, дорогие, сложные и недостаточно надёжные. Обработка экономической информации, всякая там статистика и т.д. -- да, это их область, но не прямое управление оборудованием или участие в техпроцессах.
Ну а централизация как позволяла эффективней использовать ресурсы, не распыляя их -- но на практике получилось, что у нас ни конкуренции нормальной не было, как у капиталистов, ни эффективного использования возможностей централизации.
80 символов в строке у Кобола -- это не ограничение бумажного бланка, это ограничение перфокарты. Но, честно говоря, удивлён таким использованием сего языка. Вот экономические задачи, решаемые в пакетном режиме, на нём было писать весьма приятно.
Во-первых, есть любители истории вычислительной техники -- в первую очередь расчёт на них. Во-вторых, в технологиях 50-летней давности тоже встречаются интересные решения, особенно с учётом того, что решать приходилось сложные задачи, а ресурсы были куда более ограниченными, чем сейчас (грубо говоря, чтоб заставить мигать лампочку, нужно было делать мультивибратор на двух транзисторах, а не ставить какую-нибудь Raspberry Pi с несколькими 64-битными ядрами и десятками миллионов транзисторов).
Вычислять квадратный корень может потребоваться и на процессоре, не имеющем не только его аппаратной реализации, но и вообще какой-либо поддержки операций с плавающей запятой -- скажем, на любом микроконтроллере с ядром Cortex-M3 или вообще на Ардуине. И вот там подобная магия может дать многократный прирост (особенно если писать на ассемблере). В общем, если нечто становится не особо актуальным для ПК, может быть вполне себе актуальным для других платформ.
OS/360 -- не первая ОС для мэйнфреймов IBM; DOS/360 и ещё пара систем были разработаны раньше. Вот первой "большой" ОС, и не только для мэйнфреймов IBM, а вообще в истории, она, пожалуй, является. Не является она и "монолитным блоком программного кода", она состоит от огромного числа модулей, загружаемых по мере необходимости. Именно это дало возможность системе объёмом в несколько сотен килобайт работать на машинах с заметно меньшим объёмом памяти -- причём ещё до появления MMU, то есть без виртуальной памяти. У ядра была фиксированная часть, всегда находившаяся в основной памяти, и были модули, которые по мере необходимости загружались в транзитные области. Пользователи системы могли для неё писать свои модули, если возникала такая необходимость.
Не, z/Architecture -- это именно что продолжение Системы 360 -- через Систему 370, 370-XA, ESA/370 и ESA/390. Каждое новое поколение добавляло новые фишки, но полная программная совместимость прикладного кода сохранялась (вот совместимость на системном уровне была утрачена при переходе от 370 к 370-XA -- и IBM как раз поступила очень разумно, не потащив кучу старья и дальше, и предпочтя просто модифицировать код ОС -- ведь на прикладных программах изменения никак не сказались, как впрочем, и на 95% системного кода). Сейчас там, конечно, больше тыщи команд (против 144 изначально), но, в общем-то, они вполне в мозги лезут -- потому что вполне логичны, по большей части. Я, конечно, наизусть не скажу команды, скажем, векторной обработки, -- я для современных мэйнфреймов я и не писал, но их относительно немного, это не бесконечные MMX, SSE и прочие AVX, так что, если бы я их использовал постоянно, я б запомнил без проблем (ну а если б использовал изредка -- без проблем находил бы нужные команды в руководстве по архитектуре, оно не особо объёмное).
Что касается разброда и шатаний в рамках Системы 360 -- это я в курсе, естественно. Но, прямо скажем, это неудивительно: хотя сама архитектура была эпохальной, появилась-то она в переходный период (собственно, во многом его и определив), вот и страдали экспериментами. А вот какого лешего, например, чехи сделали ублюдочную ЕС-1021, этого и они сами, надо полагать, не поняли: вроде и Система 360, а на системном уровне совместимости нет, половины команд прикладного уровня тоже нет... И ведь это уже начало 1970-х было -- казалось бы, можно учесть чужой (IBMовский) опыт и не бегать по граблям...
Насчёт системы команд IA-32. Я в данном случае говорю не про вместимость черепной коробки, а про гадостность именно системы команд на базовом уровне. Например, "MOV EAX, константа" может кодироваться несколькими разными способами (а в 64-разрядной, кажется, только в RAX можно загрузить 64-разрядную константу, в остальные регистры -- фигвам); строковые операции обязательно используют ESI, EDI и ECX, использование в качестве базовых одних регистров влечёт к обращению через один сегментный регистр, а других -- через другой (и не всегда это можно подменить префиксами), длина команды не может быть определена простыми средствами и т.д. и т.п.; для деления в 8086 использовались строго определённые регистры и регистровые пары -- не помню, исправили это в 80386 или уже позже... И вся эта дурь тянется для совместимости и дальше. Причём, замечу, если некоторые косяки системы команд Системы 360 простительны -- она формировалась в первой половине 1960-х, в условиях ещё полнейшего архитектурного хаоса, то идиотизм архитекторов Интел просто поражает: они собрали практически все возможные глупые решения, но делали это уже в середине 1970-х! Более того, переходя, уже в 1980-х, на 32-разрядную систему команд, они поступили не как DEC, у которой VAX-11 "идеологически" подобен PDP-11, но на уровне кодирования команд и прочего не имеет никакой совместимости для обеспечения эффективности реализации, -- они решили тянуть прямую совместимость с откровенно уродской системой команд 8086 (сравните её, скажем, с 68000 и Z8000 -- все три этих микропроцессора являются современниками), а не оставить её чисто для 16-разрядного режима, в 32-разрядном переключаясь на новую, эффективно закодированную систему команд (VAX-11 могла выполнять прикладные программы PDP-11 именно таким путём).
Восьмеричная система, кстати, никак не напрягает, это вопрос привычки; для PDP-11 она была естественней: восемь регистров, восемь режимов адресации... Я легко прыгал с одной на другую в зависимости от того, приходилось ли иметь дело с СМкой или ЕСкой.
Насчёт терминалов. А Вы гляньте, когда появился VT100 и на чём он был сделан. IBM делала технику много раньше, на другом технологическом уровне, и для того времени всё было очень даже круто (хотя временами переусложнено -- тут соглашусь). Редактировать там, кстати, можно было не строку, а весь экран. Ну а что до ЖабаСкрипта... Он появился, по историческим меркам, вчера -- а не в эпоху мамонтов :) Вот игры -- да, бяда-бяда, но в IBM сидели скучные дяди, ориентированные исключительно на бизнес-задачи :) (Кстати, в змейке на СМке для меня всё один раз закончилось надписью "кролики кончились" :) ).
Это понятно; я к тому, что, если б у машины что-то не в порядке было с напряжением питания подложек, то микросхемы должны были бы гореть оптом, а не по штуке в месяц. Думаю, это просто ранняя серия микросхем была, ещё недостаточно надёжная (возможно, потому "золотая", типа военная, машина попала на гражданское предприятие -- подозреваю, что вояки в те годы ещё предпочитали нормально работающую ферритовую память). Но ремонтировал не я, я де-факто системщиком был и просто ковырялся в железе ради собственного удовольствия, поэтому не знаю, выходили ли из строя повторно уже заменённые микросхемы, или же дохли только те, что были установлены на заводе (микросхемы из ЗИПа были относительно новые -- примерно 1985 года выпуска или даже несколько позже; сама история имела место в конце 80-начале 90-х).
Для уровня технологий СССР -- да, но не для уровня технологий IBM, от которой мы отставали лет на 10. Поэтому если сравнивать 486, то с современной ему продукцией именно IBM.
Ну, по сравнению с оригинальной IBMовской техникой, -- да, формально устаревшее, с отставанием лет на 5 (к концу СССР, правда, отставание стало нарастать), но машины тогда каждый год, как айфоны, не меняли -- служили и по 10 лет, и по 15 что у нас, что у них, так что критического в этом ничего не было. По сравнению с полностью отечественными разработками -- большой шаг вперёд; у нас из архитектурного хаоса 1 и 2 поколений так и не выбрались самостоятельно. Нет, в конечном итоге, пришли бы к тому же -- к необходимости иметь небольшое количество архитектур и разрабатывать совместимые машины (собственно, уже пришли -- по крайней мере, в серии "Минск"; просто сами архитектуры оставались ещё примитивными и малоэффективными, что было общим для техники 1-2 поколения во всех странах), но потратили бы куда больше времени, делая всё (в первую очередь, системное и околосистемное ПО) с нуля. В общем, лично моё мнение -- правильно, что скопировали весьма неплохую архитектуру, это позволило нам совершить быстрый рывок; основные ошибки начались позже -- когда разработку "по мотивам" стали заменять тупым копированием всего подряд, что вкупе с неэффективным расходованием и так не очень больших ресурсов и привело к ещё большему отставанию. Но это уже не техника, а политика и экономика...
Ну почему заменяли... Были на ЕСках и принтеры, и мониторы с клавиатурами. Но в качестве консольного терминала пишмашка часто была удобнее: протокол сохранялся. А что она печатала максимум 10 символов в секунду, то какая нужда-то для консоли печатать быстро? (Ну а принтеры в зависимости от модели -- от 500 до 1200 строк по 128-132 символа в минуту; из-за высокой скорости и низких эксплуатационных расходов их потом к ПК присобачивали).
А что, есть полные исходники MVT?
Ага, в обычной официальной документации вроде б не упоминается, но без проблем отыскивается в системной макробиблиотеке. Правда, её использование, в принципе, можно запретить беспарольным заданиям, но обычно с этим не заморачивались.
Вот это -- запросто :) И, кстати, не везде микропрограммная. Например, у ЕС-1050 чисто схемное управление что процессором, что каналами.
Если кратко -- делая что-то, надо включать мозги и смотреть, какие правила, рекомендации и т.п. полезны для данного случая, а какие -- вредны, а не следовать им, "потому что так правильно". Скажем, был у меня коллега, который прошивку одного промышленного прибора на микроконтроллере (какой-то из младших STM32) писал примерно как положено по чистому коду: с классами, виртуальными функциями и прочим -- в общем, как уместно было бы, скажем, в игровом движке, где заранее невозможно предсказать, какие расширения "каркаса" потребуются при создании множества продуктов на его основе разными людьми и, вероятно, на протяжении очень длительного времени. Но здесь-то -- не игровой движок, а прошивка промышленной железяки под вполне определённую задачу, которую один раз написал и, скорей всего, больше к ней возвращаться не будешь -- работает и работает, что-то измеряет, какие-то циферки показывает, что-то куда-то передаёт по вполне определённым интерфейсам...
Ну а что здесь удивительного? Процессор формировал канальные программы и запускал их, всё остальное делалось без его участия: контроллер дисков сам управлял накопителями, позиционируя головки и затем записывая разметку на дорожки. Естественно, время от времени процессор и канал конфликтовали при доступе к ОП, что слегка подтормаживало работу процессора, но не более того.
Угу. Но диапазон значений байтов, которые можно было передать машине, был ограничен, поэтому вряд ли бы удалось практически.
Бывали, да. Правда, я с ними не сталкивался и даже не видел, так что про практическое использование ничего не скажу.
Да, было такое -- экономили место, но не в кодовых таблицах (пустого места в EBCDIC было предостаточно), а на барабанах принтеров, в первую очередь. Из-за этого сортировка в ОС ЕС была доработана: при запуске можно было указать, сортировать по-русски или по-английски.
Ну, для чего АСВТ нужна была, понятно. Непонятно, почему в её рамках разрабатывали машину верхнего уровня в виде той же самой ЕСки, вид сбоку -- вместо того, чтоб делать всё ИБМ-совместимое в рамках одного проекта, PDP-совместимое -- в другом, HP-совместимое -- в третьем (а два последних в итоге смешали в одну кучу). Ничто ведь не мешало использовать ЕСки вместе с машинами из АСВТ и СМками -- как, собственно, и бывало на практике; да и в качестве управляющих в строгом смысле слова они никогда не годились -- слишком большие, дорогие, сложные и недостаточно надёжные. Обработка экономической информации, всякая там статистика и т.д. -- да, это их область, но не прямое управление оборудованием или участие в техпроцессах.
Ну а централизация как позволяла эффективней использовать ресурсы, не распыляя их -- но на практике получилось, что у нас ни конкуренции нормальной не было, как у капиталистов, ни эффективного использования возможностей централизации.
80 символов в строке у Кобола -- это не ограничение бумажного бланка, это ограничение перфокарты. Но, честно говоря, удивлён таким использованием сего языка. Вот экономические задачи, решаемые в пакетном режиме, на нём было писать весьма приятно.
Во-первых, есть любители истории вычислительной техники -- в первую очередь расчёт на них. Во-вторых, в технологиях 50-летней давности тоже встречаются интересные решения, особенно с учётом того, что решать приходилось сложные задачи, а ресурсы были куда более ограниченными, чем сейчас (грубо говоря, чтоб заставить мигать лампочку, нужно было делать мультивибратор на двух транзисторах, а не ставить какую-нибудь Raspberry Pi с несколькими 64-битными ядрами и десятками миллионов транзисторов).
Вычислять квадратный корень может потребоваться и на процессоре, не имеющем не только его аппаратной реализации, но и вообще какой-либо поддержки операций с плавающей запятой -- скажем, на любом микроконтроллере с ядром Cortex-M3 или вообще на Ардуине. И вот там подобная магия может дать многократный прирост (особенно если писать на ассемблере). В общем, если нечто становится не особо актуальным для ПК, может быть вполне себе актуальным для других платформ.
OS/360 -- не первая ОС для мэйнфреймов IBM; DOS/360 и ещё пара систем были разработаны раньше. Вот первой "большой" ОС, и не только для мэйнфреймов IBM, а вообще в истории, она, пожалуй, является. Не является она и "монолитным блоком программного кода", она состоит от огромного числа модулей, загружаемых по мере необходимости. Именно это дало возможность системе объёмом в несколько сотен килобайт работать на машинах с заметно меньшим объёмом памяти -- причём ещё до появления MMU, то есть без виртуальной памяти. У ядра была фиксированная часть, всегда находившаяся в основной памяти, и были модули, которые по мере необходимости загружались в транзитные области. Пользователи системы могли для неё писать свои модули, если возникала такая необходимость.
Ну, 176-я серия -- она КМОП, там с аналоговым режимом попроще будет, насколько знаю. Но вообще, народ остроумные конструкции временами делал, это да.
Не, z/Architecture -- это именно что продолжение Системы 360 -- через Систему 370, 370-XA, ESA/370 и ESA/390. Каждое новое поколение добавляло новые фишки, но полная программная совместимость прикладного кода сохранялась (вот совместимость на системном уровне была утрачена при переходе от 370 к 370-XA -- и IBM как раз поступила очень разумно, не потащив кучу старья и дальше, и предпочтя просто модифицировать код ОС -- ведь на прикладных программах изменения никак не сказались, как впрочем, и на 95% системного кода). Сейчас там, конечно, больше тыщи команд (против 144 изначально), но, в общем-то, они вполне в мозги лезут -- потому что вполне логичны, по большей части. Я, конечно, наизусть не скажу команды, скажем, векторной обработки, -- я для современных мэйнфреймов я и не писал, но их относительно немного, это не бесконечные MMX, SSE и прочие AVX, так что, если бы я их использовал постоянно, я б запомнил без проблем (ну а если б использовал изредка -- без проблем находил бы нужные команды в руководстве по архитектуре, оно не особо объёмное).
Что касается разброда и шатаний в рамках Системы 360 -- это я в курсе, естественно. Но, прямо скажем, это неудивительно: хотя сама архитектура была эпохальной, появилась-то она в переходный период (собственно, во многом его и определив), вот и страдали экспериментами. А вот какого лешего, например, чехи сделали ублюдочную ЕС-1021, этого и они сами, надо полагать, не поняли: вроде и Система 360, а на системном уровне совместимости нет, половины команд прикладного уровня тоже нет... И ведь это уже начало 1970-х было -- казалось бы, можно учесть чужой (IBMовский) опыт и не бегать по граблям...
Насчёт системы команд IA-32. Я в данном случае говорю не про вместимость черепной коробки, а про гадостность именно системы команд на базовом уровне. Например, "MOV EAX, константа" может кодироваться несколькими разными способами (а в 64-разрядной, кажется, только в RAX можно загрузить 64-разрядную константу, в остальные регистры -- фигвам); строковые операции обязательно используют ESI, EDI и ECX, использование в качестве базовых одних регистров влечёт к обращению через один сегментный регистр, а других -- через другой (и не всегда это можно подменить префиксами), длина команды не может быть определена простыми средствами и т.д. и т.п.; для деления в 8086 использовались строго определённые регистры и регистровые пары -- не помню, исправили это в 80386 или уже позже... И вся эта дурь тянется для совместимости и дальше. Причём, замечу, если некоторые косяки системы команд Системы 360 простительны -- она формировалась в первой половине 1960-х, в условиях ещё полнейшего архитектурного хаоса, то идиотизм архитекторов Интел просто поражает: они собрали практически все возможные глупые решения, но делали это уже в середине 1970-х! Более того, переходя, уже в 1980-х, на 32-разрядную систему команд, они поступили не как DEC, у которой VAX-11 "идеологически" подобен PDP-11, но на уровне кодирования команд и прочего не имеет никакой совместимости для обеспечения эффективности реализации, -- они решили тянуть прямую совместимость с откровенно уродской системой команд 8086 (сравните её, скажем, с 68000 и Z8000 -- все три этих микропроцессора являются современниками), а не оставить её чисто для 16-разрядного режима, в 32-разрядном переключаясь на новую, эффективно закодированную систему команд (VAX-11 могла выполнять прикладные программы PDP-11 именно таким путём).
Восьмеричная система, кстати, никак не напрягает, это вопрос привычки; для PDP-11 она была естественней: восемь регистров, восемь режимов адресации... Я легко прыгал с одной на другую в зависимости от того, приходилось ли иметь дело с СМкой или ЕСкой.
Насчёт терминалов. А Вы гляньте, когда появился VT100 и на чём он был сделан. IBM делала технику много раньше, на другом технологическом уровне, и для того времени всё было очень даже круто (хотя временами переусложнено -- тут соглашусь). Редактировать там, кстати, можно было не строку, а весь экран. Ну а что до ЖабаСкрипта... Он появился, по историческим меркам, вчера -- а не в эпоху мамонтов :) Вот игры -- да, бяда-бяда, но в IBM сидели скучные дяди, ориентированные исключительно на бизнес-задачи :) (Кстати, в змейке на СМке для меня всё один раз закончилось надписью "кролики кончились" :) ).
Это понятно; я к тому, что, если б у машины что-то не в порядке было с напряжением питания подложек, то микросхемы должны были бы гореть оптом, а не по штуке в месяц. Думаю, это просто ранняя серия микросхем была, ещё недостаточно надёжная (возможно, потому "золотая", типа военная, машина попала на гражданское предприятие -- подозреваю, что вояки в те годы ещё предпочитали нормально работающую ферритовую память). Но ремонтировал не я, я де-факто системщиком был и просто ковырялся в железе ради собственного удовольствия, поэтому не знаю, выходили ли из строя повторно уже заменённые микросхемы, или же дохли только те, что были установлены на заводе (микросхемы из ЗИПа были относительно новые -- примерно 1985 года выпуска или даже несколько позже; сама история имела место в конце 80-начале 90-х).
Для уровня технологий СССР -- да, но не для уровня технологий IBM, от которой мы отставали лет на 10. Поэтому если сравнивать 486, то с современной ему продукцией именно IBM.
Ну, тогда б они дохли пачками, а они отбрасывали копыта строго по одной. Так что вряд ли дело было в напряжении смещения.