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