Текст книги "Основы AS/400"

Автор книги: Фрэнк Солтис

сообщить о нарушении

Текущая страница: 25 (всего у книги 41 страниц)

Режим активных тегов

В главе 2 мы говорили о расширениях архитектуры PowerPC. Одно из таких расширений – режим активных тегов. Когда процессор PowerPC работает в данном режиме, доступны дополнительные команды, которых нет в режиме неактивных тегов. Всего для AS/400 было добавлено 25 команд, доступных только в режиме активных тегов. Сюда входят команды множественной загрузки и сохранения четверных слов в регистрах, а также команды, обратные им. Есть также команды десятичной арифметики, системные функции вызова/возврата и команды выделения для проверки значений разрядов в управляющих регистрах. Шесть новых команд поддерживают теги.

Некоторые из этих специальных теговых команд используются для установки или проверки значений разрядов тега. Одна из них, команда «Сохранить четверное слово» («stq»), сохраняет в памяти 16 байтов данных из двух 64-разрядных регистров и включает два разряда тега. Другая —«Загрузить четверное слово» («lq»), загружает 16 байтов памяти в два 64-разрядных регистра и устанавливает разряд в регистре управления в 1, если оба теговых разряда в считанных словах равны 1 (в противном случае этот разряд устанавливается в 0). Еще одна команда позволяет считывать теги из памяти в специальный регистр процессора. Использование этой команды будет рассмотрено в следующем разделе.

Теговые команды: используются только в SLIC; они не генерируются транслятором для программ MI. Это означает, что любое сохранение в памяти, сгенерированное для программы MI, всегда использует стандартные команды и отключает разряды тега. Когда в процессе разрешения создается указатель, SLIC строит его в двух 64-разрядных регистрах и использует команду «stq» для включения теговых регистров в памяти. При всякой попытке использовать указатель программой MI, SLIC загружает его содержимое командой «lq» в регистры и затем проверяет, установлены ли разряды: тега. Если разряды тега сброшены, значит, кто-то изменил указатель, и он теперь неверен.

Разряды тега AS/400 не предотвращают изменения указателей, а лишь определяют, производились ли эти изменения. Такой подход отличается от большинства схем защиты памяти. Обычно, защита памяти не допускает изменений, и такая защита на уровне страниц в AS/400 имеется. Однако указатели распознают лишь уже произошедшие модификации, что по сравнению с ранними версиями системы сокращает объем аппаратуры, но по-прежнему обеспечивает нужный уровень защиты.

Указатели нельзя подделать. Теги гарантируют, что указатель создан ОС (SLIC), и что он не изменялся чем-либо, кроме SLIC. Недобросовестный пользователь, попытавшись создать, скопировать или изменить указатель, не сможет включить разряды тега и получит в результате бесполезные 16 байт. Именно поэтому AS/400 всегда работает в режиме активных тегов, несмотря на то, что процессоры PowerPC, используемые в ней, могут действовать и в режиме неактивных тегов.

Указатели и теги на диске

Разработчики System/38 столкнулись с и другой проблемой. Допустим, потребуется переместить страницу из памяти на диск. В памяти есть дополнительные разряды для ЕСС и тегов, а на диске нет. Там используется другая форма кода коррекции ошибок, называемая циклическим избыточным контролем CRC (cyclic redundancy check), который не добавляет дополнительных разрядов к каждому слову памяти. Значит, нужен способ сохранения разрядов тега вместе с указателями при перемещении страницы, содержащей указатели, на диск. Короче говоря, нужно найти дополнительное место на диске.

Магнитный диск представляет собой набор плоскостей, имеющих по две поверхности для записи. Поверхность каждого диска разделена на концентрические окружности, называемые дорожками. В свою очередь, дорожки разделены на сектора, которые и содержат информацию. Размер сектора для System/38 и AS/400 равен 520 байтам. Каждый сектор содержит 8-байтовый заголовок сектора и область данных в 512 байт. Размер сектора был выбран так, чтобы 512-байтовая страница System/38 умещалась в него.

