СИСТЕМА ДЛЯ ПОДГОТОВКИ ВЫЗЫВАЮЩЕГО ОБРАЗА И ЕГО ОСУЩЕСТВЛЕНИЯ Российский патент 1999 года по МПК G06F9/445 

Изобретение относится к программированию, точнее к способу обеспечения доступа к символам сегмента при совершении внешних вызовов в среде, поддерживающей сегменты с коллективным доступом.

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

Однако операционная система VAX/VMS^TM отличается тем, что поддерживает образы с коллективным доступом. Прикладная программа может использовать библиотечные образы, например, для печати, отображения на дисплей и т.д., вызываемые другими прикладными программами. Вместо предоставления каждой прикладной программе копии каждого такого библиотечного образа ряд программ в многопользовательской или многозадачной среде, активизируемых в момент запуска, обеспечивают возможность коллективного пользования этими образами. При этом, когда несколько программ используют библиотечный образ, необходима активизация только одной копии данного образца, а не собственной копии для каждой программы. Такой подход обеспечивает рациональное использование пространства оперативной памяти. Что является более важным, в иерархической памяти упомянутый образ будет скорее всего помещен в память с меньшим временем доступа, что обеспечит повышение общей производительности системы. Это в свою очередь означает, что требуемый образ при необходимости будет размещен в кэш-памяти, а не записан на диск виртуальной системы памяти.

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

Хотя особенность коллективного использования образов является существенным достижением VAX/VMS операционной системы, совершенствование компьютерных архитектур привело к необходимости создания расширенных программных возможностей для эффективной эксплуатации этих архитектур. Например, ширина каналов передачи информации увеличивалась с 8-битной до 16-битной, 32-битной и, наконец, 64-битной. Память стала намного дешевле и более быстродействующей. Полупроводниковые СБИС-технологии обеспечивали возможность увеличения числа составных элементов компьютера, объединенных в одной ИС, что сопровождалось снижением цен, уменьшением габаритов и потребляемой мощности, а также повышением быстродействия. Прогресс в разработке компиляторов позволил раскрывать элементарные шаги выполнения функций программисту или компилятору вместо встраивания их в микрокод. Эти и другие причины породили новое направление разработки так называемых RISC-архитектур вместо известной CISC-архитектуры VAX-машины. Более конкретно, была создана 64-битная RISC-архитектура, использующая все упомянутые технологии, о чем свидетельствует заявленная патентная документация за N 547,619, сданная в архив 29 июня 1990, которой владеет фирма DEC, где предложено устройство для преобразования программ, написанных в VAX-коде. Для обеспечения непосредственного преобразования прикладных программ, написанных в VAX-коде, и самой операционной системы VMS операционная система для новой RISC-архитектуры должна поддерживать многие свойства архитектуры VAX/VMS, среди которых есть и концепция коллективных образов.

Поскольку новая RISC-архитектура имеет другой набор команд и отличный от RISC механизм связывания, необходимо обеспечить трансляцию кода из VAX/VMS так, чтобы это свойство становилось реализованным. Кроме того, свойство коллективного использования образов в VMS-системе имело ряд ограничений, относящихся к автономности образов, и снятие этих ограничений в новой RISC-системе позволяет сделать систему более гибкой и менее ограниченной.

Ранее операционная система VAX/VMS осуществляла поддержку коллективного использования образов путем использования вектора перемещений в требуемом образе. Вектор перемещений представлял собой структуру, содержащую элемент на каждую процедуру в образе, которая должна быть видима извне. Каждый элемент таблицы перемещений содержал смещение на одну из процедур, и элементы располагались в фиксированном порядке. Вызывающий образ должен был включать только адрес вектора перемещений и порядковый номер вызываемой процедуры в этом векторе. При этом за время исполнения образа вызываемая процедура отыскивалась путем обращения к вектору перемещений (или, более точно, к смещению в упомянутом векторе, в соответствии с порядковым номером которого была расположена данная вызываемая процедура), где находится указатель на действительный адрес. Действительное местоположение, например, процедур Proc_A, Proc_B и других в образе 11 может изменяться в соответствии с изменениями, вносимыми в код. Однако, как обсуждалось выше, в настоящей реализации этот способ имеет определенные недостатки.

Так, операционная система VAX/VMS благодаря своему свойству коллективного использования образов обеспечивает конкретный тип установления связи между образами в момент запуска программы. Данный тип подразумевает ручное создание программистом вектора перемещений внутри каждого образа с коллективным доступом, где каждый элемент упомянутого вектора представляет собой точку перемещения либо на процедуру внутри образа, либо на ячейку или структуру данных. Путем создания этого вектора (что является обычным процессом при установлении интерфейса в операционной или программной системе) достигается инвариантность каждой относительной величины (смещения) для каждого элемента вектора и обеспечивается возможность ее привязывания в другие образы, вызывающие данный, пока местоположение вектора перемещений не определится за время активизации.

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

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

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

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

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

Краткое описание рисунков
Принципы, определяющие суть изобретения, приведены в прилагаемой формуле изобретения. Однако понимание преимуществ и принципов изобретения основывается на подробном описании конкретного варианта осуществления изобретения, поясняемом прилагаемыми чертежами, на которых:
фиг. 1 представляет собой диаграмму нескольких образов, предназначенных для выполнения на компьютере и иллюстрирующих принципы изобретения;
фиг. 2 представляет собой диаграмму компьютера, на котором может применяться способ связывания образов, предложенный в настоящем изобретении;
фиг. 3 представляет собой диаграмму вектора перемещений, используемого в VAX/VMS системе для установления связи между образами в момент запуска;
фиг. 4 представляет собой диаграмму программных образцов и ассоциированных с ними символьной таблицы и символьного вектора в соответствии с настоящим изобретением;
фиг. 5 изображает блок-схему действий, добавленных к процессу обработки файла редакторов связей, примененному в соответствии с упомянутой реализацией изобретения;
фиг. 6 изображает блок-схему действий, добавленных к редактору связей и применяемых для обработки обращений к символам в соответствии с реализацией изобретений на фиг.4;
фиг.7 представляет собой блок-схему действий, выполняемых в активизаторе образов для подстройки обращений между образами в соответствии с реализацией изобретения на фиг.4.

Подробное описание предпочтительного варианта осуществления изобретения
В соответствии с фиг. 1 первой частью компьютерной программы является образ (фрагмент кода) 10, называемый в дальнейшем вызывающим образом. Другой частью программы является образ 11, в дальнейшем именуемый требуемым образом. Вызывающий образ 10 содержит вызовы процедур 12 - команды, вызывающие в требуемом образе 11 определенные процедуры 13, именуемые в дальнейшем Proc_ A, Proc_ B и Proc_С. В исходном или ассемблерном тексте сегменты программы, представленные этими образцами, обращаются к вызываемым процедурам 13 по имени (например, Proc_A, Proc_B и т.д.), однако, когда образ активизируется в памяти с целью его исполнения процессором, возникает необходимость определения процедур 13 по адресу (или по паре связи, как мы будем говорить в дальнейшем). Конечно, эти адреса неизвестны до момента активизации, то есть, пока образы 10 и 11 не вызваны процессором на фиг.2 и не загружены в память 15. В среде виртуальной памяти, такой как VMS, виртуальные адреса присваиваются в момент запуска и остаются фиксированными, несмотря на то, что в многозадачной среде физические адреса в памяти 15 могут изменяться динамически, например, при загрузке образов в память и записи их на диск 16. Если все вызывающие и требуемые образы 10, 11 и т.д., предназначенные для исполнения и вызывающие один другого, собраны в единый пакет (при отсутствии возможности коллективного использования образов), задача упрощается, однако этот случай нас мало интересует. Мы предполагаем, что требуемый образ должен являться образом с коллективным доступом, так что некоторый вызывающий образ 17 может совершать вызовы к упомянутому требуемому образу 11. Поскольку в наиболее распространенных операционных системах коллективное использование образов не поддерживается, то если два вызывающих сегмента 10 и 17 находятся в отдельно активизируемых программах и оба обращаются к одному и тому же требуемому образу 11, часть кода, представленная образом 11, дублируется. Для поддержки коллективного использования образов, как показано на фиг.1, необходимо обеспечить механизм для реализации связывания.

Согласно фиг.3 операционная система VAX/VMS для поддержки коллективного использования образов применяет вектор перемещений. Архитектура VAX описана Levy и Eckhouse в книге "Компьютерное программирование и архитектура: VAX", 2-е изд. , Digital Press, 1989, ссылки на которую мы будем здесь приводить. Операционная система VMS предполагала описание вектора перемещений 19 в требуемом образе 11; вектор 19 состоял из элементов A', B', C' для каждой из процедур 13. Каждый элемент содержал величину смещения (указатель относительно начала вектора перемещений 19) на одну из вызываемых процедур 13, при этом элементы имели фиксированный порядок. Вызывающему образу 10 требовались только адрес вектора перемещений 19 и порядковый номер вызываемой процедуры в упомянутом векторе. Действительное местоположение процедур Proc_A, Proc_B и т.д. в образе 11 на фиг.4 могло меняться, однако, когда код обновлялся или корректировался, ссылки из вызывающих образов на вектор перемещений оставались правильными, поскольку ссылка, связанная с вызывающим образом, являлась адресом элемента в векторе перемещений 19. Как обсуждалось выше, в настоящей реализации изобретения этот способ имеет свои недостатки. Каждый вызов в коллективно используемый сегмент 11 приводит к выполнению дополнительных операций, так как передачу управления в вызываемую процедуру 13 приходится осуществлять через вектор перемещений 19. Для описания и использования вектора перемещений 19 необходимо дополнительное программирование. Кроме того, случайные изменения вектора 19 могут приводить к ошибкам в процессе выполнения. При обращении к ячейкам памяти и структурам данных (в отличие от процедур 13) обеспечивается недостаточная гибкость, поскольку данные должны быть размещены внутри соответствующего элемента самого вектора перемещений 19. Таким образом, объем данных ограничивается размером элемента, который фиксирован, поскольку должен находиться на определенной позиции вектора перемещений. Кроме того, для описания вектора перемещений может потребоваться дополнительная семантика языка, которая может отсутствовать в применяемом пользователем языке программирования.

В соответствии с изобретением вместо вектора перемещений 19 на фиг.3 используется символьный вектор 20 на фиг.4. Как и ранее, требуемый образ 11 содержит некоторые вызываемые образом 10 процедуры 13. Процедуры 13, обозначенные снова Proc_A, Proc_B и Proc_C, расположены в произвольных позициях кода образа 11. В процессе редактирования связей процедуры 13 (определяемые по их символическим именам) распознаются и заносятся в символьную таблицу 21 в порядке появления. Таким образом заполняются элементы символьной таблицы 21. Символьная таблица 21 является структурой данных, создаваемой компилятором наряду с образами и используемой редактором связей с целью определения всех внешних обращений к переменным, литеральным значениям, процедурам, вызываемым программам и т.д. Каждый элемент символьной таблицы содержит символическое имя, определяющее позицию в образе, где располагается соответствующий объект. Любой объект, описанный программистом как глобальный или универсальный, заносится в символьную таблицу; таким образом, процедуры 13 становятся глобально объявленными. Кроме того, редактор связей создает символьный вектор 20 и размещает его в образе 11 на установленной по умолчанию или же определенной в файле опций позиции, так что указатель на символьный вектор 20 задается в заголовке 23. Вектор 20 строится в том порядке, в каком символы 13 встречаются в файле опций редактора связей, и содержит элемент 24 для каждого символа 13. Этот порядок должен оставаться неизменным при всех последующих построениях символьного вектора. Элементы 24 могут добавляться к концу, некоторые элементы могут быть вычеркнуты (в данном случае они будут содержать пустой элемент), но последующие элементы 24 должны размещаться в тех же начальных позициях. При разрешении обращений к другим образам редактор связей посимвольно просматривает символьную таблицу 21 требуемого образа, находит элемент 22 и определяет его индекс в символьном векторе 20 для данного требуемого образа 11. Этот индекс (порядковый номер) для данного имени образа привязывается с образом 10 по позиции вызова 12. В момент активизации программы процедура активизации образа использует индекс, привязанный к вызывающему образу 10, для получения текущего значения символа в требуемом образе путем обращения к заголовку 23 с целью получения указателя на символьный вектор 20 и индекса элемента 24 в векторе 20, содержащего действительное смещение в образе 11, где ищется процедура 13. Ни символьный вектор 20, ни символьная таблица 21 не становятся частью активизированного кода в памяти. Обращение к вызывающей позиции 12 является обращением к адресу (или, в некоторых случаях, к литеральному значению, если символ - литерал), а не косвенным обращением, как на фиг.3.

На фиг.5 - 7 показаны логические блок-схемы операций, связанных с использованием свойств символьного вектора. На фиг.5 проиллюстрирован способ обработки описания символьного вектора в файле опций редактора связей. Программист добавляет имена процедур 13 к файлу опций редактора связей, то есть добавляет имена объектов модуля, которые должны быть видимыми за пределами данного модуля, и устанавливает опцию SYMBOL_VECTOR в значение "истина". Последовательность действий на фиг. 5 представляет собой дополнение к стандартным программам обработки файла опций, осуществляемым редактором связей; они выполняются только в случае, когда опция SYMBOL_VECTOR установлена. Сначала переменная N инициализируется нулем, а затем осуществляется вход в цикл, решение о выходе из которого принимается в точке 30, если достигнут конец списка описаний. В этом случае символьный вектор 20 записывается в образ 11, как показано в блоке 31, и действия фиг.5 завершены. Если это не так, осуществляется синтаксический разбор командной строки с целью получения следующего элемента N (следующего символа 13, описанного пользователем), который запоминается в локальной переменной SYMВOL в блоке 32. Тип элемента (процедура или ячейка данных) запоминается в переменной TYPE. В блоках 33 и 34 элементы проверяются на правильность и в случае обнаружения ошибки в блоке 35 генерируется ошибка и осуществляется выход из процедуры. Если все правильно, в блоке 36 значение символа записывается в символьный вектор 20 как элемент 24 на позицию N, а значение в соответствующем элементе символьной таблицы 21 заменяется на порядковый номер символа N в символьном векторе 20. Символьная таблица 21 записывается как часть образа 11. Затем в блоке 37 определяется, является ли элемент процедурой (а не ячейкой данных), и если это так, выполняется операция блока 38, показывающая адресное поле кода CA символьного вектора, соответствующего данному символу и заполняемое адресом кода из описателя процедуры PDSC. Адрес кода используется путем активизации (фиг.7). В блоке 39 осуществляется возврат в начало цикла, где порядковый номер N увеличивается на единицу. Цикл повторяется до тех пор, пока не будут обработаны все элементы 13 списка, после чего сформированный символьный вектор записывается в блоке 31.

