Проект Future Systems ( FS ) был научно-исследовательским и опытно-конструкторским проектом, предпринятым в IBM в начале 1970-х годов с целью создания революционной линейки компьютерных продуктов, включая новые модели программного обеспечения, которые упростили бы разработку программного обеспечения за счет использования современного мощного оборудования .
В FS было два ключевых компонента. Первый заключался в использовании одноуровневого хранилища , которое позволяло ссылаться на данные, хранящиеся на вторичном хранилище, например на дисковых накопителях , в программе так, как если бы это были данные, хранящиеся в основной памяти ; переменные в коде могли указывать на объекты в хранилище, и они были бы незаметно загружены в память, устраняя необходимость писать код для обработки файлов. Второй заключался в включении инструкций, соответствующих операторам в языках программирования высокого уровня , что позволяло системе напрямую запускать программы без необходимости в компиляторе для преобразования из языка в машинный код . Например, можно было написать программу в текстовом редакторе , и машина могла бы запустить ее напрямую.
Объединение двух концепций в одной системе за один шаг оказалось невыполнимой задачей. Эта проблема была отмечена инженерами с самого начала, но она была проигнорирована руководством и руководителями проекта по многим причинам. Официально начатый осенью 1971 года, к 1974 году проект был уже неактуален и официально отменен в феврале 1975 года. Одноуровневое хранилище было реализовано в System/38 и затем перенесено в другие системы в линейке, но концепция машины, которая напрямую запускала языки высокого уровня, никогда не появлялась в продуктах IBM.
System /360 была анонсирована в апреле 1964 года. Всего шесть месяцев спустя IBM начала исследовательский проект по изучению тенденций, которые имели место на рынке и как их следует использовать в серии машин, которые заменят 360 в будущем. Одним из существенных изменений стало введение полезных интегральных схем (ИС), которые позволили бы заменить множество отдельных компонентов 360 меньшим количеством ИС. Это позволило бы построить более мощную машину по той же цене, что и существующие модели. [1]
К середине 1960-х годов 360-я стала массовым бестселлером. Это повлияло на конструкцию новых машин, поскольку привело к требованиям, чтобы машины имели полную обратную совместимость с серией 360. Когда машины были анонсированы в 1970 году, теперь известные как System /370 , они по сути были 360-ми, использующими малогабаритные ИС для логики, гораздо большие объемы внутренней памяти и другие относительно незначительные изменения. [2] Было добавлено несколько новых инструкций, а другие были очищены, но система была в значительной степени идентична с точки зрения программиста. [3]
Рецессия 1969–1970 годов привела к замедлению продаж в период 1970–1971 годов и гораздо меньшим заказам на 370 по сравнению с быстрым распространением 360 пятью годами ранее. [4] Впервые за десятилетия рост IBM остановился. В то время как некоторые в компании начали попытки внедрить полезные усовершенствования в 370 как можно скорее, чтобы сделать их более привлекательными, другие считали, что в долгосрочной перспективе сработает только полное переосмысление системы. [3]
За два месяца до анонса 370-х годов компания снова начала рассматривать изменения на рынке и то, как они повлияют на будущие разработки. [3] В 1965 году Гордон Мур предсказал, что интегральные схемы увидят экспоненциальный рост числа поддерживаемых ими схем, что сегодня известно как закон Мура . Джерриер А. Хаддад из IBM написал меморандум на эту тему, предположив, что стоимость логики и памяти стремится к нулю быстрее, чем ее можно измерить. [3]
Внутреннее исследование Комитета по корпоративным технологиям (CTC) пришло к выводу, что в течение следующих пяти лет произойдет 30-кратное снижение цен на память, и еще в 30 раз — в течение следующих пяти лет. Если IBM собиралась сохранить свои показатели продаж, ей пришлось бы продать в 30 раз больше памяти за пять лет и в 900 раз больше еще через пять лет. Аналогично ожидалось, что стоимость жестких дисков упадет в десять раз за следующие десять лет. Чтобы сохранить свой традиционный 15%-ный рост из года в год, к 1980 году им пришлось бы продавать в 40 раз больше дискового пространства и в 3600 раз больше памяти. [4]
Что касается самого компьютера, если проследить прогресс от 360 до 370 и до некоторой гипотетической System/380, то новые машины будут основаны на крупномасштабной интеграции и будут значительно снижены по сложности и стоимости. Не было никакого способа, которым они могли бы продать такую машину по их текущей цене, если бы они попытались, другая компания представила бы гораздо менее дорогие системы. [3] Вместо этого они могли бы производить гораздо более мощные машины по тем же ценам, но их клиенты уже недоиспользовали свои существующие системы. Чтобы предоставить разумный аргумент для покупки новой высококлассной машины, IBM пришлось придумать причины, по которым их клиентам нужна эта дополнительная мощность. [5] [6]
Другой стратегический вопрос заключался в том, что в то время как стоимость вычислений неуклонно снижалась, расходы на программирование и эксплуатацию, состоящие из расходов на персонал, неуклонно росли. Таким образом, часть ИТ-бюджета заказчика, доступная поставщикам оборудования, в ближайшие годы значительно сократится, а вместе с ней и база для доходов IBM. Было крайне важно, чтобы IBM, обращаясь к стоимости разработки приложений и эксплуатации в своих будущих продуктах, одновременно снизила общую стоимость ИТ для заказчиков и захватила большую часть этой стоимости. [6]
В 1969 году Боб О. Эванс , президент подразделения IBM System Development Division, которое разработало их самые большие мэйнфреймы , попросил Эриха Блоха из IBM Poughkeepsie Lab рассмотреть, как компания могла бы использовать эти гораздо более дешевые компоненты для создания машин, которые все еще сохраняли бы прибыль компании. Блох, в свою очередь, попросил Карла Конти описать такие системы. Увидев, что используется термин «будущие системы», Эванс назвал группу Advanced Future Systems. Группа встречалась примерно раз в две недели.
Среди множества разработок, изначально изучавшихся в рамках AFS, выделялась одна концепция. В то время появлялись первые системы с виртуальной памятью (VM), и основополагающий проект Multics расширил эту концепцию в качестве основы для одноуровневого хранилища . В этой концепции все данные в системе обрабатываются так, как будто они находятся в основной памяти , и если данные физически расположены во вторичном хранилище , система VM автоматически загружает их в память, когда программа этого требует. Вместо того чтобы писать код для чтения и записи данных в файлы, программист просто говорил операционной системе, что они будут использовать определенные данные, которые затем появлялись как объекты в памяти программы и могли манипулироваться как любая другая переменная . Система VM обеспечивала синхронизацию данных с хранилищем при необходимости. [7]
В то время это считалось особенно полезной концепцией, поскольку появление пузырьковой памяти предполагало, что будущие системы не будут иметь отдельной основной памяти и дисковых накопителей , вместо этого все будет храниться в большом объеме пузырьковой памяти. [7] Физически системы будут одноуровневыми хранилищами, поэтому идея наличия еще одного слоя для «файлов», представляющего отдельное хранилище, не имела смысла, а наличие указателей на одну большую память не только означало бы, что можно просто ссылаться на любые данные, как если бы они были локальными, но и устраняло бы необходимость в отдельных интерфейсах прикладного программирования (API) для тех же данных в зависимости от того, загружены они или нет. [7]
Эванс также попросил Джона Макферсона из штаб-квартиры IBM в Армонке возглавить другую группу, чтобы рассмотреть, как IBM будет предлагать эти новые разработки во многих своих подразделениях. Группа из двенадцати участников, распределенных по трем подразделениям, подготовила «Higher Level System Report» (отчет о высокоуровневой системе), или HLS, который был представлен 25 февраля 1970 года. Ключевым компонентом HLS была идея о том, что программирование дороже оборудования. Если система могла значительно снизить стоимость разработки, то ее можно было продать дороже, поскольку общая стоимость эксплуатации все равно была бы ниже, чем у конкурентов. [8]
Основная концепция серии System/360 заключалась в том, что будет определена архитектура с единым набором инструкций (ISA), которая будет предлагать все возможные инструкции, которые может пожелать программист на языке ассемблера . В то время как предыдущие системы могли быть предназначены для научного программирования или валютных расчетов и имели инструкции для такого рода данных, 360 предлагала инструкции для обеих этих и практически для любой другой задачи. Затем были разработаны отдельные машины, которые были нацелены на определенные рабочие нагрузки и запускали эти инструкции непосредственно в оборудовании и реализовывали другие в микрокоде . Это означало, что любая машина в семействе 360 могла запускать программы с любой другой, просто быстрее или медленнее в зависимости от задачи. Это оказалось чрезвычайно успешным, поскольку клиент мог купить машину низкого класса и всегда обновляться до более быстрой в будущем, зная, что все его приложения будут продолжать работать.
Хотя набор инструкций 360 был большим, эти инструкции все еще были низкоуровневыми, представляя собой отдельные операции, которые выполнял центральный процессор (ЦП), например, «сложить два числа» или «сравнить это число с нулем». Языки программирования и их связи с операционной системой позволяли пользователям вводить программы, используя высокоуровневые концепции, например, «открыть файл» или «сложить эти массивы». Компиляторы преобразовывали эти высокоуровневые абстракции в ряд инструкций машинного кода .
Для HLS инструкции вместо этого представляли бы эти высокоуровневые задачи напрямую. То есть, в машинном коде были бы инструкции для «открыть файл». Если программа вызывала эту инструкцию, не было бы необходимости преобразовывать ее в низкоуровневый код, машина делала бы это внутренне в микрокоде или даже прямой аппаратной реализации. [8] Это работало рука об руку с одноуровневым хранилищем; для реализации HLS каждый бит данных в системе был связан с дескриптором , записью, которая содержала тип даты, ее местоположение в памяти, а также ее точность и размер. Поскольку дескрипторы могли указывать на массивы и структуры записей, это позволяло машинному языку обрабатывать их как атомарные объекты. [8]
Представляя эти гораздо более высокоуровневые объекты непосредственно в системе, пользовательские программы будут намного меньше и проще. Например, чтобы сложить два массива чисел, хранящихся в файлах на традиционных языках, обычно нужно открыть два файла, прочитать один элемент из каждого, добавить их, а затем сохранить значение в третьем файле. В подходе HLS нужно просто открыть файлы и вызвать add. Базовая операционная система сопоставит их в памяти, создаст дескрипторы, показывающие, что они оба являются массивами, а затем инструкция add увидит, что они являются массивами, и сложит все значения вместе. Присвоение этого значения вновь созданному массиву будет иметь эффект записи его обратно в хранилище. Программа, которая могла бы занять страницу или около того кода, теперь была сокращена до нескольких строк. Более того, поскольку это был естественный язык машины, командная оболочка сама по себе была программируемой таким же образом, не было бы необходимости «писать программу» для такой простой задачи, ее можно было бы ввести как команду. [8]
В отчете сделан вывод:
Пользователь и IBM должны существенно выиграть от более легкого кодирования и отладки лаконичных программ. Мы ожидаем резкого снижения стоимости программирования и размера сложных программ, поскольку и качество программ, и производительность программистов улучшаются. [8]
До конца 1960-х годов IBM получала большую часть прибыли от оборудования, объединяя программное обеспечение и услуги поддержки вместе со своими системами, чтобы сделать их более привлекательными. Только оборудование имело ценник, но эти цены включали распределение на программное обеспечение и услуги. [7]
Другие производители начали продавать совместимое оборудование, в основном периферийные устройства, такие как ленточные и дисковые накопители , по цене значительно ниже, чем у IBM, тем самым сокращая возможную базу для возмещения стоимости программного обеспечения и услуг. IBM ответила отказом обслуживать машины с этими сторонними надстройками, что почти сразу привело к масштабным антимонопольным расследованиям и многим последующим судебным мерам. В 1969 году компания была вынуждена прекратить свои соглашения о пакетировании и объявила, что будет продавать программные продукты отдельно. [9]
Джин Амдал увидел возможность продавать совместимые машины без программного обеспечения; клиент мог купить машину у Амдала, а операционную систему и другое программное обеспечение у IBM. Если бы IBM отказалась продать им это, они бы нарушили свои юридические обязательства. В начале 1970 года Амдал ушел из IBM и объявил о своем намерении представить совместимые с System/370 машины, которые были бы быстрее, чем высококлассные предложения IBM, но стоили бы меньше при покупке и эксплуатации. [10]
Сначала IBM не беспокоилась. Они заработали большую часть своих денег на программном обеспечении и поддержке, и эти деньги все равно шли бы им. Но, чтобы быть уверенной, в начале 1971 года была сформирована внутренняя целевая группа IBM, Project Counterpoint, для изучения концепции. Они пришли к выводу, что бизнес совместимых мэйнфреймов действительно был жизнеспособным и что основа для взимания платы за программное обеспечение и услуги как части цены на оборудование быстро исчезнет. Эти события породили желание внутри компании найти какое-то решение, которое снова заставило бы клиентов покупать все у IBM, но таким образом, чтобы не нарушать антимонопольное законодательство. [7]
Если бы IBM последовала рекомендациям отчета HLS, это означало бы, что другим поставщикам пришлось бы копировать микрокод , реализующий огромное количество инструкций. Поскольку это было программное обеспечение, если бы они это сделали, эти компании подверглись бы нарушению авторских прав. [7] В этот момент концепции AFS/HLS получили новую популярность в компании.
В мае-июне 1971 года в Армонке собралась международная целевая группа под руководством Джона Опеля , тогдашнего вице-президента IBM. Ее задачей было исследовать осуществимость новой линейки компьютеров, которая использовала бы технологические преимущества IBM, чтобы сделать устаревшими все предыдущие компьютеры - совместимые предложения, а также собственные продукты IBM. Целевая группа пришла к выводу, что проект стоит продолжения, но что ключом к принятию на рынке является сокращение на порядок затрат на разработку, эксплуатацию и обслуживание прикладного программного обеспечения.
Основные цели проекта FS были сформулированы следующим образом:
Была надежда, что новая архитектура, более интенсивно использующая аппаратные ресурсы, стоимость которых снижалась, могла бы значительно упростить разработку программного обеспечения и сократить расходы как для IBM, так и для клиентов.
Одним из принципов проектирования FS было « одноуровневое хранилище », которое расширило идею виртуальной памяти (VM) для покрытия постоянных данных. В традиционных проектах программы выделяют память для хранения значений, представляющих данные. Эти данные обычно исчезали, если машина выключалась или пользователь выходил из системы. Чтобы эти данные были доступны в будущем, необходим дополнительный код для записи их в постоянное хранилище, например на жесткий диск , а затем для их повторного считывания в будущем. Чтобы упростить эти общие операции, в 1960-х годах появилось несколько механизмов баз данных , которые позволяли программам передавать данные механизму, который затем сохранял их и снова извлекал по требованию.
Другой развивающейся технологией в то время была концепция виртуальной памяти. В ранних системах объем памяти, доступной программе для выделения данных, был ограничен объемом основной памяти в системе, который мог меняться в зависимости от таких факторов, как перемещение с одной машины на другую или выделение памяти другими программами. Системы виртуальной памяти решали эту проблему, определяя максимальный объем памяти, доступный всем программам, обычно очень большое число, намного большее, чем физическая память в машине. В случае, если программа запрашивает выделение памяти, которая физически недоступна, блок основной памяти записывается на диск, и это пространство используется для нового выделения. Если программа запрашивает данные из этой выгруженной («выгружаемой» или «буферизованной») области памяти, они невидимо загружаются обратно в основную память. [11]
Одноуровневое хранилище по сути является расширением виртуальной памяти на всю память, внутреннюю или внешнюю. Системы VM невидимо записывают память на диск, что является той же задачей, что и файловая система, поэтому нет причин, по которым ее нельзя использовать в качестве файловой системы. Вместо того, чтобы программы выделяли память из «основной памяти», которая затем, возможно, отправляется в какое-то другое резервное хранилище VM, вся память немедленно выделяется VM. Это означает, что нет необходимости сохранять и загружать данные, простое выделение их в памяти будет иметь тот же эффект, поскольку система VM записывает их. Когда пользователь снова входит в систему, эти данные и программы, которые их запускали, поскольку они также находятся в той же объединенной памяти, немедленно доступны в том же состоянии, в котором они были раньше. Вся концепция загрузки и сохранения удаляется, программы и целые системы возвращаются туда, где они были, даже после перезапуска машины.
Эта концепция была исследована в системе Multics , но оказалась очень медленной, но это был побочный эффект доступного оборудования, где основная память была реализована в ядре с гораздо более медленным резервным хранилищем в виде жесткого диска или барабана . С введением новых форм энергонезависимой памяти , в частности пузырьковой памяти [7] , которая работала со скоростью, схожей с ядром, но имела плотность памяти , схожую с жестком диском, казалось, что одноуровневое хранилище больше не будет иметь никаких недостатков производительности.
Future Systems планировала сделать одноуровневое хранилище ключевой концепцией в своих новых операционных системах. Вместо того, чтобы иметь отдельный движок базы данных, который программисты будут вызывать, будут просто вызовы в интерфейсе прикладного программирования системы (API) для извлечения памяти. И эти вызовы API будут основаны на конкретных аппаратных или микрокодовых реализациях, которые будут доступны только в системах IBM, тем самым достигая цели IBM по тесной привязке оборудования к программам, которые на нем работают. [7]
Другим принципом было использование очень высокоуровневых сложных инструкций для реализации в микрокоде . Например, одна из инструкций, CreateEncapsulatedModule, была полным редактором связей. Другие инструкции были разработаны для поддержки внутренних структур данных и операций языков программирования, таких как FORTRAN , COBOL и PL/I . По сути, FS был разработан как компьютер с окончательным набором сложных инструкций ( CISC ). [7]
Другой способ представления той же концепции состоял в том, что весь набор функций, ранее реализованных как аппаратное обеспечение, программное обеспечение операционной системы , программное обеспечение базы данных и многое другое, теперь будет рассматриваться как составляющая одну интегрированную систему, в которой каждая элементарная функция реализована на одном из многих слоев, включая схему, микрокод и обычное программное обеспечение . Рассматривалось более одного слоя микрокода и кода, иногда называемого пикокодом или милликодом . В зависимости от того, с кем общались, само понятие «машины» поэтому варьировалось от тех функций, которые были реализованы как схемы (для специалистов по аппаратному обеспечению) до полного набора функций, предлагаемых пользователям, независимо от их реализации (для системных архитекторов).
Общая конструкция также требовала «универсального контроллера» для обработки в первую очередь операций ввода-вывода за пределами основного процессора. Этот универсальный контроллер имел бы очень ограниченный набор инструкций, ограниченный теми операциями, которые требуются для ввода-вывода, что стало пионером концепции компьютера с сокращенным набором инструкций (RISC).
Тем временем Джон Кок , один из главных конструкторов ранних компьютеров IBM, начал исследовательский проект по разработке первого компьютера с сокращенным набором команд ( RISC ). [ требуется ссылка ] В долгосрочной перспективе архитектура IBM 801 RISC, которая в конечном итоге развилась в архитектуры IBM POWER , PowerPC и Power , оказалась значительно дешевле в реализации и способна достигать гораздо более высокой тактовой частоты.
Проект FS был официально начат в сентябре 1971 года в соответствии с рекомендациями специальной целевой группы, собранной во втором квартале 1971 года. Со временем несколько других исследовательских проектов в различных подразделениях IBM объединились в проект FS или стали ассоциироваться с ним.
В течение всего срока службы проект FS проводился в условиях строгих мер безопасности. Проект был разбит на множество подпроектов, назначенных разным командам. Документация также была разбита на множество частей, и доступ к каждому документу зависел от проверки необходимости знать со стороны проектного офиса. Документы отслеживались и могли быть отозваны в любое время.
В своей служебной записке (см. Внешние ссылки ниже) Сова отметил, что общепризнанная цель всей этой бюрократической волокиты — помешать кому-либо понять всю систему; эта цель, безусловно, достигнута.
В результате большинство людей, работающих над проектом, имели крайне ограниченное представление о нем, ограниченное тем, что им нужно было знать, чтобы внести ожидаемый вклад. Некоторые команды даже работали над FS, не зная этого. Это объясняет, почему, когда их просят дать определение FS, большинство людей дают очень частичный ответ, ограниченный пересечением FS с их областью компетенции.
Было запланировано три реализации архитектуры FS: модель высшего уровня разрабатывалась в Покипси, штат Нью-Йорк , где были построены самые большие и самые быстрые компьютеры IBM; следующая по уровню модель разрабатывалась в Эндикотте, штат Нью-Йорк , который отвечал за компьютеры среднего уровня; модель, расположенная ниже, разрабатывалась в Бёблингене, Германия , а самая маленькая модель разрабатывалась в Херсли, Великобритания . [12]
Непрерывный диапазон производительности может быть обеспечен путем изменения количества процессоров в системе на каждом из четырех уровней реализации.
В начале 1973 года общее руководство проектом и команды, отвечающие за более «внешние» уровни, общие для всех реализаций, были объединены в лаборатории Mohansic ASDD (на полпути между штаб-квартирой в Армонке/Уайт-Плейнс и Покипси).
Проект FS был прекращен в 1975 году. Причины прекращения проекта зависят от человека, которому задавали вопрос, каждый из которых выдвигал проблемы, связанные с областью, с которой он был знаком. В действительности успех проекта зависел от большого количества прорывов во всех областях, от проектирования схем и производства до маркетинга и обслуживания. Хотя каждая отдельная проблема, взятая в отдельности, могла быть решена, вероятность того, что все они могли быть решены вовремя и взаимно совместимыми способами, была практически нулевой.
Одним из симптомов была низкая производительность его самой большой реализации, но проект также был омрачен затяжными внутренними спорами о различных технических аспектах, включая внутренние дебаты IBM о достоинствах конструкций RISC против CISC. Сложность набора инструкций была еще одним препятствием; собственные инженеры IBM считали его «непонятным», и были веские основания полагать, что общесистемное одноуровневое хранилище не может быть частично резервировано, [ необходимо разъяснение ] предсказывающее разбиение IBM AS/400 одноуровневого хранилища System/38. [13] [ необходимо разъяснение ] Более того, моделирование показало, что выполнение собственных инструкций FS на высокопроизводительной машине было медленнее, чем эмулятор System/370 на той же машине. [14]
Проект FS был окончательно прекращен, когда IBM поняла, что принятие клиентами будет гораздо более ограниченным, чем изначально предполагалось, поскольку не было разумного пути миграции приложений для клиентов архитектуры 360. Чтобы предоставить максимальную свободу для проектирования действительно революционной системы, простота миграции приложений не была одной из основных целей проектирования для проекта FS, но должна была быть решена с помощью средств миграции программного обеспечения, принимающих новую архитектуру как данность. В конце концов, оказалось, что стоимость миграции массы пользовательских инвестиций в приложения на основе COBOL и ассемблера в FS во многих случаях, вероятно, будет выше, чем стоимость приобретения новой системы.
Хотя проект FS в целом был прекращен, упрощенная версия архитектуры для самой маленькой из трех машин продолжала разрабатываться в Рочестере. В конце концов она была выпущена как IBM System/38 , которая оказалась хорошим дизайном для простоты программирования, но была ужасно недостаточно мощной. AS/400 унаследовала ту же архитектуру, но с улучшениями производительности. В обеих машинах набор высокоуровневых инструкций, сгенерированный компиляторами, не интерпретируется, а транслируется в набор машинных инструкций более низкого уровня и выполняется; исходный набор низкоуровневых инструкций был набором инструкций CISC с некоторым сходством с набором инструкций System/360 . [15] В более поздних машинах набор низкоуровневых инструкций был расширенной версией набора инструкций PowerPC , который произошел от машины RISC Джона Кока. Специализированная аппаратная платформа была заменена в 2008 году платформой IBM Power Systems, работающей под управлением операционной системы IBM i .
Помимо System/38 и AS/400, которые унаследовали большую часть архитектуры FS, отдельные элементы технологии Future Systems были включены в следующие части линейки продуктов IBM: