Абельсон Х., Сассман Д.Д. Структура и интерпретация компьютерных программ

Подождите немного. Документ загружается.

5.5. Компиляция

551

(lambda (+ * a b x y)

(+ (* a x) (* b y)))

которая вычисляет линейную комбинацию x и y. Мы могли бы вызвать такую процедуру с аргумен-

тами +matrix, *matrix и четырьмя матрицами, но явно кодирующий компилятор по-прежнему

вставлял бы код для + и * в (+ (* a x) (* b y)) как для примитивов + и *. Измените ком-

пилятор с явным кодированием так, чтобы он проверял окружение времени компиляции и на его

основе порождал правильный код для выражений, в которых встречаются имена элементарных

процедур. (Код будет работать правильно, пока программа не применяет к этим именам define

или set!.)

5.5.7. Связь скомпилированного кода с вычисл и телем

Пока что мы не объяснили, как загружать скомпилированный код в машину-

вычислитель и как его запускать. Предположим, что машина-вычислите ль с явным

управлением определена как в разделе 5.4.4 с дополнительными операциями из при-

мечания 38. Мы реализуем процедуру compile-and-go, которая компилирует выраже-

ние на Scheme, загружает получившийся код в машину-вычислитель, а затем заставляет

машину исполнить код в глобальном окружении вычисл ителя, напечатать результат и

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

выражения могли вызывать не только интерпретируемые, но и скомпилированные про-

цедуры. После этого мы можем поместить скомпилированную процедуру в машину и

вызвать ее с помощью интерпретатора:

(compile-and-go

’(define (factorial n)

(if (= n 1)

(* (factorial (- n 1)) n))))

;;; Значение EC-Eval:

;;; Ввод EC-Eval:

(factorial 5)

;;; Значение EC-Eval:

120

Для того, что бы вычисли те ль мог обрабатывать скомпилированные процедуры (на-

пример, выполнить вызов factorial, как показано выше), нужно изменить код apply-

dispatch (раздел 5.4.1), чтобы он распознавал их (в отличие от составных и элемен-

тарных процедур) и передавал управление прямо во входную точку скомпилирован ного

кода

apply-dispatch

(test (op primitive-procedure?) (reg proc))

Разумеется, скомпилированные процедуры являются составными (неэлементарными) точно так же, как

и интерпретируемые. Однако ради совместимости с терминологией, которая используется при обсуждении

вычислителя с явным управлением, мы в этом разделе будем считать, что слово «составная» означает «интер-

претируемая» (а не скомпилированная).

552

Глава 5. Вычисления на регистровых машинах

(branch (label primitive-apply))

(test (op compound-procedure?) (reg proc))

(branch (label compound-apply))

(test (op compiled-procedure?) (reg proc))

(branch (label compiled-apply))

(goto (label unknown-procedure-type))

compiled-apply

(restore continue)

(assign val (op compiled-procedure-entry) (reg proc))

(goto (reg val))

Обратите внимание на восстановление continue в compiled-apply. Вспомним, что

вычислитель был так устроен, что при выполнении apply-dispatch продолжение на-

ходилось на вершине стека. С другой стороны, входная точка скомпилированного кода

ожидает, что продолжение будет находиться в continue, так что этот регистр надо

восстановить, прежде чем передать управление скомпилированному коду.

Для того, чтобы позволить нам запускать скомпилированный код при запуске вычис-

лителя, мы в начало машины добавляем команду branch, которая переводит машину на

новую точку входа, если установлен регистр flag

(branch (label external-entry)) ; переход, если установлен flag

read-eval-print-loop

(perform (op initialize-stack))

...

External-entry предполагает, что при запуске машины регистр val содержит место-

положение последовательности команд, которая помещает результат в val и заканчива-

ется командой (goto (reg continue)). Запуск машин ы с этой точки входа приво-

дит к переходу в место, куда показывает val, но сначала continue устанавливается в

print-result, которая распечатает значение val, а затем направится в начало управ-

ляющего цикла вычислителя

