Машинно-зависимые свойства загрузчиков

Абсолютный загрузчик, описанный в разд. 2.1, конечно, весьма прост и эффективен, однако данная схема имеет ряд потенциальных недостатков. Одним из наиболее очевидных является то, что от программиста требуется определять фактический адрес начала загрузки программы во время ее ассемблирования. Если мы рассматриваем очень простую ЭВМ с небольшим объемом оперативной памяти (такую, как стандартная модель УУМ), то это не создает особых проблем. В этом случае места достаточно только для выполнения одной программы, и поэтому начальный адрес загрузки известен заранее. Для более совершенных машин, обеспечивающих работу с большим объемом оперативной памяти (подобных УУМ/ДС), ситуация не столь проста. Очень часто желательно одновременно выполнять несколько независимых программ, совместно использующих оперативную память и другие ресурсы. Это означает, что мы не знаем заранее, куда будет загружена программа. Поэтому для того, чтобы обеспечить эффективное разделение ресурсов машины, требуется создавать перемещаемые, а не абсолютные программы.

Абсолютные программы неудобны также и для использования в библиотеках стандартных подпрограмм. Количество подпрограмм, содержащееся в большинстве таких библиотек (например, пакеты для научных или математических расчетов), намного больше, чем требуется для каждой отдельно взятой программы. Поэтому для того, чтобы эффективно использовать оперативную память, необходимо иметь возможность выбирать только те подпрограммы, которые действительно нужны. Сделать это, если все подпрограммы должны загружаться с заранее назначенных адресов, весьма непросто.

В этом разделе мы рассмотрим более сложный загрузчик. Такой загрузчик вполне подходит для УУМ/ДС и является типичным для большинства современных ЭВМ. Наряду с простой функцией размещения программы в оперативной памяти, описанной в предыдущем разделе, данный загрузчик выполняет также перемещение и связывание программ. Одним из вопросов, которого мы коснемся в данном разделе, будет вопрос о влиянии структуры машины на решения, применяемые при проектировании загрузчика.

Необходимость выполнения перемещения программ косвенно связана с переходом на более мощные и большие ЭВМ. Конкретный способ, используемый загрузчиком для реализации перемещения, зависит от структуры ЭВМ. Эта зависимость будет рассмотрена в разд. 3.2.1. Мы обсудим различные технические приемы, которые могут быть использованы для перемещения программ, и укажем область их применения.

В разд. 3.2.2 разбирается процесс связывания программ с точки зрения загрузчика. Функция связывания по сравнению с перемещением обладает меньшей степенью машинной зависимости. Однако на практике для реализации обеих этих функций очень часто используется один и тот же механизм. Кроме того, процесс связывания обычно требует перемещения некоторых подпрограмм. (см. приведенный выше пример использования библиотечных подпрограмм.) Поэтому мы будем рассматривать эти два процесса вместе.

В разд. 3.2.3 обсуждаются структуры данных и алгоритмы, используемые в типичном связывающем (и перемещающем) загрузчике. Рассматриваемые здесь алгоритмы будут использованы в последующих разделах в качестве отправной точки при изучении более сложных возможностей, предоставляемых загрузчиком.

Перемещение

Загрузчики, обеспечивающие перемещение программ, называются перемещающими загрузчиками (relocating loaders) или относительными загрузчиками (relative loaders). С концепцией перемещения программ мы познакомились в разд. 2.2.2. Вам, прежде чем продолжить чтение, следует бегло повторить материал этого раздела. В данном разделе мы обсудим два способа, в которых информация о перемещении задается как составная часть объектной программы.

Первый из рассматриваемых способов в основном аналогичен тому, что мы обсуждали в гл. 2. Для описания каждого фрагмента объектного кода, требующего изменения при перемещении, используется специальная запись-модификатор. (Ее формат описан в разд. 2.3.5.) На рис. 3.3 показана программа для УУМ/ДС, которую мы будем использовать для иллюстрации первого способа задания информации о перемещении. Это та же самая программа, что и на рис. 2.6.

 

Строка Адрес Исходное предложение Объектный код

5 0000 COPY START 0

10 0000 FIRST STL RETADR 17202D

12 0003 LDB #LENGTH 69202D

13 BASE LENGTH

15 0006 CLOOP +JSUB RDREC 4B101036

20 000A LDA LENGTH 032026

25 000D COMP #0 290000

