История электронных компьютеров

Не меньшей проблемой оказалось определение набора команд. Команды компьютера задают его функциональность, и каждая прежняя модель имела собственный набор инструкций. При проектировании System/360 нужно было разработать универсальный компромиссный Instruction Set Architecture, который был бы достаточно богатым для сложных вычислений, но при этом не усложнял бы малые модели и не делал их медленными и дорогими. Найти баланс между универсальностью и эффективностью оказалось крайне непросто.

Одновременно инженеры сталкивались с задачей управления памятью и поддержки многозадачности. В крупных организациях уже тогда возникала потребность запускать одновременно несколько программ, обеспечивая при этом изоляцию процессов. Разработчикам пришлось создать систему виртуальной адресации и управления памятью, которая работала бы одинаково на всех моделях линейки и позволяла каждому процессу видеть «свою» память, независимо от физического объема ресурсов. Это было особенно сложно с учетом технических ограничений того времени: интегральные схемы только появлялись, дисковые и ленточные накопители были медленными, а интерфейсы ввода-вывода ограничены.

Не меньше усилий потребовала разработка масштабируемой аппаратной конструкции. Модели System/360 должны были различаться по мощности, но использовать одни и те же архитектурные принципы. Инженеры создали модульные процессоры и блоки памяти, которые можно было наращивать по мере необходимости, обеспечивая плавный переход от малых машин до крупных вычислительных центров.

Особое внимание уделялось периферийным устройствам. До System/360 каждая машина имела свои ленты, диски, принтеры и терминалы, что делало расширение и модернизацию сложными и дорогими. Для новой системы нужно было разработать унифицированные интерфейсы и протоколы обмена данными, которые позволяли подключать любую периферию ко всем моделям.

И, наконец, сама архитектура была бы бесполезна без программной поддержки. Программы должны были работать на всех моделях линейки без изменений. Для этого инженеры IBM синхронизировали разработку аппаратной части с созданием операционных систем и стандартизировали языки программирования COBOL, FORTRAN и ассемблер. Такое параллельное проектирование «железа» и софта было новым подходом для того времени и потребовало тесного взаимодействия различных групп специалистов.

Только преодолев все эти трудности – разработав единую архитектуру, стандартизовав набор команд, спроектировав масштабируемые процессоры и модули памяти, унифицировав периферию и создав универсальные операционные системы – команда IBM смогла перейти к конкретной линейке моделей System/360, которая объединила малые, средние и крупные системы в единую экосистему, задав стандарты для всей индустрии.

Принципиальные новшества System/360

Создание System/360 требовало не просто улучшения существующих технологий, а разработки принципиально новых подходов как в аппаратной архитектуре, так и в программной поддержке.

Прежде всего, инженерам IBM пришлось впервые в истории объединить разноуровневые модели в единую архитектурную платформу. Прежде каждая машина проектировалась отдельно, и каждая имела собственный набор команд. System/360 ввела концепцию универсального набора инструкций, одинакового для всех моделей, что позволило запускать одну и ту же программу как на малой, так и на сверхмощной машине. Это была революционная идея совместимости «по вертикали» – масштабируемости программного обеспечения вместе с ростом мощности аппаратуры.

Второе принципиальное новшество касалось управления памятью и многозадачностбю. В System/360 впервые была реализована система виртуальной адресации и разделения памяти между процессами, что позволяло запускать несколько программ одновременно и изолировать их друг от друга. До этого большинство компьютеров работало с физической памятью напрямую, и любая ошибка в одной программе могла повредить данные другой. Новая концепция стала предвестником будущих систем виртуализации, которые сегодня лежат в основе серверов и облачных вычислений.

Третье – масштабируемая модульная архитектура процессоров и блоков памяти. Для того чтобы разные модели линейки отличались по мощности, но оставались совместимыми, инженеры придумали принцип «строительных блоков» – процессоры, память и устройства ввода-вывода проектировались так, чтобы их можно было наращивать. Это было совершенно новым подходом: до System/360 инженеры просто проектировали отдельную машину под каждую задачу.

Четвертое новшество – унификация периферийных устройств и интерфейсов. Впервые IBM стандартизовала работу дисков, лент, терминалов и принтеров, чтобы они одинаково работали со всеми моделями. Ранее каждая машина имела свои устройства, и смена оборудования часто означала дорогостоящую переделку программ. Унификация позволила создавать общую экосистему железа и ПО.

