Cтраница 2
Временные оценки же необходимо получать для конкретного компилятора и языка ассемблера целевого процессора. Этим объясняется необходимость моделирования процесса компиляции, ассемблирования и функционирования процессоров целевой вычислительной системы. В этом и состоит основная трудность реализации статического анализа фрагментов программы. Современные компиляторы поддерживают развитые механизмы оптимизации кода, например, выделение и исключение общих подвыражений, продвижение констант, распределение регистров. Кроме того, и компиляторы, и ассемблеры отдельно транслируют каждую единицу исходного кода. Все это может привести к тому, что моделирование компиляции отдельных фрагментов кода станет неадекватным реальному процессу компиляции всей программы. Конечно же, задача упрощается при наличии кросс-компилятора для целевой системы, который далеко не всегда доступен. [16]
Известно большое число работ, посвященных методам оптимизации компиляторов. Однако пока совершенно недостаточно уделено внимания как специфичным задачам оптимизации ДТ, так и методам тестирования двоичных трансляторов в различных режимах оптимизации. В данной работе делается попытка заполнить этот пробел. На примере этой системы анализируются такие методы оптимизации кода, как отложенные вычисления кодов условий и распределение регистров, и предлагаются алгоритмы верификации оптимизированного ДТ. [17]
Это было верно на начальном этапе. На численную сторону не обращалось внимание, поскольку язык был предназначен для символьной обработки. Лисп-системы могут в численных вычислениях быть более эффективными, чем Фортран на той же машине. Это объясняется в том числе и тем, что в трансляторах с Лиспа можно применять более сложные преобразования для оптимизации кода. [18]
Поэтому управление памятью во время выполнения отсутствует. Программы компилируются в машинные команды и выполняются аппаратным интерпретатором. На большинстве вычислительных машин выполнение операций ввода-вывода требует довольно значительного программного обеспечения. Однако наиболее очевидной областью несовместимости между виртуальной машиной Кобола и традиционной аппаратурой является представление данных. Большая часть данных в Кобол-программах хранится в форме цепочек литер, и каждая подцепочка, представляющая элемент данных, имеет сложное описание типа. Как упоминалось в предыдущем разделе, при организации доступа к элементам данных и при преобразовании между различными типами данных возникают значительные трудности. В идеале, поскольку по описаниям легко построить необходимые дескрипторы, большая часть работы по организации проверок, доступа и преобразований типа может быть выполнена во время компиляции; при этом в выполняемой форме присутствуют лишь относительно несложные вычисления, необходимые для доступа и преобразований типа. Однако в реализации Кобола с меньшей оптимизацией скомпилированного кода значительная часть этой обработки может делаться программно во время выполнения с использованием, дескрипторов, подготовленных компилятором. Программно моделируются также некоторые более специализированные примитивы Кобола, в частности операция SORT и команда SEARCH, предназначенная для поиска в массиве. [19]
Поскольку сверточный код - это групповой ( или линейный) код, набор расстояний, которые нужно проверить, не зависит от того, какая последовательность выбрана в качестве проверочной. Вследствие этого, не теряя общности, в качестве проверочной можно выбрать последовательность, целиком состоящую из нулей, показанную на рис. 9.25 пунктирной линией. В предположении, что была передана нулевая последовательность, ошибочное событие определяется как отклонение от нулевого пути с последующим возвратом на этот путь. Ошибочные события начинаются и заканчиваются состоянием а и не возвращаются в это состояние нигде в промежуточной области. На рис. 9.25 показано ошибочное сообщение в решетчатом коде, т.е. на рисунке изображена переданная нулевая последовательность, помеченная как U... Видно, что альтернативная последовательность сначала отклоняется, а затем снова сливается с переданной последовательностью. Если предположить, что осуществляется мягкое декодирование, сообщение принимается ошибочно тогда, когда полученные символы ближе ( евклидово расстояние) к некоторой возможной последовательности V, чем к реальной переданной последовательности U. Из этого следует, что коды для сигналов многоуровневой / фазовой модуляции должны строиться таким образом, чтобы достигать максимального евклидова просвета; чем больше просвет, тем меньше вероятность ошибки. Следовательно, присвоение сигналов переходам решетки в кодере таким образом, чтобы максимизировать евклидов просвет ( см. раздел 9.10.2), - это ключ к оптимизации решетчатых кодов. [20]