30 0010 JEQ ENDFIL 332007

35 0013 +JSUB WRREC 4B10105D

40 0017 J CLOOP 3F2FEC

45 001A ENDFIL LDA EOF 032010

50 001D STA BUFFER 0F2016

55 0020 LDA #3 010003

60 0023 STA LENGTH 0F200D

65 0026 +JSUB WRREC 4B10105D

70 002A J @RETADR 3E2003

80 002D EOF BYTE C"EOF" 454F46

95 0030 RETADR RESW 1

100 0033 LENGTH RESW 1

105 0036 BUFFER RESB 4096

110 *

115 * ПОДПРОГРАММА ВВОДА ЗАПИСИ НА БУФЕР

120 *

125 1036 RDREC CLEAR X B410

130 1038 CLEAR A B400

132 103A CLEAR S B440

133 103C +LDT #4096 75101000

135 1040 RLOOP TD INPUT E32019

140 1043 JEQ RLOOP 332FFA

145 1046 RD INPUT DB2013

150 1049 COMPR A,S A004

155 104B JEQ EXIT 332008

160 104E STCH BUFFER,X 57C003

165 1051 TIXR T B850

170 1053 JLT RLOOP 3B2FEA

175 1056 EXIT STX LENGTH 134000

180 1059 RSUB 4F0000

185 105C INPUT BYTE X"F1" F1

195 *

200 * ПОДПРОГРАММА ВЫВОДА ЗАПИСИ ИЗ БУФЕРА

205 *

210 105D WRREC CLEAR X B410

212 105F LDT LENGTH 774000

215 1062 WLOOP TD OUTPUT E32011

220 1065 JEQ WLOOP 332FFA

225 1068 LDCH BUFFER,X 53C003

230 106B WD OUTPUT DF2008

235 106E TIXR T B850

240 1070 JLT WLOOP 3B2FEF

245 1073 RSUB 4F0000

250 1076 OUTPUT BYTE X"05" 05

255 END FIRST

 

Рис.3.3 Пример программы для УУМ/ДС (с рис.2.6).

 

Здесь мы ее воспроизводим исключительно для удобства. Большинство команд данной программы использует относительную или непосредственную адресацию. Единственной частью объектной программы, содержащей фактические адреса, являются команды, в которых используется расширенный командный формат (строки 15, 35 и 65). Поэтому при перемещении программы изменение значений потребуется только для этих величин.

На рис. 3.4 показана объектная программа, соответствующая исходному тексту на рис. 3.3. Обратите внимание, что для каждого значения, требующего изменения при перемещении, имеется отдельная запись-модификатор (в данном случае это три ранее упомянутые команды). Каждая запись-модификатор определяет начальный адрес и длину поля, значение которого необходимо изменить, а также тип требуемой модификации.

 

H_COPY _000000_001077 T_000000_1D_17202D_69202D_4B101036_032026_290000_332007_4B10105D_3F2FEC_032010 T_00001D_13_0F2016_010003_0F200D_4B10105D_3E2003_454E46 T_001036_1D_B410_B400_B440_75101000_E32019_332FFA_DB2013_A004_332008_57C003_B850 T_001053_1D_3B2FEA_134000_4F0000_F1_B410_774000_E32011_332FFA_53CO03_DF2008_B850 T_001070_07_3B2F3F_4F0000_05

M_000007_05+COPY

M_000014_05+COPY

M_000027_05+COPY

E_000000

 

Рис. 3.4. Объектная программа, в которой перемещение задается с помощью записей-модификаторов.

 

В данном примере все модификации заключаются в прибавлении значения метки COPY, представляющей собой начальный адрес программы. Алгоритм, используемый загрузчиком для выполнения данной операции, описывается в разд. 3.2.3. Дополнительные примеры определяемого подобным образом перемещения будут приведены в следующем разделе при изучении взаимосвязи между перемещением и связыванием.

Записи-модификаторы являются удобным средством для задания информации о перемещении программы. Однако данная схема годится не для всех машин. Рассмотрим, например, программу, приведенную на рис.3.5. Это перемещаемая программа, написанная для стандартной модели УУМ. Ее важным отличием от программы, изображенной на рис. 3.3, является то, что стандартная модель УУМ не имеет относительной адресации. В данной программе адреса всех команд, за исключением RSUB, должны модифицироваться при перемещении. Поэтому для задания информации о перемещении необходимо иметь 31 запись-модификатор, что потребует более чем двукратного увеличения объема памяти, занимаемой объектной программой, по сравнению с программой, показанной на рис. 3.4.

 