Наконец, принципиально новым был параллельный подход к разработке аппаратуры и программного обеспечения. Для System/360 инженеры и разработчики языков программирования работали вместе с архитекторами процессоров, синхронизируя набор инструкций, операционные системы и языковые стандарты. Это позволяло обеспечить полную совместимость между железом и софтом, что было беспрецедентно.

В совокупности эти новшества сделали System/360 не просто очередной линейкой компьютеров, а фундаментом для всей индустрии вычислительной техники. Универсальная архитектура, масштабируемость, виртуализация, стандартизированная периферия и интегрированная программная поддержка стали теми принципиальными решениями, которые определяли будущее компьютеров на десятилетия вперед.

Железо и софт

В отличие от прежних подходов, где сначала создавали железо, а потом пытались подстроить под него программное обеспечение, команда IBM подошла к System/360 как к единым комплексным системам. С самого начала инженеры процессоров, архитекторы памяти и контроллеров, разработчики операционных систем и языков программирования работали параллельно и синхронно.

Каждая группа имела свои задачи, но решения одной напрямую влияли на других. Например, архитекторы процессора проектировали набор команд так, чтобы он подходил под универсальные задачи – научные расчеты, обработку транзакций, управление вводом-выводом. При этом они консультировались с разработчиками операционной системы: как эти команды будут использоваться для управления памятью, планирования задач, обеспечения многопользовательского режима. Если программисты ОС видели, что какой-то набор команд усложнит поддержку виртуальной памяти или многозадачность, это сразу обсуждалось и корректировалось на уровне архитектуры.

Аналогично, проектирование виртуальной памяти и многозадачности было тесно связано с возможностями железа. Инженеры должны были заранее предусмотреть поддержку изоляции процессов, работу с виртуальными адресами и синхронизацию нескольких потоков. Это напрямую влияло на конструкцию процессоров, регистров, контроллеров памяти. Каждый блок железа создавался с пониманием того, как его будут использовать программы, и каждая функция ОС проектировалась с учетом того, что реально может сделать процессор.

Периферийные устройства и интерфейсы – еще один пример интеграции. Разработчики ОС должны были управлять дисками, лентами, терминалами и принтерами одинаково на всех моделях. Поэтому архитекторы железа создавали унифицированные контроллеры, а программисты ОС одновременно разрабатывали драйверы и стандартизированные методы доступа. Это позволило достичь совместимости между малой и большой моделью без переписывания ПО.

Особенно сложным было согласование масштабируемости. Малые модели имели один процессор и небольшую память, крупные – несколько процессоров и огромные объемы памяти. Команды и операционная система должны были работать на всех моделях одинаково, а это означало проектирование интерфейсов и функций ОС с учетом возможного добавления процессоров, памяти и устройств. Такой уровень интеграции был тогда принципиально новым: инженеры не могли рассматривать железо и софт отдельно, они рожали систему как единое целое.

Таким образом, System/360 – это не просто машина с операционной системой. Это система, которая создавалась одновременно на двух уровнях: аппаратном и программном, где каждый элемент – процессор, память, контроллеры, ОС, языки программирования – был спроектирован с учетом работы всех остальных. Такой подход позволил IBM впервые создать линейку совместимых машин, где программы могли выполняться одинаково на малых и больших моделях, а железо и софт образовывали единый, согласованный организм.

Модели IBM/360

Когда команда IBM перешла от абстрактной идеи «универсальной системы» к созданию конкретных моделей, каждый элемент линейки проектировался одновременно с соответствующей поддержкой в операционной системе. Например, малые модели вроде 360/30 и 360/40 предназначались для небольших предприятий и отделов крупных организаций. Их процессоры были простыми по структуре, но полностью поддерживали общий набор команд, принятый для всей линейки. Это позволяло запускать те же программы, что и на больших моделях, хотя производительность была ограничена.

Для этих малых моделей инженеры создали минимальный блок процессора с базовыми регистрами и контроллерами памяти, одновременно разработав версию операционной системы, способную управлять ограниченными ресурсами. ОС должна была обеспечивать поддержку ввода-вывода, планирование задач и базовую многозадачность в условиях ограниченной памяти. Инженеры аппаратуры и разработчики софта тесно согласовывали, как каждая команда процессора будет интерпретироваться и выполняться в ОС, чтобы не нарушать совместимость с другими моделями.

Средние и крупные модели, например 360/65 и 360/75, требовали принципиально другого подхода к масштабируемости. В этих машинах использовались несколько процессоров, расширенные блоки памяти и высокопроизводительные контроллеры ввода-вывода. Архитекторы процессоров создавали модули, которые можно было добавлять или заменять без изменения основной логики команд, а программисты операционной системы проектировали механизмы управления ресурсами так, чтобы одинаково эффективно работать с малым и большим числом процессоров и объемом памяти. В результате одна и та же ОС могла запускаться как на малой, так и на большой модели, обеспечивая совместимость программного обеспечения и унификацию работы с пользователем.

