Одноуровневая память

Внутри указателя

Указатель используется в AS/400 для доступа к объектам. В этом разделе мы сосредоточимся исключительно на формате разрешенного указателя. У разрешенного указателя две функции: он описывает объект и полномочия пользователя на этот объект; а также задает адрес объекта в одноуровневом хранилище. Иначе говоря, 16-байтовый указатель разделен на две 8-байтовые части: первая — описание объекта, а вторая — виртуальные адрес.

В первой части разрешенного указателя находятся биты состояния, которые, кроме всего прочего, задают, что это за указатель: системный, пространственный, данных, команд или процедуры. В этой же части содержится информация об объекте и данных, доступных через этот указатель. Например, системный указатель задает для объекта тип системного объекта MI и подтип, определенный OS/400; а указатель данных описывает тип данных. Прочая информация первой части указателя касается полномочий пользователей на операции с объектом. Как отмечалось ранее, поле полномочий используется, только если указателем оперирует сама ОС в системном состоянии. В указателях, созданных пользовательскими программами в пользовательском режиме, поле полномочий не заполнено.

Информация первой части указателя не занимает все 8, а лишь 4 байта. Это означает, что 4 байта указателя не используются. Они зарезервированы для будущих расширений адреса. Дополнительные 32 разряда вместе с 64 адресными разрядами указателя дают возможность расширить адрес AS/400 до 96 разрядов (12 байтов) без изменений каких-либо программ поверх MI. Если потребуется еще большее пространство, то можно будет удалить из указателя информацию типа и полномочий, и увеличить длину адреса сверх 96 разрядов.

Вторая часть разрешенного указателя содержит 64-разрядный адрес. Так было всегда, и многие годы это вызывало путаницу: каков все же размер виртуального адреса System/38 и AS/400, 48 или 64-разрядный? С появлением новых RISC-моделей AS/400 путаница прекратилась: теперь адрес 64-разрядный. А в System/38 и ранних моделях AS/400 он был и таким, и таким. В MI адрес всегда был 64-разрядным, а аппаратура работала с 48разрядным адресом. Как они уживались вместе — тема следующего раздела.

Сказка о двух размерах адреса

Появление новых RISC-моделей с полностью 64-разрядными аппаратными адресами устранило большинство проблем, связанных со смешением 64 и 48-разрядной адресации в предыдущих моделях. Чтобы понять, почему 64разрядный аппаратный адрес так важен, рассмотрим первоначальную 48-разрядную реализацию.

48-разрядный адрес появился в результате компромисса. Проектировщики ОС System/38 планировали адрес размером в 64 бита. После того, как размер указателя был определен в 16 байтов, для 64разрядного адреса появилось достаточно места. Проблемы возникли на аппаратном уровне. Чем больше разрядов в адресе, тем больше размер регистров процессора. Больший размер регистров требовал большего числа цепей и повышал стоимость аппаратных средств.

Для поддержки сегментированной памяти 48разрядный адрес разделяется надвое. Старшие разряды задают сегмент, а младшие, называемые смещением — байт внутри сегмента. Мы решили использовать для задания сегмента старшие 32 разряда, а для смещения — младшие 16, назвав все это адресом 32/16. 16 разрядов смещения означали размер сегмента в 64 КБ (2¹⁶ =64 KБ).

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

Программисты, отвечавшие за ПО ОС ниже MI (первоначально VMC) не были согласны с такой адресацией (32/16), так как считали, что размер сегмента в 64 КБ слишком мал. Первоначально они предполагали создать сегментные группы, каждая из которых содержала бы один или несколько таких 64-килобайтных сегментов, но, в конце концов, решили, что сегментная группа всегда должна состоять из 256 сегментов. При выделении нового сегмента как части вновь создаваемого объекта его размер всегда будет равен 16 МБ (256 ґ 64 КБ = 16 МБ). С этого момента мы говорили о 64-килобайтных и 16-мегабайтных сегментах, впрочем, называя иногда вторые сегментной группой. Этот разнобой в терминологии продолжался до появления процессоров PowerPC и SLIC. Если Вы возьмете в руки калькулятор или таблицу степеней двойки, то поймете, почему программисты VMC, имевшие дело с 16-мегабайтными сегментами, рассматривали 48-разрядный адрес как имеющий 24-разрядный идентификатор сегмента и 24-разрядное смещение (ведь 2²⁴ = 16 МБ).

Представление адреса 24/24, использовавшееся VMC, не совпадало с представлением 32/16, использовавшимся аппаратурой. Возник вопрос: каким способом обрабатывать переполненное поле смещения адреса? Рассматривая объекты, мы говорили, что они состоят из одного или нескольких несмежных сегментов, и что ни один сегмент не может содержать части более чем одного объекта. Очевидно, что смещение адреса за границу сегмента в следующий сегмент нежелательно, так как последний может относиться к другому объекту. Следовательно, такое смещение, например, адреса в пространственном указателе за пределы ассоциированного пространства объекта, надо предотвратить. Определяется такое переполнение адреса следующим способом: после каждого увеличения адреса проверяется, не было ли переноса из разрядов смещения в разряды идентификатора сегмента. Такой перенос и означает попытку обратиться к следующему сегменту.