Строка Адрес Исходное предложение Объектный код

5 0000 COPY START 0

10 0000 FIRST STL RETADR 140033

15 0003 CLOOP JSUB RDREC 481039

20 0006 LDA LENGTH 000036

25 0009 COMP ZERO 280030

30 000C JEQ ENDFIL 300015

35 000F JSUB WRREC 481061

40 0012 J CLOOP 3С0003

45 0015 ENDFIL LDA EOF 00002А

50 0018 STA BUFFER 0С0039

55 001B LDA THREE 00002D

60 001E STA LENGTH 0С0036

65 0021 JSUB WRREC 481061

70 0024 LDL RETADR 080033

75 0027 RSUB 4С0000

80 002A EOF BYTE C"EOF" 454F46

85 002D THREE WORD 3 000003

90 0030 ZERO WORD 0 000000

95 0033 RETADR RESW 1

100 0036 LENGTH RESW 1

105 0039 BUFFER RESB 4096

110 *

115 * ПОДПРОГРАММА ВВОДА ЗАПИСИ НА БУФЕР

120 *

125 1039 RDREC LDX ZERO 040030

130 103C LDA ZERO 000030

135 103F RLOOP TD INPUT E0105D

140 1042 JEQ RLOOP 30103F

145 1045 RD INPUT D8105D

150 1048 COMP ZERO 280030

155 104B JEQ EXIT 301057

160 104E STCH BUFFER,X 548039

165 1051 TIX MAXLEN 2C105E

170 1054 JLT RLOOP 38103F

175 1057 EXIT STX LENGTH 100036

180 105A RSUB 4C0000

185 105D INPUT BYTE X"F1" F1

190 105E MAXLEN WORD 4096 001000

195 *

200 * ПОДПРОГРАММА ВЫВОДА ЗАПИСИ ИЗ БУФЕРА

205 *

210 1061 WRREC LDX ZERO 040030

215 1064 WLOOP TD OUTPUT E01079

220 1067 JEQ WLOOP 301064

225 106A LDCH BUFFER,X 508039

230 106D WD OUTPUT DC1079

235 1070 TIX LENGTH 2C0036

240 1073 JLT WLOOP 381064

245 1076 RSUB 4C0000

250 1079 OUTPUT BYTE X"05" 05

255 END FIRST

 

Рис.3.5. Перемещаемая программа для стандартной модели УУМ.

 

На машинах, где преимущественно используются прямая адресация и фиксированный командный формат, очень часто более эффективным оказывается другой способ задания информации о перемещении. На рис. 3.6 показано, как этот способ может быть применен к нашему примеру. В данном случае записи-модификаторы не используются. Формат записей тела программы то же, что и ранее, за исключением того, что теперь с каждым словом объектного кода связан разряд перемещения. Поскольку все команды УУМ занимают одно слово, это означает, что для каждой потенциальной команды имеется один разряд перемещения. Эти разряды собираются вместе и образуют маску, которая записывается после указателя длины каждой записи тела программы. На рис. 3.6 эта маска (в символьном виде) показана в виде трех шестнадцатеричных цифр (на рисунке они подчеркнуты).

Если разряд перемещения установлен в 1, то при перемещении программы начальный адрес программы добавляется к слову, соответствующему этому разряду. Значение разряда перемещения, равное О, показывает, что никаких преобразований при перемещении делать не надо. Если запись тела программы содержит менее 12 слов объектного кода, то разряды, соответствующие неиспользуемым словам, устанавливаются в 0.

 

H_COPY _000000_00107A T_000000_1E_ FFC _140033_481039_000036_280030_300015_481061_3C0003_00002A_0C0039_00002D T_00001E_15_ E00 _0C0036_481061_080033_4C0000_454F46_000003_000000 T_001039_1E_ FFC _040030_000030_E0105D_30103F_D8105D_280030_301057_548039_2C105E_38103F T_0010570A_ 800 _100036_4C0000_F1_001000 T_001061_19_ FE0 _040030_E01079_301064_508039_DCI079_2C0036_381064_4C0000_05

E_000000

 

Рис. 3.6. Объектная программа, в которой перемещение задается с помощью маски перемещения.

 