Особое внимание уделялось периферийным устройствам. Диски, ленточные накопители, терминалы и принтеры разрабатывались так, чтобы одинаково работать на всех моделях. Для этого архитекторы железа создавали унифицированные контроллеры, а программисты ОС одновременно разрабатывали драйверы и стандартизированные методы доступа. Так, операционная система могла управлять устройствами независимо от мощности модели, обеспечивая клиентам возможность расширять систему без переписывания программ.

Одним из ключевых достижений было создание универсального набора команд, поддерживающего все модели. Инженеры процессоров и разработчики ОС тесно взаимодействовали, чтобы каждая команда могла выполняться на всех машинах одинаково. Это потребовало согласования работы арифметических операций, управления памятью, синхронизации процессов и ввода-вывода. Любое изменение на аппаратном уровне обсуждалось с программистами ОС, а новые функции софта учитывались при проектировании железа.

В результате совместного проектирования родились первые реальные системы System/360, где каждая модель представляла собой не отдельный компьютер, а часть единой архитектурной платформы. Малые машины обслуживали ограниченные задачи, большие – крупные вычислительные центры и банки, но все они работали одинаково, использовали один набор инструкций, унифицированные устройства и совместимое программное обеспечение. Именно эта интеграция железа и софта позволила IBM создать по-настоящему универсальную линейку компьютеров, ставшую фундаментом для всей индустрии на следующие десятилетия.

Для иллюстрации интеграции аппаратуры и программного обеспечения в линейке IBM System/360 мы выбрали две модели: 360/30 и 360/75. Причина в том, что они показывают крайние точки спектра возможностей системы. Малая модель 360/30 предназначалась для офисов и отделов средних предприятий, где важна была компактность, экономичность и работа с ограниченными ресурсами. На ее примере хорошо видно, как инженеры оптимизировали выполнение команд, управление памятью и ввод-вывод, сохранив совместимость с другими моделями.

Крупная модель 360/75 предназначалась для крупных вычислительных центров и банков, где требовалась высокая производительность, многопроцессорность и работа с большими объемами памяти и потоками данных. На ее примере можно проследить, как реализовывалась масштабируемость, управление ресурсами и поддержка сложной многозадачной среды.

Эти две модели позволяют увидеть полный диапазон решений, которые инженеры IBM внедрили, чтобы линейка System/360 стала единой и универсальной. Малая машина показывает оптимизацию ресурсов, большая – масштабирование и сложность управления, а единая архитектура объединяет их в одну систему.

Когда команда IBM приступила к созданию этих моделей, инженеры и разработчики программного обеспечения работали параллельно и синхронно. В 360/30 процессор имел минимальный набор регистров и простую структуру, поэтому пришлось тщательно продумывать, как выполнять все команды универсального набора эффективно на малой машине. Операционная система поддерживала многозадачность и управление памятью в условиях ограниченных ресурсов, а драйверы периферийных устройств позволяли подключать диски, ленточные накопители и терминалы точно так же, как на более мощных моделях.

В 360/75 задачи были иного масштаба. Множество процессоров, большие блоки памяти и высокопроизводительные контроллеры ввода-вывода требовали разработки модульной архитектуры, где процессоры и память можно было наращивать без изменения набора команд. Операционная система распределяла ресурсы между процессорами, синхронизировала параллельные процессы и обеспечивала безопасное многопользовательское использование. Контроллеры периферийных устройств и драйверы ОС создавались так, чтобы одинаково работать на малых и больших моделях, обеспечивая совместимость и унификацию.

Особое внимание уделялось согласованию арифметических и логических операций процессоров с механизмами ОС. На 360/30 каждая операция должна была выполняться быстро на ограниченном железе, а на 360/75 – масштабироваться и работать в многопроцессорной среде. Инженеры разработали микропрограммы и аппаратные блоки так, чтобы одна и та же инструкция обеспечивала одинаковое поведение в разных условиях, а операционная система могла управлять процессами без зависимости от мощности машины.

В результате каждая модель System/360, от малой 360/30 до крупной 360/75, стала частью единой архитектурной системы. Программы, драйверы, операционная система и устройства ввода-вывода работали согласованно, обеспечивая совместимость и масштабируемость. Именно эта интеграция аппаратуры и софта позволила IBM превратить концепцию «универсальной системы» в реальные машины, способные удовлетворять потребности как малых офисов, так и крупных банков и научных центров.