Теперь, когда код вычислителя начинается с branch, нам перед запуском машины всегда нужно устанав-

ливать значение flag. Для того, чтобы запустить машину в обычном управляющем цикле, можно использовать

(define (start-eceval)

(set! the-global-environment (setup-environment))

(set-register-contents! eceval ’flag false)

(start eceval))

Поскольку скомпилированная процедура является объектом, который система может попытаться напеча-

тать, нужно еще измен ить системную операцию печати user-print (из раздела 4.1.4), чтобы она не пыталась

печатать компоненты скомпилированной процедуры:

(define (user-print object)

(cond ((compound-procedure? object)

(display (list ’compound-procedure

(procedure-parameters object)

(procedure-body object)

’<procedure-env>)))

((compiled-procedure? object)

5.5. Компиляция

553

external-entry

(perform (op initialize-stack))

(assign env (op get-global-environment))

(assign continue (label print-result))

(goto (reg val))

Теперь с помощ ью следующей процедуры можно скомпилировать определение, выпол-

нить скомпилированный код и войти в управляющий цикл, откуда мы можем процедуру

от тестировать. Поскольку мы хотим, чтобы скомпилированная процедура возвращалась в

место, указанное continue, со значением в val, мы компилируем выражение с целе-

вым р егистром val и типом связи return. Чтобы преобразовать объектный код, пор ож-

даемый компилятором, в исполняемые команды регистровой машины-вычислителя, мы

пользуемся процедурой assemble из имитатора регистровых машин (раздел 5.2.2). За-

тем мы устанавливаем val, чтобы он указывал на список команд, устанавливаем flag,

чтобы вычислитель поше л на external-entry, и запускаем выч ислитель.

(define (compile-and-go expression)

(let ((instructions

(assemble (statements

(compile expression ’val ’return))

eceval)))

(set! the-global-environment (setup-environment))

(set-register-contents! eceval ’val instructions)

(set-register-contents! eceval ’flag true)

(start eceval)))

Если мы установим отслеживание стека, как в конце раздела 5.4.4, то сможем иссле-

довать использование стека скомпилированным кодом:

(compile-and-go

’(define (factorial n)

(if (= n 1)

(* (factorial (- n 1)) n))))

(total-pushes = 0 maximum-depth = 0)

;;; Значение EC-Eval:

;;; Ввод EC-Eval:

(factorial 5)

(total-pushes = 31 maximum-depth = 14)

;;; Значение EC-Eval:

120

(display ’<compiled-procedure>))

(else (display object))))

554

Глава 5. Вычисления на регистровых машинах

Сравните этот пример с вычислением (factorial 5) с помощью интерпретируемой

вер сии той же самой процедуры, приведенным в конце раздела 5.4.4. В интерпретируемой

вер сии потребовалось 144 сохранения и максимальная глубина стека 28. Это показывает,

какую оптимизацию удалось получить с помощью нашей стратегии компиляции.

Интерпретация и компиляция

При помощи программ из этого разде ла мы можем проводить эксперименты с различ-

ными стратегиями выполнения: интерпретацией и компиляцией

. Интерпре татор подн и-

мает машину до уровня пользовательской программы; компил ятор опускает пользова-

тельскую программу до уровня машинного языка. Можно рассматривать язык Scheme

(или любой язык программирования) как согласованную систему абстракций, построен-

ных поверх машинного языка. Интерпретаторы хороши для интерактивной разработки

программ и их отладки, поскольку шаги выполнени я программы организованы в терми-

нах этих абстракций, и, следовательно, лучше понятны программисту. Скомпилирован-

ный код может работать быстрее, поскольку шаги выполнения программы организованы

в терминах машинного языка, и компил ятор может проводить оптимизации, которые

нарушают абстракции верхнего уровня

Компиляция и интерпретация также ведут к различным стратегиям при переносе

языков на новые компьютеры. Предположим, что нам надо реализовать Лисп для новой

машины. Одна страте ги я будет состоять в том, чтобы взять вычислитель с явным управ-

лением из раздела 5.4 и перевести е го команды в команды новой машины. Вторая — в

том, чтобы нач ать с компилятора и изменить генераторы кода так, чтобы они порожда-

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

программу на Лиспе, если сначала скомпи лировать ее компилятором, который работает

на исходной Лисп-системе, а затем связать со скомпилированной версией рабочей биб-

лиотеки

. Более того, мы можем скомпилировать сам компилятор, и, запустив его на

Можно добиться даже большего, если расширить компилятор так, чтобы скомпилированный код мог вы-

зывать интерпретируемые процедуры. См. упражнение 5.47.

Независимо от стратегии выполнения, мы сталкиваемся с существенным замедлением, если требуем, что-

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

приводили к смерти системы или к неверным результатам работы. Например, индексирование за границы мас-

сива можно обнаружить, если перед обращением к массиву проверить правильность индекса. Однако затраты

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

взвешивать преимущества скорости и безопасности, когда он решает, нужна ли такая проверка. Хороший ком-

пилятор должен уметь порождать код с проверками, избегать лишних проверок и позволять программистам

управлять количеством и видами проверок на ошибки в скомпил ированном коде.

Компиляторы для популярных языков программирования, вроде C или C++, почти никаких проверок в ра-

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

приходится самим проводить проверку на ошибки. К сожалению, многие этим пренебрегают, даже в крити-

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

опасную жизнь. Например, знаменитый «Червь», который парализовал Интернет в 1988 году, использовал то,

что операционная система UNIX

не проверяла переполнение буфера в демоне finger. (См. Spaﬀord 1 989.)

Разумеется, как при интерпретаци и, так и при компиляции придется еще реализовать для новой машины

управление памятью, ввод и вывод, а также все операции, которые мы считали «элементарными» при обсуж-

дении интерпретатора и компилятора. Один из способов минимизировать эту работу заключается в том, чтобы

как можно большее число этих операций написать на Лиспе, а затем скомпилировать для новой машины. В

конце концов все сводится к простому ядру (например, сборка мусора и механизм для применения настоящих

машинных примитивов), которое кодируется для новой машины вручную.

5.5. Компиляция

555

новой машине, компилировать другие программы на Лиспе

. Либо же мы можем ском-

пилировать один из интерпретаторов из раздела 4.1 и получить интерпретатор, который

работает на новой машине.

Упражнение 5.45.

Сравнивая статистику операций со стеком, порождаемую скомпилированным кодом, с такой же

статистикой для интерпретатора, ведущего то же самое вычисление, можно определить, насколько

компилятор оптимизирует работу со стеком, как по скорости (уменьшая общее число стековых

операций), так и по памяти (уменьшая максимальную глубину стека). Сравнение той же статисти-

ки с результатами работы специализированной машины, предназначенной для того же вычисления,

дает некоторое представление о качестве компилятора.

а. В упражнении 5.27 о т Вас требовалось определить как функцию от n число сохранений и

максимальную глубину стека, которые тре буются вычислителю для того, чтобы получить n! с

помощью указанной факториальной процедуры. В упражнении 5.14 Вас просили провести те же

измерения для специализированной факториальной машины, показанной на рисунке 5.11. Прове-

дите теперь тот же анализ для скомпилированной процедуры factorial.

Возьмем отношение числа сохранений в скомпилированной версии к числу сохранений в интерпре-

тируемой версии и проделаем то же для максимальной глубины стека. Поскольку число операций

и глубина стека при вычислении n! линейно зависят от n, эти отношения должны приближаться

к константам при росте n. Чему равны эти константы? Найдите также отношения показателей

использования стека в специализированной машине к показателям интерпретируемой версии.

Сравните отношения специализированной версии к интерпретируемой и отношения скомпилиро-

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

намного лучше скомпилированного кода, поскольку настроенный вручную код контроллера дол-

жен быть намного лучше, чем результаты работы нашего рудиментарного компилятора общего

назначения.

б. Можете ли Вы предложить изменения в компиляторе, помогающие ему порождать код, ко то-

рый приблизится к показателям версии, построенной вручную?