В System/38 было определено несколько специальных команд IMPI для работы с тегами. Одна из таких команд– «Извлечь теги» – использовалась для сбора тегов со страницы памяти. При записи страницы на диск, теги также записывались на диск. Другая команда IMPI – « Вставить теги»– применялась для помещения тегов обратно в память после считывания страницы с диска.

Многие ISV и пользователи, знавшие о разрядах тега System/38, считали, что они хранятся на диске в 8-байтовых заголовках секторов. Но это не так. Информация на самой странице сохранялась в 512-байтной области данных сектора. Заголовок сектора содержал информацию о странице, но наиболее важной его задачей было хранение виртуального адреса страницы. Этот адрес нужен был для восстановления. Даже в случае потери таблицы в памяти, связывавшей виртуальные адреса с местами на диске, она могла быть восстановлена: достаточно считать заголовки каждого сектора и определить, с каким виртуальным адресом этот сектор связан. Так что большая часть пространства в заголовке сектора была занята виртуальным адресом страницы, места для тегов не оставалось.

Это подтверждает простой расчет. Одна страница может содержать 32 указателя (16 байтов Г32 = 512), что означает 32 бита тегов на страницу. Виртуальный адрес в System/38 занимал 48 разрядов, но для идентификации страницы использовались не все из них. Младшие 9 разрядов виртуального адреса задавали байт на 512-байтной странице (29 = 512). Следовательно, для уникальной идентификации страницы нужно хранить только 39 старших разрядов виртуального адреса (48 – 9 =39). Однако даже без разрядов состояния потребовался бы минимум 71 разряд для хранения виртуального адреса страницы и всех битов тега (39 +32 =71), в заголовке же сектора было только 64 разряда. Хранить биты тега в заголовках секторов оказалось невозможно.

Разработчики System/38, проявив недюжинную смекалку, нашли для тегов место внутри страницы. Дело в том, что некоторое пространство в указателе не используется. Если на странице есть хотя бы один указатель, то есть и некоторое неиспользуемое пространство, в котором можно хранить биты тега. Если указателей на странице нет, то все биты тега для нее равны 0, поэтому и хранить их незачем. Заголовок сектора в System/38 содержал информацию о том, есть ли на странице теги, и если есть, то где именно.

До появления RISC-процессоров мы продолжали использовать на AS/400 и размер страницы, равный 512 байтам, и только что описанный метод хранения битов тега. Но уже несколько лет нас мучило желание увеличить размер страницы.

Размер страницы в 512 байт был выбран для System/38 по причине ограниченности размеров основной памяти[ 65 ]65
  Перед объявлением System/38 в Рочестер приехал «эксперт» из IBM, который заявил, что планируемые нами размеры памяти слишком велики. Несмотря на протесты тех из нас, кто хорошо разбирался в теме дискуссии, размер памяти пришлось сократить. В результате оригинальная Model 5 работала плохо, так как была ограничена 2 мегабайтами памяти. А ведь при увеличении размера памяти производительность росла. Когда тот же самый «эксперт» вернулся, чтобы помочь нам с AS/400, мы вышвырнули его вон.


[Закрыть]. Но для увеличенной памяти AS/400 512-байтовая страница была слишком мала, страниц получалось слишком много, и таблицы страниц достигали гигантских размеров. Кроме того, уже многие годы мы «упаковывали» маленькие страницы в «логические» страницы большего размера для сокращения объема дисковых операций. Для новых процессоров было решено увеличить размер страницы до 4 КБ (4 096 байтов).

В новых моделях был сохранен размер сектора на диске в 520 байт. Четырехкило-байтовая страница теперь хранится в восьми последовательных секторах. При наличии восьми 8-байтовых заголовков на каждой странице в 4 КБ больше чем достаточно места для хранения 256 теговых битов.

Для извлечения тегов из памяти к архитектуре процессора PowerPC был добавлен специальный регистр тегов. Когда процессор выполняет специальную теговую команду, «Множественная загрузка двойных слов» («lmd»), в 16 регистров может быть считано из памяти до 16 двойных слов (восемь четверных слов). При выполнении команды в регистре тега сохраняется восемь теговых регистров четверных слов памяти. Обратите внимание, что в регистре тега сохраняются 8 логических битов тега, а не 16 физических, как в памяти. Вспомним, что четверное слово это два 64-разрядных (8-байтовых) слова памяти; следовательно, в четверном слове два физических бита тега, так что в восьми четверных словах – 16 физических битов тега. С помощью команды «lmd» биты тегов страницы могут быть собраны для последующей записи на диске вместе с данными. Эта команда также доступна только в режиме активных тегов.

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