Основные модели:

• Модели 20, 22, 25 – предназначены для малых предприятий и офисов.

• Модели 30, 40, 50, 65, 67 – средний диапазон, включая научные и корпоративные приложения.

• Модели 75, 85, 91, 95, 195 – высокопроизводительные системы для крупных вычислительных центров и научных исследований.

• Некоторые модели, такие как 64 и 66, были анонсированы, но не поступили в производство. Модели 60 и 62 также не были выпущены, замененные на 65. Википедия+1

• По данным, к концу 1970 года в США было установлено более 7 400 процессоров модели 20, что делает ее самой успешной по количеству установленных машин в линейке System/360. Однако, несмотря на популярность, количество работающих экземпляров модели 20 в 2020 году было ограничено

• Для других моделей точные данные о количестве выпущенных машин варьируются. Например, модель 91 была произведена в количестве от 10 до 20 экземпляров, из которых 4 использовались внутри IBM. Модель 195 также была выпущена ограниченным тиражом – около 20 систем.

• Решение о разработке System/370 было принято в 1968 году, а анонс состоялся в июне 1970 года. System/370 сохраняла совместимость с System/360, но включала новые архитектурные и технологические улучшения.

IBM System/370

Системы IBM System/370 появились в 1970 году как логическое продолжение System/360. Основная идея была в том, чтобы взять проверенную архитектуру, которая уже работала у клиентов, и сделать ее гораздо более гибкой и мощной. Системная точка зрения изменений сводилась к тому, что теперь машина могла работать с гораздо более крупными и сложными программами за счет виртуальной памяти. Раньше программы были «привязаны» к физической памяти – если памяти не хватало, программа не запускалась. В 370-й системе появились аппаратные механизмы, которые позволяли «подменять» части памяти и работать с программами, размер которых превышал объем физической памяти. Это дало возможность одновременно запускать больше задач и повышало надежность работы – программы теперь были защищены друг от друга и не могли «засорять» чужую память.

С аппаратной точки зрения основное изменение – использование интегральных схем вместо транзисторов. Это позволило сделать процессор компактнее, быстрее и надежнее. Появились новые каналы ввода-вывода и контроллеры для работы с дисками и ленточными накопителями, что увеличивало скорость обработки данных и расширяло возможности подключения периферии. Также стало возможным объединять несколько процессоров в одной системе – то, что мы сегодня называем многопроцессорной конфигурацией.

С точки зрения программного обеспечения изменения тоже были существенными. Операционные системы OS/VS1 и OS/VS2 научились работать с виртуальной памятью, появились новые механизмы многозадачности, управления памятью и защиты программ. Все это позволяло писать более сложные, устойчивые и безопасные приложения.

Количество выпущенных машин трудно назвать точно, но ясно, что они были очень популярны в банках, государственных учреждениях и научных лабораториях. S/370 стал настоящей рабочей лошадкой, обеспечив переход от транзисторных машин к интегральным схемам и подготовив почву для более мощных мейнфреймов следующего поколения.

IBM System/390

System/390 появилась примерно в начале 1990-х и стала логическим продолжением 370-й серии, но уже с серьезным обновлением архитектуры. Если 370-й фокусировался на виртуальной памяти и надежности, то 390-й ориентировался на масштабируемость, производительность и интеграцию с корпоративными системами.

С системной точки зрения здесь появилась архитектура ESA/390. Она расширила адресное пространство, улучшила поддержку многопроцессорных конфигураций и позволила системе обрабатывать одновременно еще больше задач. Машины 390-й серии умели работать с большим количеством устройств и каналов ввода-вывода, что делало их удобными для центров обработки данных и крупных предприятий.

Аппаратно машины стали еще быстрее, надежнее и экономичнее. Они использовали более совершенные микросхемы, высокоскоростные каналы связи с периферией и новые технологии управления памятью. Благодаря этому мейнфреймы 390-й серии могли выполнять сложные вычислительные задачи в корпоративной среде без серьезных узких мест.

С программной стороны была введена операционная система OS/390, которая поддерживала все новые возможности архитектуры, включая распределенные вычисления, усовершенствованное управление данными и высокую надежность работы. Программы, написанные для S/370, могли выполняться на S/390 практически без изменений, но при этом они автоматически получали доступ к новым возможностям и повышенной производительности.