Упражнение 5.46.

Проведите анализ, подобный анализу из упражнения 5.45, и определите эффективность компиля-

ции для процедуры Фибоначчи с древовидной рекурсией

(define (fib n)

(if (< n 2)

(+ (fib (- n 1)) (fib (- n 2)))))

по сравнению с эффективностью работы специализированной машины Фибоначчи с рисунка 5.12.

(Измерения интерпретируемой версии см. в упражнении 5.29.) Для процедуры Фибоначчи время

растет в нелинейной зависимости от n; следовательно, отношение числа стековых операций не

будет приближаться к независимому от n пределу.

Упражнение 5.47.

В этом разделе рассказывалось, как модифицировать вычислитель с явным управлением и позво-

лить интерпретируемому коду вызывать скомпилированные процедуры. Покажите, как можно из-

Такая стратегия приводит к забавным проверкам корректности компилятора. Можно, например, сравнить,

совпадает ли результат компиляции программы на новой машине, с помощью скомпилированного компилятора,

с результатом компиляции той же программы на исходной Лисп-системе. Поиск причин расхождения — занятие

интересное, но зачастую довольно сложное, поскольку результат может зависеть от микроскопических деталей.

556

Глава 5. Вычисления на регистровых машинах

менить компилятор и позволить скомпилированным процедурам вызывать не только элементарные

и скомпилированные процедуры, но и интерпретируемые. При этом придется изменить compile-

procedure-call так, чтобы обрабатывался случай составных (интерпретируемых) процедур.

Проследите, чтобы обрабатывались все те же сочетания target и linkage, что и в compile-

proc-appl. Для того, чтобы произвести собственно применение процедуры, код должен перехо-

дить на точку входа compound-apply вычислителя. На эту метку нельзя напрямую ссы латься

из объектного кода (потому что ассемблер требует, чтобы все метки, на которые явно ссыла-

ется объектный код, в нем и определялись), так что придется добавить в машину-вычислитель

специальный регистр compapp, в котором будет храниться эта точка входа, и команду для его

инициализации:

(assign compapp (label compound-apply))

(branch (label external-entry)) ; переход, если установлен flag

read-eval-print-loop

...

Чтобы проверить свой код, для начала определите процедуру f, которая вызывает процедуру g.

С помощью compile-and-go скомпилируйте определение f и запустите вычислитель. Теперь,

ввод я код для интерпретации, определите g и попробуйте вызвать f.

Упражнение 5.48.

Интерфейс compile-and-go, реализованный в этом разделе, неудобен, поскольку компилятор

можно вызвать только один раз (при запуске машины-вычислителя). Дополните интерфейс меж-

ду компилятором и интерпретатор ом, введя примитив compile-and-run, который можно будет

вызывать из вы числителя с явным управлением так:

;;; Ввод EC-Eval:

(compile-and-run

’(define (factorial n)

(if (= n 1)

(* (factorial (- n 1)) n))))

;;; Значение EC-Eval:

;;; Ввод EC-Eval:

(factorial 5)

;;; Значение EC-Eval:

120

Упражнение 5.49.

В качестве альтернативы циклу ввод-выполнение-печать вычислителя с явным управле нием,

спроектируйте регистровую машину, которая работала бы в цикле ввод-компиляция-выполнение-

печать. А именно, машина должна работать в цикле, при каждой итерации котор ого она считывает

выражение, компилирует его, ассемблирует и исполняет получившийся код , и печатает резуль-

тат. В нашей имитируемой среде это легко устроить, поскольку мы можем заставить compile и

assemble работать как «операции регистровой машины».

Упражнение 5.50.

С помощ ью компилятора о ттранслируйте метациклический интерпретатор из раздела 4.1 и запу-

стите эту программу через имитатор регистровых машин. (Чтобы скомпилировать за раз более

5.5. Компиляция

557

одного определения, можно упаковать определения в begin.) Получившийся интерпретатор бу-

дет работать очень медленно из-за многочисленных уровней интерпретации, однако заставить все

детали работать — полезное упражнение.

