Проект IBM «Будущие системы» (, FS) представлял собой научно-исследовательскую и опытно-конструкторскую разработку, начатую в IBM в начале 1970-х годов. Целью проекта было создание революционной линейки компьютерных продуктов, включая новые программные модели, которые должны были упростить разработку программного обеспечения за счёт использования современного мощного оборудования. Предполагалось, что новые системы заменят на рынке модель System/370 к концу 1970-х годов.

Было два ключевых компонента FS. Первый — это использование одноуровневого хранилища, которое позволяло обращаться к данным, хранящимся во вторичной памяти, такой как жёсткие диски, в программе так, как если бы они находились в основной памяти. Переменные в коде могли указывать на объекты в хранилище, и они автоматически загружались бы в память, устраняя необходимость писать код для обработки файлов. Второй компонент заключался во включении в систему инструкций, соответствующих операторам языков программирования высокого уровня, Это позволяло системе напрямую выполнять программы без необходимости использования компилятора для преобразования языка в машинный код. Таким образом, можно было, например, написать программу в текстовом редакторе и машина смогла бы выполнить её напрямую.

Объединение этих двух концепций в единую систему за один шаг оказалось невыполнимой задачей. Инженеры с самого начала указывали на эту проблему, но руководители проекта игнорировали её по многим причинам. Официально начатый осенью 1971 года, к 1974 году проект заглох, а в феврале 1975 года был официально отменён. Одноуровневая память была реализована в System/38 в 1978 году и впоследствии перенесена на другие системы в линейке, но концепция машины, непосредственно работающей с языками высокого уровня, так и не появилась ни в одном продукте IBM.

История

370 System/360 анонсирована в апреле 1964. Всего через шесть месяцев IBM начала исследовательский проект, посвященный тенденциям на рынке и тому, как их следует использовать при создании серии машин, которые в будущем должны были заменить модель 360. Одним из значительных изменений стало внедрение интегральных схем (ИС), которые позволили заменить множество отдельных компонентов модели 360 меньшим количеством ИС. Это позволило бы создавать более мощные машины по той же цене, что и существующие модели.

К середине 1960-х годов модель 360 стала чрезвычайно популярной и хорошо продавалась. Это повлияло на разработку новых машин, поскольку возникла потребность в полной обратной совместимости с серией 360. Когда в 1970 году были представлены новые машины 1970, теперь известные как System/370, они, по сути, представляли собой модифицированные 360-е, в которых использовались интегральные схемы малой степени интеграции для логики, значительно увеличенный объём внутренней памяти и другие незначительные изменения. Было добавлено несколько новых инструкций и улучшены существующие, но с точки зрения программиста система осталась практически неизменной.

Экономический спад 1969–1970 годов привёл к замедлению продаж в период 1970-71 годов и гораздо меньшим заказам на 370 по сравнению с быстрым успехом 360 пятью годами ранее. Впервые за десятилетия рост IBM остановился. В то время как некоторые сотрудники компании начали работать над внедрением полезных улучшений в 370 как можно скорее, чтобы сделать их более привлекательными, другие считали, что в долгосрочной перспективе сработает только полное переосмысление системы.

Замена 370 За два месяца до анонса серии 370 компания вновь начала анализировать изменения на рынке и их влияние на будущие разработки. В 1965 году Гордон Мур предсказал экспоненциальный рост числа транзисторов в интегральных схемах, что сегодня известно как Закон Мура. из IBM написал служебную записку на эту тему, предположив, что стоимость логических элементов и памяти будет стремиться к нулю быстрее, чем её можно будет измерить.

Внутреннее исследование Корпоративного технологического комитета (, CTC) показало, что в течение следующих пяти лет цена на память снизится в 30 раз, а в последующие пять лет — ещё в 30 раз. Чтобы сохранить свои объёмы продаж, IBM должна была бы продавать в пять раз больше памяти через пять лет и в 900 раз больше — через десять лет. Аналогично, ожидалось, что стоимость жёстких дисков снизится в десять раз за следующие десять лет. Для поддержания традиционного роста продаж на 15% в год, к 1980 году компании пришлось бы продавать в 40 раз больше дискового пространства и в 3600 раз больше памяти.

В терминах самого компьютера, если бы компания продолжила развитие от 360-й к 370-й и далее к гипотетической System/380, то новые машины были бы основаны на крупномасштабной интеграции и значительно упростились бы в плане сложности и стоимости. Продавать такую машину по текущим ценам было невозможно. Если бы они попытались, другая компания представила бы гораздо более дешёвые системы Вместо этого они могли бы производить гораздо более мощные машины по тем же ценам, но их клиенты уже недостаточно использовали существующие системы. Чтобы предоставить разумный аргумент для покупки новой высокопроизводительной машины, IBM должна была придумать причины, по которым клиентам понадобится эта дополнительная мощность.

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