Таким образом, в первой записи тела программы маска FFC (представляющая собой строку 111111111100) показывает, что все 10 слов объектного кода должны быть модифицированы при перемещении программы. В данных словах находятся команды, соответствующие в исходной программе строкам с 10 по 55 (см. рис. 3.5). Маска Е00 во второй записи тела программы определяет, что модификация требуется для трех первых слов. Оставшаяся часть объектного кода в данной записи представляет собой константы (и команду RSUB), не требующие модификации.

Аналогично строятся остальные записи тела программы. Обратите внимание, что объектный код, генерируемый для команды LDX в строке 210, начинает новую запись тела программы, хотя в предыдущей записи достаточно места для его размещения. Это произошло потому, что каждый разряд перемещения связан с 3-байтовым сегментом объектного кода (словом) в записи тела программы. Поэтому каждое значение, требующее модификации при перемещении, должно совпадать с одним из этих 3-байтовых сегментов для того, чтобы ему можно было поставить в соответствие разряд перемещения. Ассемблированная команда LDX действительно требует модификации, поскольку в ней используется прямая адресация. Однако, если бы она была помещена в предыдущую запись тела программы, она не была бы правильно выровнена для соответствия разряду перемещения, так как в строке 185 была сгенерирована 1-байтовая константа. Поэтому данная команда должна начинать в объектной программе новую запись тела программы.

Вам следует тщательно изучить оставшуюся часть объектной программы на рис. 3.6 и разобраться с тем, как ассемблер генерирует разряды перемещения и как они используются загрузчиком.

Некоторые ЭВМ предоставляют аппаратные средства, облегчающие организацию перемещения программ. Например, в некоторых машинах все ссылки к оперативной памяти рассматриваются как относительные ссылки с базовым адресом, назначаемым пользователем. Преобразование этих относительных адресов в физические производится во время исполнения программы. (Мы обсудим этот процесс позднее - при разборе управления оперативной памятью в гл. 6.) Однако, как мы увидим в следующем разделе, загрузчик тем не менее должен выполнять некоторые функции перемещения подпрограмм для обеспечения их связывания.

Связывание программ

С основными концепциями, затрагивающими связывание программ, мы познакомились в разд. 2.3.5. Прежде чем продолжить чтение, вам следует повторить материал этого раздела и еще раз посмотреть приведенные там примеры. В данном разделе мы обсудим более сложные примеры внешних ссылок между программами и изучим взаимосвязь между перемещением и связыванием. В следующем разделе дается описание алгоритма загрузчика, обеспечивающего связывание и перемещение программ.

На рис. 2.15 в разд. 2.3.5 была показана программа, состоящая из трех управляющих секций. Эти управляющие секции могут ассемблироваться как вместе (т. е. за одно обращение к ассемблеру)так и независимо друг от друга. В любом случае после ассемблирования они будут представлены в виде отдельных сегментов объектного кода (рис. 2.17). Однако программист, естественно, склонен рассматривать программу в виде логического целого, включающего в себя все связанные управляющие секции. Однако с точки зрения загрузчика никакой программы нет вообще. Имеются только управляющие секции, которые должны связываться, перемещаться и загружаться. Загрузчик никоим образом не может узнать (да это ему и не нужно) о том, какие управляющие секции ассемблировались одновременно.

Рассмотрим три (раздельно ассемблированные) программы, изображенные на рис. 3.7. Каждая из них состоит из единственной управляющей секции и содержит списки (LISTA, LISTB, LISTC). Концы этих списков помечены метками ENDA, ENDB, ENDC. Метки в начале и в конце списков являются внешними именами (т. е. они доступны для связывания). Обратите внимание, что каждая программа содержит один и тот же набор ссылок к этим внешним именам. Три из них - операнды команд (предложения с метками REF1-REF3), а остальные - ссылки на элементы данных длиной в одно слово (REF4 - REF8). На данном примере мы посмотрим, в чем состоят различия в обработке этих идентичных выражений в указанных трех программах, и подчеркнем взаимосвязь между перемещением и связыванием. Для того чтобы сосредоточиться на данном вопросе, мы сознательно не стали приводить реальные программы. Те части программ, которые не используются в процессах перемещения и связывания, опущены. То же самое относится и к сгенерированному для этих программ объектному коду (см. рис. 3.8)