Подобные ошибки переполнения могут легко отслеживаться аппаратно, для чего используется механизм прерываний^{6Прерывания часто называют также исключительными ситуациями. — Прим. консультанта.}. Прерывания будут рассмотрены в "Управление процессами" , но одно из них мы обсудим прямо сейчас: переполнение эффективного адреса (ЕАО).

Разберем ситуацию, возникавшую в System/38 при переполнении 16-разрядного смещения. В этом случае аппаратура не увеличивала 32-разрядную сегментную часть адреса. Вместо этого об исключительной ситуации сообщалось VMC, который в каждом конкретном случае заново оценивал ситуацию. VMC рассматривал сегменты, как имеющие длину 16 МБ и состоящие из 256 аппаратных сегментов меньшего размера, и поэтому переполнение 64-килобайтного сегмента в середине 16-мегабайтного сегмента переполнением не считал. С его точки зрения — представления адреса 24/24 — переполнением считался только перенос из младших 24 разрядов в старшие 24. При каждом прерывании по ЕАО VMC увеличивал 32-разрядный аппаратный идентификатор сегмента, проверял, нет ли переноса в старшие 24 разряда, и если обнаруживал, что все в порядке, управление возвращалось аппаратуре. Таким образом, мы постоянно сталкивались с несовпадением схем 32/16 и 24/24.

Когда с течением времени ширина тракта данных процессора выросла с первоначальных 16 до 32, а затем до 48 разрядов, разделение регистров сегмента и смещения в аппаратуре стали менее важны. В IMPIмоделях AS/400 были добавлены команды для поддержки адреса 24/24, что исключило необходимость программной обработки переполнений. Однако в целях совместимости с оригинальным VMC, представление 32/16 было в IMPI сохранено.

Эта проблема с адресами была не единственной в оригинальном VMC. Он должен был поддерживать 64-разрядный адрес в указателе MI на аппаратуре с 48-разрядным адресом. Можно было бы попытаться рассматривать 64-разрядные адреса как виртуальные адреса большего размера, которые какимто образом отображаются в меньшие 48-разрядные виртуальные адреса, но такое решение было отвергнуто. Вместо этого, старшие 16 разрядов 64-разрядного адреса стали рассматриваться как отдельное значение. Мы назвали это 16-разрядное поле расширением идентификатора сегмента, обозначив его номером IPL. При всякой перезагрузке системы номер IPL увеличивался на единицу, что каждый раз давало новое 48-разрядное адресное пространство. На рисунке 8.2 показаны поля, составляющие 64-разрядный адрес в указателе MI.

Рис. 8.2. Оригинальный формат адреса указателя MI

Первоначально заголовок сегмента, описанный в "Объекты" , содержал поле с 16-разрядным расширением идентификатора этого сегмента. Когда программа MI пыталась использовать указатель на System/38 и на ранних моделях AS/400, для проверки битов тега и загрузки 48-разрядного адреса в процессорный регистр, использовалась специальная команда IMPI под названием "Загрузить и проверить теги" ("lvt"). Команда "lvt" аналогична "lq" на RISC-процессорах, но у первой была дополнительная задача. Она должна была сравнить старшие 16 разрядов адреса в указателе с полем расширения идентификатора в заголовке сегмента и гарантировать их совпадение с адресом сегмента. После первого обращения для доступа к сегменту использовался только 48-разрядный адрес.

Как уже говорилось, всякий раз при увеличении номера IPL мы получали новое адресное пространство для временных объектов. Временные объекты разрушаются при выполнении IPL, в отличие от постоянных, продолжающих существовать и после перезагрузки. Так как аппаратура использовала только 48 разрядов, один и тот же 48-разрядный адрес не мог быть задействован для постоянных объектов повторно, за исключением случая, когда постоянный объект по этому адресу был явно удален во время предыдущего сеанса работы ОС. Тогда от него оставались только заголовки, что обнаруживалось при первом использовании полного 64разрядного адреса, начальные 16 разрядов которого содержат номер IPL. Так как номера IPL различались, то при повторном использовании 48разрядного адреса конфликтов не возникало. Еще раз подчеркну, что заголовки сохраняются только при разрушении постоянных объектов — при разрушении временного объекта не остается ничего.

Переполнение адреса

Так как мы решили не использовать на System/38 48-разрядный адрес повторно до следующей перезагрузки, встал вопрос о том, что однажды все доступные адреса могут быть исчерпаны. В поисках ответа на него, мы провели некоторые интересные подсчеты. В соответствии с их результатами, если выполнять одну IPL в день 365 дней в году, то повторное использование номера IPL потребуется через 180 лет. Итак, опасности, что расширения идентификаторов сегментов будут повторяться, не существовало. Зная проектируемую производительность будущих процессоров, мы могли вычислить максимальное число 64-килобайтных сегментов, которое будет сгенерировано в интервале между ежедневными IPL. Эти расчеты также показали, что проблемы нет. И все же прогноз оказался неверным — некоторые большие AS/400 стали выходить за границы адресов^{7Так как я сам и был тем человеком, кто провел эти вычисления и решил, что проблем не возникнет, то и все гневные отклики на эту ошибку достались мне. Должен признаться, что это был сильный стимул заняться переводом AS/400 на 64-разрядный аппаратный адрес.}.