AFS В 1969 году президент подразделения разработки систем IBM (), занимавшегося созданием крупнейших мейнфреймов компании, Боб Овертон Эванс, обратился к Эриху Блоху из лаборатории IBM в Покипси с просьбой рассмотреть, как компания могла бы использовать более дешевые компоненты для создания машин, которые при этом сохранили бы прибыльность. Блох, в свою очередь, поручил Карлу Конти разработать концепцию таких систем. Увидев термин «future systems», Эванс назвал эту группу «Advanced Future Systems» (AFS, ). Группа собиралась примерно раз в две недели.

Среди множества разработок, изначально изучавшихся в рамках AFS, одна концепция выделялась особенно. В то время появлялись первые системы с виртуальной памятью (, VM), а основополагающий проект Multics развил эту идею, положив ее в основу одноуровневого хранилища. Согласно этой концепции все данные в системе как будто находятся в основной памяти и если данные физически находятся во вторичной памяти, система виртуальной памяти автоматически загружает их в память, когда программа к ним обращается. Вместо того чтобы писать код для чтения и записи данных в файлы, программист просто сообщал операционной системе, какие данные он собирается использовать. Эти данные затем появлялись в памяти программы в виде объектов и могли обрабатываться как любые другие переменные. Система виртуальной памяти обеспечивала синхронизацию данных с хранилищем по мере необходимости.

В то время эта концепция считалась особенно полезной, поскольку появление магнитоэлектронных запоминающих устройств предполагало, что будущие системы не будут иметь отдельной памяти на магнитных сердечниках и жёстких дисках, а всё будет храниться в большом объеме магнитоэлектронной памяти. Физически, системы будут одноуровнемыми хранилищами, так что идея наличия еще одного уровня для «файлов», представляющих отдельное хранилище, не имела смысла. Указатели на одно большое хранилище не только позволяли бы обращаться к любым данным так, как если бы они были локальными, но и устраняли бы необходимость в отдельных интерфейсах программирования приложения (, API) для одних и тех же данных в зависимости от того, были ли они загружены или нет.

HLS Эванс также попросил Джона Макферсона из штаб-квартиры IBM в возглавить другую группу, чтобы рассмотреть, как IBM будет предлагать эти новые разработки в различных своих подразделениях. Группа из двенадцати участников, представляющих три подразделения, подготовила «Отчет о системе более высокого уровня», (, HLS), который был представлен 25 февраля 1970 года. Ключевым компонентом HLS была идея о том, что программирование обходится дороже, чем аппаратное обеспечение. Если бы система могла значительно снизить стоимость разработки, то такую систему можно было бы продавать дороже, поскольку общая стоимость эксплуатации все равно была бы ниже, чем у конкурентов.

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

Несмотря на обширный набор инструкций 360, эти инструкции оставались низкоуровневыми, представляя собой отдельные операции, выполняемые центральным процессором (ЦП), такие как «сложить два числа» или «сравнить это число с нулем». Языки программирования и их связи с операционной системой позвлоляли пользователям вводить программы, используя высокоуровневые понятия, такие как «open file» (открыть файл) или «add these arrays» (сложить эти массивы). Компиляторы реобразовывали эти высокоуровневые абстракции в последовательность инструкций машинного кода.

В HLS инструкции напрямую представляли бы эти задачи более высокого уровня. То есть, в машинном коде существовали бы инструкции для «open file». Если программа вызывала такую инструкцию, не было необходимости преобразовывать ее в код более низкого уровня, машина выполняла бы это внутренне с помощью микрокода или даже прямой аппаратной реализации. Это работало в сочетании с одноуровневым хранилищем. Для реализации HLS каждый бит данных в системе сопровождался дескриптором — записью, содержащей тип данных, их местоположение в памяти, а также точность и размер. Поскольку дескрипторы могли указывать на массивы и структуры записей, это позволяло машинному языку обрабатывать их как атомарные объекты.

Прямое представление этих объектов более высокого уровня в системе сделало бы пользовательские программы значительно меньше и проще. Например, чтобы сложить два массива чисел, хранящихся в файлах, в традиционных языках программирования, обычно пришлось бы открыть оба файла, прочитать по одному элементу из каждого, сложить их, а затем сохранить результат в третьем файле. В подходе HLS достаточно было бы просто открыть файлы и вызвать команду сложения. Операционная система отобразила бы их в памяти, создала бы дескрипторы, указывающие, что оба объекта являются массивами, и тогда инструкция сложения увидела бы, что это массивы, и сложила бы все значения. Присвоение этого значения новому массиву привело бы к его записи обратно в хранилище. Программа, которая могла занимать страницу кода, теперь сократилась до нескольких строк. Более того, поскольку это был естественный язык машины, командная оболочка сама по себе была программируемой таким же образом, и не было бы необходимости «писать программу» для такой простой задачи, как эта. Её можно было бы просто ввести как команду.

В заключение отчета говорится:

Проблемы совместимости