Рассмотрим вначале предложение с меткой KEF1. Для первой программы (PROGA) REF1 является просто ссылкой на метку внутри данной программы. Она ассемблируется обычным образом как команда, использующая адресацию относительно счетчика команд. Никаких модификаций для перемещения или связывания не требуется. В PROGB, с другой стороны, тот же самый операнд ссылается на внешнее имя. Ассемблер использует для этой команды расширенный командный формат и заносит в адресное поле значение 000000. Соответствующая ей объектная программа (см. рис. 3.8) содержит запись-модификатор, в котором загрузчику предписывается добавить значение имени LISTA к данному адресному полю в момент связывания программы. Совершенно аналогично эта ссылка обрабатывается для PROGC.

Похожим образом обрабатывается ссылка в команде с меткой REF2. В PROGA выражение, используемое в качестве операнда, представляет собой сумму внешней ссылки и константы. Ассемблер запоминает величину константы в адресном поле команды, а запись-модификатор предписывает загрузчику добавить к данному полю значение LISTB. В PROGB то же самое выражение является локальной ссылкой и поэтому обрабатывается обычным образом с использованием адресации относительно счетчика команд. Ни перемещения, ни связывания здесь не требуется.

В команде с меткой REF3 используется непосредственный операнд, значением которого является разность между ENDA и LISTA (т.е. длина списка в байтах). В PROGA ассемблер располагает всей необходимой информацией для вычисления этого значения. Однако при ассемблировании PROGB (и PROGC) значения меток неизвестны. В этих программах выражение должно вычисляться как внешняя ссылка (с двумя записями-модификаторами) даже несмотря на то, что в конечном счете результат является абсолютной величиной, не зависящей от места загрузки программы.

 

Адрес Исходное предложение Объектный код

0000 PROGA START 0

EXTDEF LISTA,ENDA

EXTREF LISTB,ENDB,LISTC,ENDC

.

.

.

0020 REF1 LDA LISTA 03201D

0023 REF2 +LDT LISTB+4 77100004

0027 REF3 LDX #ENDA-LISTA 050014

.

.

.

0040 LISTA EQU *

.

.

0054 ENDA EQU *

0054 REF4 WORD ENDA-LISTA+LISTC 000014

0057 REF5 WORD ENDC-LISTC-10 FFFFF6

005A REF6 WORD ENDC-LISTC+LISTA-1 00003F

005D REF7 WORD ENDA-LISTA-(ENDB-LISTB) 000014

0060 REF8 WORD LISTB-LISTA FFFFC0

END REF1

 

 

Адрес Исходное предложение Объектный код

0000 PROGB START 0

EXTDEF LISTB,ENDB

EXTREF LISTA,ENDA,LISTC,ENDC

.

.

.

0036 REF1 +LDA LISTA 03100000

003A REF2 LDT LISTB+4 772027

003D REF3 +LDX #ENDA-LISTA 05100000

.

.

.

0060 LISTB EQU *

.

.

0070 ENDB EQU *

0070 REF4 WORD ENDA-LISTA+LISTC 000000

0073 REF5 WORD ENDC-LISTC-10 FFFFF6

0076 REF6 WORD ENDC-LISTC+LISTA-1 FFFFFF

0079 REF7 WORD ENDA-LISTA-(ENDB-LISTB) FFFFF0

007C REF8 WORD LISTB-LISTA 000060

END

 

 

Адрес Исходное предложение Объектный код

0000 PROGC START 0

EXTDEF LISTC,ENDC

EXTREF LISTA,ENDA,LISTB,ENDB

.

.

.

0018 REF1 +LDA LISTA 03100000

001C REF2 +LDT LISTB+4 77100004

0020 REF3 +LDX #ENDA-LISTA 05100000

.

.

.

0030 LISTC EQU *

.

.

0042 ENDC EQU *

0042 REF4 WORD ENDA-LISTA+LISTC 000030

0045 REF5 WORD ENDC-LISTC-10 000008

0048 REF6 WORD ENDC-LISTC+LISTA-1 000011

004B REF7 WORD ENDA-LISTA-(ENDB-LISTB) 000000

004E REF8 WORD LISTB-LISTA 000000

END

 

Рис.3.7. Модельная программа, иллюстрирующая связывание и перемещение.

 