На фиг. 6 показана последовательность операций, добавленных к коду редактора связей с целью обработки обращений к символам. Редактор связей считывает символ для обработки и в блоке 40 проверяет, существует ли элемент 22 с этим именем в символьной таблице 21. Если нет, в блоке 41 генерируется ошибка. Если символ находится в символьной таблице, в блоке 42 редактор связей проверяет, определен ли данный символ в обрабатываемом образе 11, и в этом случае использует значение из самой символьной таблицы, как показано в блоке 43. Если символ не определен, значение элемента 22 символьной таблицы (порядковый номер из блока 36) используется как универсальное значение символа (USV), и в блоке 44 образу присваивается имя того образа 11, в котором найден искомый символ. Далее в блоке 45 осуществляется проверка на тип обращения; если определяется обращение адресного типа, то значение USV идентифицируется как USV подстройки и определяется имя образа для программы подстройки (блок 46). Если обращение является парой связи, USV заменяется текущим местоположением и определяется имя образа в блоке 47. После этого образы готовы к активизации. Для каждого подстраиваемого образа (каждого IMNAM) существует список значений символов.

На фиг.7 изображена блок-схема кода, используемого активизатором образов с целью подстройки междуобразных обращений. Образы загружаются, и начинается подстройка внешних образов списка посредством использования цикла с осуществлением в точке 50 проверки, есть ли еще образы в каждом списке. Для каждого элемента в блоке 51 счетчик цикла I устанавливается в нуль, после чего в блоке 52 осуществляется вход в цикл проверки, требуется ли еще подстройка. Действия в этом цикле происходят согласно списку, генерированному редактором связей (см. фиг.7), который указывает все небходимые итерации подстройки для данного требуемого образа. Для каждой итерации подстройки в блоке 53 блок-схемы устанавливаются два значения: первое - USV (универсальное значение символа) и второе - LOC (местоположение). USV для данного номера i (FIXUR.USV(i) из блоков 46, 47 задает индекс 22 требуемого элемента 24 в символьном векторе; VAL=SYMVAL.VAL[USV] означает считывание значения символьного вектора 20 для требуемого образа 11 по индексу USV. Местоположение в подстриваемом образе определяется переменной LOC (блок 53). Затем в блоке 54 определяется тип подстройки; если подстройка осуществляется по адресу, текущее местоположение увеличивается на VAL. Значение VAL является тем, которое должно быть окончательным подлинным значением символа в том образе, в котором он описан, то есть тем, что пользователь на самом деле желает получить при обращении к символу - обычно это не имя (Proc_A и тд.), а адрес (хотя возможна и простая константа). Таким образом операция блока 55 (@LOC = @LOC+VAL) означает, что для получения точного местоположения к значению LOC, вычисленному для упомянутого образа в блоке 53, добавляется значение VAL.

Если типом подстройки является пара связи, то выполняются следующие операции. Пара связи представляет собой два числа, каждое длиной в четыре слова, которые являются адресами, относящимися к данной процедуре; первое число - описатель процедуры, второе - действительный адрес первой из команд в коде процедуры. Это описание соответствует стандарту совершения вызовов на новый RISC-архитектуре. В блоке 56 (фиг.7) первое число определяется по адресу кода, который берется из элемента 24 символьного вектора (снова путем использования порядкового номера USV в качестве индекса). Этот адрес кода CA становится @ LOC. Цикл продолжается с увеличением I в блоке 57 до тех пор, пока не будут сделаны все необходимые итерации подстройки.

Способ, описанный в настоящем изобретении, допускает различные модификации и варианты. Цель приведенного здесь конкретного варианта осуществления изобретения - охватить все возможные модификации в пределах, соответствующих области техники и формулы изобретения.

Изобретение относится к области вычислительной техники. Техническим результатом является то, что символьный вектор конструируется автоматически, так что редактор связей и операционная система быстро просматривают символы при активизации программы, обеспечивая тем самым гибкость, аналогичную гибкости привязки за время редактирования связи. 1 з.п. ф-лы, 7 ил.

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