Упражнение 5.51.

Разработайте рудиментарную реализацию Scheme на C (или на другом низкоуровневом языке по

Вашему выбору), переведя на C вычислитель с явными управлением из раздела 5.4. Для того,

чтобы запустить этот код, Вам потребуется предоставить также функции для выделения памяти и

прочую поддержку времени выполнения.

Упражнение 5.52.

В качестве обратной задачи к упражнению 5.51, измените ком пилятор так, чтобы он компилировал

процедуры Scheme в последовательности команд C. Скомпилируйте метациклический интерпрета-

тор из раздела 4.1 и получите интерпретатор Scheme, написанный на C.

Литература

Abelson, Harold, Andrew Berlin, Jacob Katzenelson, William McAllister, Guillermo Rozas,

Gerald Jay Sussman, and J ack Wisdom. 1992. The Supercomputer Toolkit: A general

framework for special-purpose computing. International Journal of High-Speed Electronics

3(3):337-361.

Allen, John. 1978. Anatomy of Lisp. New York: McGraw-Hill.

ANSI X3.226-1994. American National Standard for Information Systems—Programming

Language—Common Lisp.

Appel, Andrew W. 1987. Garbage collection can be faster than stack allocation. Information

Processing Letters 25(4):275-279.

Backus, John. 1978. Can programming be liberated from the von Neumann style?

Communications of the ACM 21(8):613–641.

Baker, Henry G., Jr. 1978. List processing in real time on a serial computer. Communications

of the ACM 21(4):280-293.

Batali, John, Neil Mayle, Howard Shrobe, Gerald Jay Sussman, and Daniel Weise. 1982.

The Scheme-81 architecture—System and chip. In Proceedings of the MIT Conference on

Advanced Research in VLSI, edited by Paul Penﬁeld, Jr. Dedham, MA: Artech House.

Borning, Alan. 1977. ThingLab—An object-oriented system for building simula-tions

using constraints. In Proceedings of the 5th International Joint Conference on Artiﬁcial

Intelligence.

Borodin, Alan, and Ian Munro. 1975. The Computational Complexity of Algebraic and

Numeric Problems. New York: American Elsevier.

Chaitin, Gregory J. 1975. Randomness and mathematical proof. Scientiﬁc Americ an

232(5):47–52.

Church, Alonzo. 1941. The Calculi of Lambda-Conversion. Princeton, N.J.: Princeton

University Press.

Clark, Keith L. 1978. Negation as failure. In Logic and Data Bases. New York: Plenum

558

Литература

559

Press, pp. 293–322.

Clinger, William. 1982. Nondeterministic call by need is neither lazy nor by name. In

Proceedings of the ACM Symposium on Lisp and Functional Programming, pp. 226–234.

Clinger, William, and Jonathan Rees. 1991. Macros that work. In Proceedings of the 1991

ACM Conference on Principles of Programming Languages, pp. 155–162.

Colmerauer A., H. Kanoui, R. Pasero, and P. Roussel. 1973. Un syst

eme de communication

homme-machine en fran¸cais. Technical rep ort, Groupe Inte lligence Artiﬁcielle, Universit

d’Aix Marseille, Luminy.

Cormen, Thomas, C harles Leiserson, and Ronald Rivest. 1990. Introduction to Algorithms.

Cambridge, MA: MIT Press. (Русский перевод: Кормен Т., Ч. Лейзерсон, Р. Ривест.

Алгоритмы: построение и анализ. – М.: МЦНМО, 2001.)

Darlington, John, Peter Henderson, and David Turner. 1982. Functional Programming and

Its Applications. New York: Cambridge University Press.

Dijkstra, Edsger W. 1968a. The structure of the “THE” multiprogramming system.

Communications of the ACM 11(5):341–346.

Dijkstra, Edsger W. 1968b. Cooperating sequential processes. In Programming Languages,

edited by F. Genuys. New York: Academic Press, pp. 43–112. (Русский перевод: Дийкст-

ра Э. Взаимодействие последовательных процессов. // в кн.: Языки программирования,

под ред. Ф. Женюи. – М.: Мир, 1972, с. 9–86.)