Оставшиеся ссылки иллюстрируют другие возможные варианты. Общий подход, принятый при ассемблировании, заключается в том, что ассемблер стремиться вычислить как можно большую часть выражения. Оставшиеся термы передаются загрузчику с помощью записей-модификаторов. Для того чтобы разобраться в этом, рассмотрим предложение с меткой REF4. В PROGA ассемблер может вычислить все выражение, за исключением значения LISTC. В результате имеем начальное значение 000014 (шестнадцатеричное) и одну запись-модификатор. Однако в PROGB то же самое выражение не содержит ни одного терма, который может быть вычислен ассемблером. Поэтому объектный код будет содержать начальное значение, равное 000000, и три записи-модификатора. В PROGC ассемблер знает относительное значение LISTC (но не фактический адрес, который неизвестен до тех пор, пока программа не будет загружена в память). Начальное значение данной константы будет содержать относительный адрес LISTC (шестнадцатеричная величина 000030). Записи-модификаторы содержат указания загрузчику прибавить начальный адрес программы (т.е. значение PROGC)прибавить значение ENDA и вычесть значение LISTA. Таким образом, выражение REF4 представляет собой простую внешнюю ссылку в PROGA, более сложную внешнюю ссылку в случае PROGB и комбинацию перемещения с внешней ссылкой в случае PROGC.

Вам следует самостоятельно разобраться с оставшимися ссылками (с REF5 по REF8) и убедиться, что вы правильно поняли, как были сгенерированы объектный код и записи-модификаторы, показанные на рис. 3.8.

 

H_PROGA _000000_000063

D_LISTA _000040_ENDA _000054

R_LISTB _ENDB _LISTC _ENDC

*

*

T_000020_0A_03201D_77100004_050014

*

*

T_000054_0F_000014_FFFFF6_00005F_000014_FFFFC0

M_000024_05_+LISTB

M_000054_06_+LISTC

M_000057_06_+ENDC

M_000057_06_-LISTC

M_00005A_06_+ENDC

M_00005A_06_-LISTC

M_00005A_06_+PROGA

M_00005D_06_-ENDB

M_00005D_06_+LISTB

M_000060_06_+LISTB

M_000060_06_-PROGA

E_000020

 

 

H_PROGB _000000_00007F

D_LISTB _000060_ENDB _000070

R_LISTA _ENDA _LISTC _ENDC

*

*

T_000036_0B_03100000_772027_05100000

*

*

T_000070_0F_000000_FFFFF6_FFFFFF_FFFFF0_000060

M_000037_05_+LISTA

M_00003E_05_+ENDA

M_00003E_05_-LISTA

M_000070_06_+ENDA

M_000070_06_-LISTA

M_000070_06_+LISTC

M_000073_06_+ENDC

M_000073_06_-LISTC

M_000076_06_+ENDC

M_000076_06_-LISTC

M_000076_06_+LISTA

M_000079_06_+ENDA

M_000079_06_-LISTA

M_00007C_06_+PROGB

M_00007C_06_-LISTA

E

 

 

H_PROGС _000000_000051

D_LISTС _000030_ENDС _000042

R_LISTA _ENDA _LISTB _ENDB

*

*

T_000018_0C_03100000_77100004_05100000

*

*

T_000042_0F_000030_000008_000011_000000_000000

M_000019_05_+LISTA

M_00001D_05_+LISTB

M_000021_05_+ENDA

M_000021_05_-LISTA

M_000042_06_+ENDA

M_000042_06_-LISTA

M_000042_06_+PROGC

M_000048_06_+LISTA

M_00004B_06_+ENDA

M_00004B_06_-LISTA

M_00004B_06_-ENDB

M_00004B_06_+LISTB

M_00004E_06_+LISTB

M_00004E_06_-LISTA

E

 

Рис.3.8. Объектная программа, соответствующая рис.3.7.

 

На рис. 3.9а приведены три рассмотренные нами программы после загрузки и связывания. Программа PROGA была загружена, начиная с адреса 4000. Непосредственно после нее были загружены PROGB и PROGC. Заметим, что в результате (после перемещения связывания) каждое выражение с REF4 по REF8 будет иметь одно и то же значение во всех трех программах. Так и должно было быть, поскольку в исходных программах они имели один и тот же вид.