Что же случилось? Вопервых, одна IPL в день — это неплохое допущение для ранних System/38, но после того как многие заказчики стали использовать свои компьютеры 24 часа в сутки, времени на перезагрузку не осталось. Кроме того, наши системы сильно увеличились в размерах, и время IPL стало слишком большим. С тех пор мы внесли существенные изменения в AS/400, что позволило сократить время IPL до нескольких минут. Но даже при этом одна IPL в день была неверным допущением. Второй ошибкой в вычислениях было предположение о 64-килобайтном сегменте. Используя представление адреса 24/24 оригинальный VMC всегда создавал 16-мегабайтные сегменты.

Ситуация усугублялась тем, что компонент управления основной памятью в оригинальном VMC разделял полное 48разрядное виртуальное адресное пространство на квадранты. Старшие два разряда адреса задавали квадрант в зависимости от назначения последнего. Один квадрант был зарезервирован для адресов постоянных объектов, так что у всех постоянных адресов два старших разряда были одинаковы. Другой квадрант был выделен адресам для временных объектов, третий — для адресов временных объектов групп доступа^{8Группа доступа, упомянутая в "Объекты" , представляет собой системный объект, позволяющий объединять несколько временных объектов и работать с ними как с целым. Возможно, читателю знакома группа доступа процесса PAG (process access group).}. Так как постоянные объекты не могут входить в группу доступа, то четвертый квадрант не использовался. Такое решение было принято в предположении, что 48-разрядное адресное пространство настолько велико, что на одну его четверть можно безболезненно "закрыть глаза". Из 256 ТБ (2⁴⁸ байтов) виртуальной памяти, которыми мы так любили похваляться, 64 ТБ никогда не использовались в System/38 и первых моделях AS/400.

Проблема, возникшая в некоторых больших системах AS/400, состояла в выходе за пределы диапазона временных адресов. Эта проблема получила название переполнения идентификатора сегмента, так как все идентификаторы сегментов, доступные в интервалах между перезагрузками, были использованы. При разделении адресного пространства на квадранты на каждую IPL приходилось лишь по 4 миллиона 16-мегабайтных временных сегментов. Вследствие этого, большие системы с приложениями, использовавшими много временных объектов, выходили за пределы диапазона временных идентификаторов сегментов, если не перегружались по несколько дней. С точки зрения пользователя, положение можно было исправить довольно просто — перезагрузить систему^{9Перезагрузить систему действительно очень просто. Гораздо труднее было объяснить заказчику почему он должен это делать каждый месяц. Особенно если система установлена, например, в финансовой компании. — Прим. консультанта.}. Но причин происшедшего это паллиативное решение не устраняло.

В первые версии ОС для AS/400 были внесены изменения, позволявшие уменьшить проблему переполнения адресов. Компоненты стали использовать 64-килобайтные сегменты вместо 16-мегабайтных, везде, где было возможно. Был также задействован ранее выброшенный квадрант адресного пространства. Разумеется, эти изменения не решили проблему, но они позволили нам продержаться до появления новых RISC-процессоров.

Проблема касалась и постоянных адресов. Их максимальное число ограничено объемом дискового пространства на подключенных к системе устройствах, поскольку даже удаленные объекты продолжают занимать некоторое место на диске. Мы ограничили общий объем дискового пространства, которое могло быть подключено к AS/400, чтобы пользователь не мог исчерпать постоянные адреса. Ведь выход за пределы постоянных адресов нельзя исправить с помощью IPL, здесь потребуется полная переустановка системы, что, разумеется, совершенно неприемлемо.

Я потратил несколько разделов на описание структуры адресации System/38 и первых моделей AS/400, чтобы показать причины, заставившие IBM перейти на RISC-процессоры. Еще до выпуска первой AS/400 мы знали, что 48-разрядный адрес ограничивает будущий рост системы. По мере увеличения размеров и скорости работы, системы начинали использовать все больше временных адресов. Заказчики же хотели подключать все больший объем дисков.

Нам потребовалось некоторое время, чтобы убедить руководство в невозможности использовать 48-разрядный адрес в будущих системах. В Рочестере всегда была популярна старая поговорка: "Не надо чинить то, что не ломается". И вот, наконец, мы убедили менеджеров, что то, что сломалось, сломалось безвозвратно. Хорошо еще то, что поломка случилась внутри системы. Независимость AS/400 от технологии защитила наших заказчиков.

Если в вычислительной архитектуре изменяются адреса, то приходится менять и все остальное. Мы восприняли случившееся как шанс избавиться от IMPI и перейти на RISC. Наш первый RISC-процессор, который мы начали разрабатывать в 1990 году и назвали С-RISC ("C" — обозначает коммерческий), имел 96-разрядный адрес. У нас появилось место для такого большого адреса в указателях, и мы не стали стесняться. Когда в 1991 году было принято решение использовать архитектуру PowerPC, размер адреса был сокращен до 64 разрядов.