Указатель используется в 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-разрядного адреса появилось достаточно места. Проблемы возникли на аппаратном уровне. Чем больше разрядов в адресе, тем больше размер регистров процессора. Больший размер регистров требовал большего числа цепей и повышал стоимость аппаратных средств.

Техническим менеджером System/38 был Рей Клотц, не видевший надобности в таком большом адресе. Его многократно пытались уговорить, но Рей так и не поддался на уверения, что 64-разрядного адреса хватит навечно. В середине 70-х годов подразделение IBM по мэйнфреймам собиралось объявить о новом большом адресе для System/370, получившем название расширенной адресации (XA). С применением ХА адрес System/370 должен был вырасти с 24 до 31 разряда. Рей обвинял нас в желании непременно превзойти System/370 и утешал тем, что 32 разряда все равно больше чем 31. «Вы побьете их и одним разрядом, а больше и не надо», – как бы говорил он. Мы, в свою очередь, утверждали, что 32-разрядный адрес не будет работать с одноуровневой памятью System/38, и что нужны 64 разряда. Когда стало очевидным, что спор зашел в тупик, мы поступили так, как будто торговались о цене подержанной машины: поделили пополам разницу между 32 и 64. Таким образом, получился 48-разрядный адрес.

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

Оригинальная аппаратура процессора 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-разрядное смещение (ведь 224 = 16 МБ).

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

Подобные ошибки переполнения могут легко отслеживаться аппаратно, для чего используется механизм прерываний[ 66 ]66
  Прерывания часто называют также исключительными ситуациями. – Прим. консультанта.


[Закрыть]. Прерывания будут рассмотрены в главе 9, но одно из них мы обсудим прямо сейчас: переполнение эффективного адреса (ЕАО).

Разберем ситуацию, возникавшую в 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

Первоначально заголовок сегмента, описанный в главе 5, содержал поле с 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 стали выходить за границы адресов[ 67 ]67
  Так как я сам и был тем человеком, кто провел эти вычисления и решил, что проблем не возникнет, то и все гневные отклики на эту ошибку достались мне. Должен признаться, что это был сильный стимул заняться переводом AS/400 на 64-разрядный аппаратный адрес.


[Закрыть].

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

Ситуация усугублялась тем, что компонент управления основной памятью в оригинальном VMC разделял полное 48-разрядное виртуальное адресное пространство на квадранты. Старшие два разряда адреса задавали квадрант в зависимости от назначения последнего. Один квадрант был зарезервирован для адресов постоянных объектов, так что у всех постоянных адресов два старших разряда были одинаковы. Другой квадрант был выделен адресам для временных объектов, третий – для адресов временных объектов групп доступа[ 68 ]68
  Группа доступа, упомянутая в главе 5, представляет собой системный объект, позволяющий объединять несколько временных объектов и работать с ними как с целым. Возможно, читателю знакома группа доступа процесса PAG (process access group).


[Закрыть]. Так как постоянные объекты не могут входить в группу доступа, то четвертый квадрант не использовался. Такое решение было принято в предположении, что 48-разрядное адресное пространство настолько велико, что на одну его четверть можно безболезненно «закрыть глаза». Из 256 ТБ (248 байтов) виртуальной памяти, которыми мы так любили похваляться, 64 ТБ никогда не использовались в System/38 и первых моделях AS/400.

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


[Закрыть]. Но причин происшедшего это паллиативное решение не устраняло.

8первые версии ОС для 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 («С» – обозначает коммерческий), имел 96-разрядный адрес. У нас появилось место для такого большого адреса в указателях, и мы не стали стесняться. Когда в 1991 году было принято решение использовать архитектуру PowerPC, размер адреса был сокращен до 64 разрядов.