Рассмотрим, например, значение метки REF4 в PROGA. Она расположена по адресу 4054 (этот адрес

 

Адрес Содержимое

0000 хххххххх хххххххх хххххххх хххххххх

· · · · ·

· · · · ·

· · · · ·

3FF0 xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx

4000.....…….....……...... ……..........……......

4010.....…….....……...... ……..........……......

4020 03201D77 1040C705 0014..…......……… PROGA

4030.....…….....……...... ……..........……......

4040.....…….....……...... ……..........……......

4050......…….. 00412600 00080040 51000004

4060 000083.....……...... ……..........……......

4070.....…….....……...... ……..........……......

4080.....…….....……...... ……..........……......

4090.....…….....……..........031040 40772027 PROGB

40A0 05100014.....…….....……...... ……........

40B0.....…….....……...... ……..........……......

40C0.....…….....……...... ……..........……......

40D0 …........00 41260000 08004051 00000400

40E0 0083.….......…….....……...... ……........

40F0 ……...........…….......…..0310 40407710

4100 40C70510 0014.....…..……...... ……........ PROGC

4110.....…….....……...... ……..........……......

4120 ……........ 00412600 00080040 51000004

4130 000083 хх хххххххх хххххххх хххххххх

4140 хххххххх хххххххх хххххххх хххххххх

· · · · ·

· · · · ·

· · · · ·

 

a

 

Объектная программа Содержимое памяти

PROGA HPROGA · · · 0000

· ·

· (REF4) ·

· (REF4)

T000054 0F 000014 · · · · +

· 4050 · · · · · · · · · 004126 · · · · · · · · · · · ·

·

M 00005406+LISTC

·

·

·

·

·

·

PROGC HPROGC · · · ·

·

· + 4112

DLISTC 000030

· (Фактический

· адрес LISTC)

 

 

PROGA 004000

 

PROGB 004063

PROGC 0040E2

б

 

 

Рис.3.9а. Программа рис. 3.8 после связывания и загрузки. 3.9б. Выполнение операций связывания и перемещения для предложения REF4 из PROGA.

 

вычисляется как сумма начального адреса PROGA и относительного адреса REF4, равного 0054). На рис. 3.9б детально показан процесс вычисления этого значения. Начальное значение (полученное из записи тела программы) равно 000014. К нему прибавляется адрес, назначенный метке LISTC и равный 4112 (начальный адрес PROGC плюс 30). В PROGB значение REF4 расположено по относительному адресу 70 (фактический адрес 4003). К начальному значению (000000) загрузчик прибавляет значения меток ENDA (4054) и LISTC (4112), а затем вычитает значение метки LISTA (4040). В результате будет получено значение 004126, т. е. точно такое же, как и в PROGA. Значение REF4 в PROGC вычисляется аналогично и дает тот же самый результат. Те же самые рассуждения справедливы и для всех других меток с REF5 по REF8.

Если одно и то же выражение используется в качестве операнда в различных командах, то после загрузки адресные поля этих команд необязательно должны иметь одинаковые значения. Это происходит потому, что при вычислении адреса операнда для команд, использующих адресацию относительно счетчика команд (или базы), выполняется еще один дополнительный шаг. В данном случае важно, чтобы совпадали целевые адреса команд. Например, в PROGA команда с меткой REF1 использует адресацию относительно счетчика команд. Значение смещения для данной команды равно 010. В момент исполнения этой команды в счетчике команд будет находиться величина 4023 (фактический адрес следующей команды). В результате будет получен целевой адрес 4040. Данная команда не требует какой-либо модификации при перемещении программы, так как счетчик команд всегда будет содержать фактический (а не относительный) адрес следующей команды. Мы можем рассматривать данный процесс как автоматическое выполнение требуемого перемещения в момент исполнения программы путем вычисления целевого адреса. С другой стороны, в программе PROGB команда с меткой REF1 использует расширенный командный формат, в котором фактический адрес задается непосредственно. После связывания значение данного адреса будет равно 4040, т. е. будет совпадать со значением целевого адреса соответствующей команды PROGA.

Вам следует тщательно разобраться с остальными предложениями и убедиться, что целевые адреса (в случае REF2 и REF3) и значения констант (для REF5-REF8) одни и те же в каждой из трех программ. Сейчас вас не должно беспокоить, как загрузчик реально выполняет данные вычисления, поскольку необходимые для этого алгоритмы и структуры данных будут обсуждаться в следующем разделе. Важно, однако, чтобы вы поняли, какие именно вычисления надо делать, и могли выполнить их вручную (следуя при этом инструкциям, содержащимся в объектных программах).