
книги из ГПНТБ / Журавлев, Ю. П. Системное проектирование управляющих ЦВМ
.pdf§ 2.10. МЕТОДИКА ВЫБОРА ВНУТРЕННЕГО ЯЗЫКА УПРАВЛЯЮЩЕЙ ЦВМ
Задача выбора внутреннего языка управляющей ЦВМ решается поэтапно.
1-й этап. |
В ы б о р о с н о в н о г о с п и с к а о п е р а |
ций. В § 2.1 |
указывалось, что вопрос о выборе основ |
ного списка операций в настоящее время остается от крытым, и проблема выбора внутреннего языка управ ляющей цифровой машины, затронутая в настоящей главе, предполагает задание этого списка. Однако в неко торых случаях выбор основного списка операций может производиться с ориентацией на некоторый прототип, в качестве которого служит основной список операций какой-нибудь ЦВМ.
Ниже рассматривается одна из возможных процедур выбора основного списка операций.
Эта процедура состоит из трех этапов:
—алгоритмизации задачи,
—моделирования задачи с помощью универсальной
ЦВМ,
—выбора основного списка команд.
Алгоритмизация задачи включает:
—выбор математического метода,
—систематизацию исходных данных, расчленение их на входные переменные и необходимые для решения за дачи константы,
—выделение логических условий, ограничений и до пущений, которые могут существенно повлиять на окон чательный результат решения,
—составление блок-схемы алгоритма, определяющей порядок и последовательность переработки информации,
и описание ее в терминах какого-либо алгоритмического языка.
Разработанный алгоритм должен обладать следующи ми свойствами:
—определенностью (детерминированностью) порядка выполнения операций;
—универсальностью, т. е. способностью многократно го решения задачи с различными исходными данными;
—результативностью, т. е. гарантией получения одно значного решения за конечное число шагов вычислитель ного процесса.
Ш
Вид алгоритма зависит от формы математического описания задачи и при преобразованиях расчетных фор мул может видоизменяться. Одновременно с этим будет изменяться общее количество элементарных вычисли тельных операций и их процентное соотношение. Послед нее обстоятельство позволяет путем моделирования процесса решения задачи на универсальной ЦВМ варьи ровать процесс составления алгоритма посредством на правленного изменения вида расчетных формул с целью выбора основного списка команд.
Моделирование включает:
— составление программы решения задачи в терми нах внутреннего языка некоторой универсальной ЦВМ
иввод ее в машину (или трансляцию задачи);
—статистический анализ составленной (оттранслиро ванной) задачи в динамическом режиме, т. е. набор ста тистических данных по частотному спектру операций и объему вычислительных работ.
В результате моделирования получаются данные о том, какой процент операций каждого типа, имеющих ся в списке команд этой универсальной ЦВМ, участвует в процессе переработки информации в соответствии с ис следуемым алгоритмом.
Основной список операций выбирается, исходя из ре зультатов обработки полученных статистических данных. Выбор заключается в следующем.
Вначале анализируется весь частотный спектр без учета спецкоманд той ЦВМ, с помощью которой выпол нялось моделирование. Наиболее часто встречающиеся операции вносятся в основной список команд проектируе мой ЦВМ и одновременно исследуется возможность за мены некоторых редко встречающихся операций или их объединения с другими. Затем на основе умозрительных соображений направленным образом изменяют выявлен ный состав команд основного списка путем добавления некоторых команд, отсутствующих в списке моделирую щей машины, и выполняют повторное моделирование, в результате которого этот список может вновь изме ниться, и т. д. С каждым уточнением основного списка операций проводится количественный анализ объема вы числительных работ.
Необходимо отметить, что выше речь шла о простей ших арифметических, логических и управленческих опе рациях, хотя принципиально нет препятствий, чтобы
111
включить в основной список команд такие кбманДы, под воздействием которых проектируемая ЦВМ будет спо собна выполнять более сложные операции, такие, как интегрирование функции одной переменной в определен ных пределах, сложение (вычитание) двух различных функций от одной переменной на заданном диапазоне изменения последней, вычисление трансцендентных функ ций и т. п. Такие попытки в настоящее время уже пред принимаются.
Введение в основной список подобных команд сущест венно отразится на структуре операционных устройств проектируемых ЦВМ, приведет к значительному увеличе нию количества оборудования и усложнению системы коммутации между отдельными функциональными узла ми. Анализ целесообразности введения таких команд должен решаться в каждом конкретном случае отдельно. Общий подход к решению этого вопроса пока еще не
выработан. |
этап. |
В ы б о р |
а д р е с н о с т и к о м а н д ос |
|
2- |
й |
|||
н о в н о г о |
с пис к а . Этот |
этап выполняется с учетом |
||
рекомендаций, приведенных в § 6.2. |
||||
3- |
й |
этап. |
С о с т а в л е н и е п р о г р а м м ы а л г о |
|
р и т м о в у п р а в л е н и я в т е р м и н а х о с н о в н о г о |
||||
с п и с к а |
к о ма н д . |
Программы алгоритмов управления |
могут быть составлены непосредственно вручную либо промоделированы с помощью любой универсальной ЦВМ (так, как это описано, например, в работе {23]) или, если основной список команд совпадает с системой команд прототипа — некоторой ЦВМ, имеющей транслятор с под ходящего для описания алгоритмов управления алгорит мического языка, оттранслированы.
4- |
й этап. О п р е д е л е н и е |
ч а с т о т н ы х х а р а к |
т е р и с т и к а л г о р и т м о в у п р |
а в л е н и я . Частот |
ные характеристики алгоритмов управления определяют ся с помощью специальной программы-анализатора, ко торая перед исполнением каждой команды (или модели команды) анализируемых алгоритмов управления про
водит их |
анализ |
с учетом необходимой предыстории, |
э затем |
передает |
управление исследованной команде. |
Программа-анализатор не искажает работы исследуемых программ. Описание программы-анализатора достаточно громоздко и в то же время не представляет особого ин тереса, поэтому здесь не приводится. Подобные програм мы использовались в различных исследованиях (см., на-
]фймер, [15] и приложение 1 настоящей книги). В конце своей работы программа-анализатор выдает на печать следующие характеристики программ алгоритмов управ ления:
а) Частотный спектр
/= 1, 2, ...,«,
операций основного списка. б) Частотный спектр
jDa~'{Paj}, / = 1, 2, . . ., Ra—1,
относительных адресов. в) Частотные спектры
P |
i |
/ = /min, |
., /maxi |
/= 1, 2, . . ..S'max,
цепочек элементарных операций допустимой длины. г) Частотный спектр
Л>~{роЛ, /= 1 , 2...... |
/?о--- 1, |
относительных кодов операций.
Как указывалось выше, количество всевозможных цепочек последовательных операций фиксированной дли ны сильно зависит от числа исходных операций, вклю чаемых в состав цепочки и от длины последней. Напри мер, если в основной список входит 20 операций,.™ раз личные цепочки длиной в 5 последовательных операций, составленных из этих двадцати, превышают три мил лиона.
В реальной программе, состоящей из Nup команд основного списка операций, количество различных цепо чек любой фиксированной длины не может превышать числа NИр даже при условии, что она составлена только из различных цепочек. Если же учесть тот факт, что ре альные программы имеют объемы, не превышающие не скольких десятков тысяч команд, и содержат большое количество повторяющихся цепочек различной длины, то станет очевидным, что реальные частотные спектры цепо чек последовательных операций с нулевыми частотами во много раз уже теоретически возможных частотных спектров. Анализ результатов экспериментальных иссле дований частотных спектров цепочек последовательных операций показывает, что с увеличением длины цепочки
8—458 |
113 |
реальные спектры с ненулевыми Частотами сильно сужа ются. Все это дает возможность относительно быстро и
просто определить спектры цепочек |
последовательных |
||
операций. |
В ы б о р |
о с н о в н ы х |
э л е м е н т о в в н у |
5-й этап. |
|||
т р е н н е г о |
я з ык а , |
а) Определение допустимых длин |
цепочек операций в командах первого дополнительного списка осуществляется в соответствии с выражениями, полученными из (2.7):
где R*u, l*i — допустимые значения разрядностей отно сительных адресов и соответствующих им длин цепочек операций.
В результате составляется таблица допустимых отно сительных адресов и соответствующих им длин цепочек операций, как это сделано в § 2.5.
б) Определение допустимых разрядностей одноадрес ных фрагментов и, следовательно, допустимых длин цепо чек операций в командах второго и третьего дополни
тельных |
списков выполняется с помощью соотношений |
|
|
R ^ ^ E i R o ^ A R j L ^ ) , |
|
где R*<i,i, |
L*i — значения |
искомых величин. |
Составляется таблица |
значений пар R*&, L*t. |
в) Выбор операций первого дополнительного списка осуществляется таким образом, что из всех частотных спектров цепочек операций, допустимой для первого до
полнительного списка длины, выбирается |
цепочек |
с наибольшими значениями произведений pij(U—1): |
|
М, = 2Ro — М, |
|
где М — количество операций основного |
списка, R0— |
разрядность кода операций, р ц — частота |
появления /-й |
цепочки длины U.
г) Оптимальная разрядность Ry усеченных кодов опе раций для максимального сжатия исходных программ выбирается на основе соотношения (см. § 2.5)
2 'У |
т |
Umax 1 |
Р м X G(Rm - R y) . |
' i=1 |
k = \ |
которое предполагает, что частоты рЭг появления опера ций основного списка не возрастают с увеличением ин-
114
декса i. Полученное значение Ry указывает на то, что из М операций основного списка целесообразно выбрать
М0 — 2Ry
операций в порядке убывания частот их появления и присвоить им усеченные коды.
д) Оптимальную разрядность/?^ относительных ко
дов операций для каждого k-ro допустимого фрагмента можно выбрать по условию максимизации функции
(см. § 2.5). |
|
6-й этап. В ы б о р с и с т е м ы фо р м а т о в |
к о ма н д . |
Вся необходимая для выявления системы |
форматов |
команд информация получена на предыдущем этапе. На этом этапе она обобщается. При этом составляются спи сок кодов обобщенных операций и таблица соответствия усеченных кодов и полных кодов операций; определяются общее количество различных форматов команд и раз рядность признака формата; определяется единая раз рядная сетка команд всех списков; выбирается относи тельное расположение элементов операционной и адрес ной частей команд каждого формата.
Шестой этап завершает построение модели внутрен него языка управляющей ЦВМ. Она является основой внутреннего языка, окончательный выбор которого может быть произведен только лишь после испытания этой мо
дели. |
. . |
Дело в том, что статистические данные указывают ча |
|
стоты появления |
независимых событий — цепочек, адре |
сов, относительных кодов операций. В реальных алгорит мах цепочки могут перекрываться таким образом, что некоторые из выбранных не будут иметь применения. Кроме того, некоторые из выбранных цепочек могут вы пасть из списка из-за малой разрядности отводимых в коде команды относительных адресов. По этой же при чине могут оказаться непригодными те или иные форма ты команд второго или третьего дополнительных списков. Другими словами, целью испытания модели внутреннего языка является отсев неиспользуемых обобщенных команд первого дополнительного списка и неиспользован-
8* 115
ных форматов команд второго и третьего дополнитель ных списков.
7-й этап. И с п ы т а н и е м о д е л и в н у т р е н н е г о я з ы к а . На этом этапе программы анализируемых алго ритмов, записанные в терминах основного списка команд, исследуются на «сжатие», т. е. на возможность замены групп последовательно выполняемых команд одиночны ми командами дополнительных списков. При каждой воз можности такая замена осуществляется с одновременной фиксацией как самого факта замены, так и цепочки, типа формата и т. д. Испытание модели внутреннего языка должно проводиться по вполне определенным правилам, совокупность которых образует основу алгоритма «сжа тия» программ (см. § 2.9) .
На основании результатов «сжатия» программ и по лученных реальных частотных спектров уточняется мо дель внутреннего языка проектируемой ЦВМ. Это уточ нение заключается в том, что все цепочки с нулевыми или очень низкими реальными частотами, обусловленны ми пересекаемостью их с другими цепочками, исключа ются из дополнительного списка. Точно так же исключа ются и форматы для относительных и усеченных кодов операций с нулевыми или очень низкими реальными ча стотами появления. Одновременно с этим проектировщи ком могут быть включены в модель дополнительно неко торые цепочки и форматы на основе каких-либо умозри тельных выводов.
После этого модель повторно испытывается на «сжа тие» программы и в случае получения удовлетворитель ных результатов на этом процесс выбора внутреннего языка проектируемой управляющей ЦВМ заканчивается.
Эффективность построения модели внутреннего язы ка, использующего принципы относительной адресации, всегда выше эффективности последнего, не использую щего эти принципы.
Седьмой этап завершает процесс выбора и обоснова ния внутреннего языка управляющей ЦВМ. На этом эта пе окончательно уточняются все списки команд, система форматов и разрядность команд.
Нетрудно заметить, что выбор внутреннего языка управляющей ЦВМ в соответствии с предлагаемой мето дикой требует выполнения большого объема вычисли тельных работ, связанных с набором статистических дан ных и их обработкой.
116
§ 2.11. ЗАМЕЧАНИЯ ПО ВЫБОРУ ВНУТРЕННЕГО ЯЗЫКА
1. Наличие мощных вычислительных систем с развитым математическим обеспечением и большой емкостью памяти позволяет автоматизировать процесс выбора вну треннего языка управляющих ЦВМ.
Эволюция развития средств вычислительной техники привела к реальной возможности создания в настоящее время ЦВМ четвертого поколения, обладающих разви тыми системами команд, запоминающими устройствами емкостью в несколько миллиардов битов, быстродейст вием до нескольких миллионов операций в секунду и мощным математическим обеспечением.
Математическое обеспечение таких машин позволяет значительно расширить области и масштабы применения ЦВМ за счет использования специальных языков раз личного уровня многих типов. К низшим уровням отно сятся символические языки (автокоды, мнемокоды и др.), которые в той или иной мере связаны с техническими ха рактеристиками машины и являются машинно-ориенти рованными. К языкам высших уровней относятся языки, тесно связанные не с цифровой машиной, а с ее назна чением, т. е. с характером решаемых задач. К таким поо- блемно-ориентированным языкам относятся АЛГОЛ, ФОРТРАН, КОБОЛ, СОЛ и др.
Использование машинно-ориентированных и програм мно-ориентированных языков потребовало разработки программных средств, обеспечивающих повышение эф фективности ЦВМ в целом. Создаваемые с этой целью программы позволяют в значительной мере освободить программистов и операторов в процессе подготовки и решения задач от участия в организации работы про граммных и аппаратурных компонент, а также обеспе чивают их взаимодействие при работе в различных ре жимах. Эти программы, помимо трансляции текстов с ориентированных языков на внутренний язык машины, выполняют ряд функций, связанных с учетом, отладкой, контролем и т. п. Эти программы вместе с программами интерпретирующих и компилирующих систем, динамиче ского распределения памяти, прерывания по приорите там, управления периферийным оборудованием и кон троля за его работой, а также стандартными подпрограм-
117
мами объединяются специальной программой, называе мой супервизором.
Для автоматизации процесса выбора внутреннего язы ка проектируемых управляющих ЦВМ с помощью подоб ных систем необходимо дополнить их математическое обеспечение специальными программами-анализаторами для определения частотных спектров операций, относи тельных адресов, цепочек последовательных операций, а также программами выбора системы дополнительных форматов команд, сжатия п сравнения различных моде лей внутренних языков по критерию экономии памяти для программ.
2. Преобразующие грамматики Gx и Gs (§§ 2.7, 2.8) описаны весьма конспективно с единственной целью — не загромождать текст излишними подробностями, затруд няющими понимание их структуры. В целях упрощения все фрагменты второго и третьего дополнительных спи сков предполагались одноадресными, а соответствующие
им символы алфавитов и Ед являлись поэтому упо
рядоченными парами. Систему правил грамматики Gx следовало бы дополнить правилами, позволяющими про водить перекодировку исходных программ с использо ванием двух-, трех- и многоадресных фрагментов.
Кроме того, отображения F и ¥ |
грамматики Gx и со |
ответственно обратные отображения |
F _1 и u F '1 грамма |
тики Gs используют переменную базу. Для полноты кар тины необходимо ввести в эти грамматики и отображе ния с постоянной базой. Введенные упрощения снижают эффективность соответствующих конечных преобразова телей и в итоге — эффективность внутреннего языка ма
шины. |
Экспериментальные исследования, описанные |
в § 2.9 |
и приложении 1, были лишены этих упрощений. |
Наконец, количество относительных адресов выходно го символа шифрирующей грамматики Gx не всегда рав но количеству адресов кортежа соответствующей цепоч ки входных символов. Например, если символы входного алфавита 2i грамматики Gx суть трехадресные команды, в которых один из адресов служит для указания места засылки результата операции только лишь для того, что бы его извлечь оттуда при выполнении следующей команды (если это нужно), то ясно, что эта пара адрессв двух соседних трехадресных команд не должна учи тываться при анализе всего кортежа адресов. Подобные нюансы можно обнаружить и в случае одноадресных или
118
двухадресных команд. При построении алгоритма сжа тия это необходимо учитывать, исходя из конкретного состава основного списка команд.
3. Рассмотренная в § 2.10 методика выбора внутрен него языка управляющих ЦВМ обладает достаточной общностью и может в частных случаях приводить к вы бору внутренних языков уже известных типов.
Пусть к моменту испытания модели внутреннего язы ка ЦВМ, предназначенной для функционирования в не которой конкретной АСУ, были определены все дополни тельные списки команд и системы их форматов и пусть после отсева неиспользуемых команд и соответствующих им форматов в результате работы алгоритма сжатия ока залось, например, что все команды сжатой программы имеют один и тот же формат и относятся только ко вто рому дополнительному списку. Тогда каждый фрагмент можно рассматривать как отдельную команду. Усечен ный код операции становится полноразрядным кодом операции, поскольку никакие другие коды операций не используются. Адресная часть фрагмента содержит один или несколько относительных адресов. Подобные системы команд имеют, например, ЦВМ «Днепр» и 1ВМ/360, при чем первая из них содержит в коде команды два девяти разрядных относительных адреса, а вторая — один две надцатиразрядный относительный адрес.
Если после сжатия оказалось, например, что все команды сжатой программы имеют одинаковый формат и относятся только к первому дополнительному списку, причем база постоянная и равна нулю, то каждый отно сительный адрес превращается в полноразрядный фак тический адрес, а коду обобщенной операции ставится в соответствие вполне определенная цепочка элементар ных операций. Подобные системы команд описываются в работах [2, 16] и уже имеются у некоторых ЦВМ.
Если же после работы алгоритма сжатия исходная программа не сжалась, то полученный в результате вну тренний язык входит в семейство внутренних языков большинства известных в настоящее время ЦВМ.
Таким образом, рассмотренная методика обладает широкими возможностями и может приводить к выбору различных типов существующих и перспективных вну тренних языков управляющих ЦВМ.
4. Техническая реализация принципов относительной адресации приводит к необходимости изменения струк
119