Dinesman, Howard P. 1968. Sup erior Mathematical Puzzles. New York: Simon and

Schuster.

deKleer, Johan, Jon Doyle, Guy Steele, and Gerald J. Sussman. 1977. AMORD: Explicit

control of reasoning. In Proceedings of the ACM Symposium on Artiﬁcial Intelligence and

Programming Languages, pp. 116–125.

Doy le, Jon. 1979. A truth maintenance system. Artiﬁcial Intelligence 12:231–272.

Feigen baum, Edward, and Howard Shrobe. 1993. The Japanese National Fifth Generation

Project: Introduction, survey, and evaluation. In Future Generation Computer Systems, vol.

9, pp. 105–117.

Feeley, Marc. 1986. Deux approches

a l’implantation du language Scheme. Masters thesis,

Universit

e de Montr

eal.

Feeley, Marc and Guy Lapalme. 1987. Using closures for code generation. Journal of

Computer Languages 12(1):47–66.

Feller, William. 1957. An Introduction to Probability Theory and Its Applications, volume

1. New York: John Wiley & Sons. (Русский перевод: Феллер В. Введение в теорию веро-

ятностей и её при ложения, в 2-х томах. – М.: Мир, 1984)

560

Литература

Fenichel, R., and J. Yochelson. 1969. A Lisp garbage collector for virtual memory computer

systems. Communications of the ACM 12(11):611–612.

Floyd, Robert. 1967. Nondeterministic algorithms. JACM, 14(4):636–644.

Forbus, Kenneth D., and Johan deKleer. 1993. Building Problem S olvers. Camb ridge, MA:

MIT Press.

Friedman, Daniel P., and David S. Wise. 1976. CONS should not evaluate its arguments.

In Automata, Languages, and Programming: Third International Colloquium, edited by S.

Michaelson and R. Milner, pp. 257–284.

Friedman, Daniel P., Mitchell Wand, and Christopher T. Haynes. 1992. Essentials of

Programming Languages. Cambridge, MA: MIT Press/McGraw-Hill.

Gabriel, Richard P. 1988. The Why of Y. Lisp Pointers 2(2):15–25.

Goldberg, Adele, and David Robson. 1983. Smalltalk-80: The Language and Its

Implementation. Reading, MA: Addison-Wesley.

Gordon, Michael, Robin Milner, and Christopher Wadsworth. 1979. Edinburgh LCF. Lecture

Notes in Computer Sc ience, volume 78. New York: Springer-Verlag.

Gray, Jim, and Andreas Reuter. 1993. Transaction Processing: Concepts and Models. San

Mateo, CA: Morgan-Kaufman.

Green, Cordell. 1969. Application of theorem proving to problem solving. In Proceedings of

the International Joint Conferenc e on Artiﬁcial Intelligence, pp. 219–240.

Green, Cordell, and Bertram Raphael. 1968. The use of theorem-proving techniques in

question-answering systems. In Proceedings of the ACM National Conference, pp. 169–181.

Griss, Martin L. 1981. Portable Standard Lisp, a brief overview. Utah Symbolic Computation

Group Operating Note 58, University of Utah.

Guttag, John V. 1977. Abstract data types and the development of data structures.

Communications of the ACM 20(6):397–404.

Hamming, Richard W. 1980. Coding and Info rmation Theory. Englewood Cliﬀs, N.J.:

Prentice-Hall.

Hanson, Christopher P. 1990. Eﬃcient stack allocation for tail-recursive languages. In

Proceedings of ACM Conferen c e on Lisp and Functional Programming, pp. 106–118.

Hanson, Christopher P. 1991. A syntactic closures macro facility. Lisp Pointers, 4(3).

Hardy, Godfrey H. 1921. Srinivasa Ramanujan. Proceedings of the London Mathematic al

Society XIX(2).

Hardy, Godfrey H., and E. M. Wright. 1960. An Introduction to the Theory of Numbers.

4th edition. New York: O x ford University Press.