Как и 370-й, S/390 был массово использован в банках, телекоммуникациях и других больших организациях, где критически важна надежность, непрерывная работа и обработка огромного объема данных.

IBM zSeries (начало 2000-х)

С появлением zSeries IBM ввела архитектуру, названную z/Architecture, которая впервые сделала мейнфреймы полностью 64-битными. Это был ключевой шаг: адресное пространство резко увеличилось, что позволило работать с огромными объемами памяти и хранить данные в размерах, которые ранее были невозможны. Для крупных банков, страховых компаний, телекомов и государственных структур это означало, что можно обрабатывать миллионы транзакций и одновременно работать с огромными базами данных без ограничений старой 31-битной архитектуры.

Архитектура zSeries встроила поддержку современных сетевых технологий и криптографических функций на аппаратном уровне. Кроме того, она позволяла виртуализировать всю систему – целиком, а не по отдельным процессам – что значительно повысило эффективность использования ресурсов и надежность. При этом сохранялась полная совместимость с программами S/390, что позволило клиентам обновлять железо без переписывания приложений.

IBM System z

Следующий шаг – серия System z – развивала концепцию масштабируемости и интеграции. Системы стали поддерживать сотни тысяч одновременных операций, десятки ядер и тысячи потоков. Вводились новые функции безопасности, поддержка современных операционных систем, включая Linux, и инструменты для интеграции с распределенными системами. Здесь мейнфрейм превращался из «локальной вычислительной машины» в «центр корпоративной вычислительной инфраструктуры», который мог взаимодействовать с внешними системами, облаками и высокоскоростными сетями.

Современные IBM Z – это вершина эволюции мейнфреймов. Они полностью 64-битные, рассчитаны на обработку огромных объемов данных и имеют встроенные аппаратные возможности для шифрования и защиты информации. Эти системы поддерживают контейнеры, облачные технологии и интеграцию с современными DevOps-процессами, сохраняя при этом полную совместимость с кодом, написанным еще для S/370, S/390 или z/Architecture.

Когда IBM представила zSeries в начале 2000-х, это был настоящий качественный рывок. Архитектура z/Architecture сразу перевела мейнфреймы в 64-битную эру. Почему это было важно? Потому что предыдущая система, S/390, ограничивалась 31-битной адресацией. На практике это означало, что физически и логически доступная память ограничивала программы и базы данных, а крупные предприятия все больше сталкивались с этим потолком. С переходом на 64 бита задачи вроде управления банковскими транзакциями, обработкой страховых портфелей или телеком-данных стали решаемыми на одном и том же физическом железе, без необходимости дробить нагрузки на несколько машин.

Аппаратная база zSeries была построена на микропроцессорах RISC POWER. Этот момент особенный: ранее процессоры мейнфреймов представляли собой сложные интегральные схемы, где каждая логика была «своя», но с POWER IBM смогла стандартизировать ядро, повысить тактовые частоты, добавить многопоточность и снизить энергопотребление. И при этом весь исторический код S/390 продолжал работать без изменений. Это, по сути, был мост между старым и новым: старые программы жили на новом железе, а новые задачи можно было решать уже эффективно и масштабируемо.

Программно zSeries принесла еще одно важное новшество – полноценную виртуализацию на уровне всей системы через z/VM. В старых системах виртуализация была локальной, ограниченной процессом или группой процессов. Теперь можно было запустить сотни и тысячи виртуальных машин на одном мейнфрейме, и каждая чувствовала себя полностью автономной. Это резко увеличило эффективность использования ресурсов и стало прямым ответом на требования корпоративной IT-инфраструктуры: нагрузка распределялась автоматически, и при этом сохранялась полная совместимость со старыми приложениями. Появилась также поддержка Linux, что открыло дверь для open-source и современных распределенных приложений.

Следующий шаг System z развивал эти идеи дальше. Если zSeries уже был «умным городом», то System z можно представить как город с развитыми транспортными магистралями, центрами управления и системами безопасности. Аппаратная база стала еще более плотной: процессоры стали более производительными, появилось больше ядер, улучшена работа кэшей и шины памяти. Системы могли одновременно управлять большим числом потоков, поддерживать высокоскоростные каналы ввода-вывода и интегрироваться с внешними распределенными системами. Программное обеспечение тоже эволюционировало: z/OS теперь умела управлять этой сложной многопроцессорной инфраструктурой, поддерживала виртуализацию, шифрование и распределенные вычисления. Linux на System z стал полноценным игроком: предприятия получили возможность запускать современные приложения на мейнфрейме, не отказываясь от проверенной надежной среды для критичных данных.