Книга о компиляторах

именно ахо/ульман, и то его мало... Или лучше иди улицы мести, ползы будет больше

Альфред Ахо, Рави Сети, Джеффри Ульман "Компиляторы: Принципы, Технологии, Инструменты"
5,51 Mb; 768 страниц; формат - djvu
http://masterpc.alfaspace.net/books/CCScience/AhoSetiUlman_Kompilyators-www.m...

Т. Пратт, М. Зелковиц "Языки программирования: разработка и реализация"
Я что-то не нагуглил

> именно ахо/ульман, и то его мало... Или лучше иди улицы мести, ползы будет больше

//wbr?

Книга Дракона. Не помню, кто написал.

> Книга Дракона.

Безумные анонимусы ЛОРа утверждают, что вышла из моды Книга Дракона. Правда, не утруждаются объяснять, почему.

потому что она устарела, уже никто так современные компиляторы не пишет.

> потому что она устарела

Ну это кагбэ понятно. Интересует, что именно устарело (что, грамматический разбор по-другому делается? AST какой-то другой? промежуточное представление другое? или "всего лишь" методы оптимизации поменялись?), и какие книги содержат современную информацию.

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

> потому что она устарела, уже никто так современные компиляторы не пишет.

Вообщето недавно была новая редакция этой книги.

> потому что она устарела

Фундаментальные вещи не устаревают. Только если оказывается, что они в корне неправильные.

> уже никто так современные компиляторы не пишет

Как их пишут?

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

> потому что она устарела, уже никто так современные компиляторы не пишет.

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

Фундаментальные знания устареть не могут, а в Книге Дракона только фундаментальные вещи и изложены. Да и не поменялось ничего принципиально в компиляторостроении за последние лет эдак двадцать-тридцать.

Там о JIT ничего не сказанно. Современные тенденции таковы, что передовые разработки делаются по схеме interpreter+jit, так что, книга действительно устарела.

Сейчас набежит анонимусов, которые быстро расскажут, как нужно писать компиляторы. А авторы Книги Дракона лучше пусть занимаются варкой супов или лепкой пельменей.

> Там о JIT ничего не сказанно.

Но для того, чтобы дать материал JIT'у, нужно скомпилировать программу до кода виртуальной машины - вся (или почти вся) Книга Дракона применима.

> Там о JIT ничего не сказанно.

JIT - это точно такой же компилятор, как и любой другой. Ничем не отличается от всех прочих, кроме оптимизации по скорости, и, соответственно, низким качеством оптимизаций.

> Современные тенденции таковы, что передовые разработки делаются по схеме interpreter+jit,

Вы таки ламер? Какой такой интерпретатор? Стандартный подход сейчас - компилятор в промежуточный язык (именно компилятор, и всё написанное в Драконьей Книге тут применимо) + JIT (который собственно простому смертному писать не надо, но если возьмётся за это, то опять же знаний из Драконьей Книги будет более чем достаточно).

> так что, книга действительно устарела.

Ну ну. Смешной ты.

> вся (или почти вся) Книга Дракона применима.

Вся, если учесть, что виртуальные машины бывают и стековые, и регистровые (LLVM, WAM, и т.п.).

>> вся (или почти вся) Книга Дракона применима.

> Вся

Ну я думаю, что некоторые оптимизации можно и не делать (в расчете на JIT), хотя могу и ошибаться.

> Ну я думаю, что некоторые оптимизации можно и не делать (в расчете на JIT), хотя могу и ошибаться.

Делать надо столько, сколько можешь, поскольку JIT почти никаких оптимизаций не делает, от него высокая скорость работы требуется, что абсолютно несовместимо с серьёзными оптимизациями. Средний JIT делает удаление неиспользуемого кода, простейший инлайнинг, раскраску регистров (причём поганенько, но это увы не контроллируемо на уровне генерации байткодов), самую элементарную оптимизацию арифметики, peephole оптимизации, и, пожалуй, всё на этом. Ничего более серьёзного он делать не умеет (и не должен).

К нигу дракона ниписали индусы...

> раскраску регистров (причём поганенько, но это увы не контроллируемо на уровне генерации байткодов)

Хм. Если набор команд VM стековый, а целевая машина регистровая, оптимизация компилятора может чем-то помочь?

> peephole оптимизации

Ну хоть ее можно не делать %)

> Хм. Если набор команд VM стековый, а целевая машина регистровая, оптимизация компилятора может чем-то помочь?

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

> Ну хоть ее можно не делать %)

А вот фиг. На уровне байткодов - всё равно нужно. Например, всякие там последовательные box-unbox раскрывать надо, поскольку нет гарантии что JIT это заметит. Разнообразные peephole-проходы вообще надо делать много раз, на каждом этапе, когда появляется плоский код.

>> Хм. Если набор команд VM стековый, а целевая машина регистровая, оптимизация компилятора может чем-то помочь?

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

Я имел в виду оптимизацию использования регистров (особенно глобальную). Не очень понимаю, как она переведется из стековой в регистровую.

> всякие там последовательные box-unbox раскрывать надо, поскольку нет гарантии что JIT это заметит

Если он это не замечает, что он вообще замечает?

> Я имел в виду оптимизацию использования регистров (особенно глобальную). Не очень понимаю, как она переведется из стековой в регистровую.

А, ну так про это я и говорил, что не поможет. За исключением, конечно же, локальных переменных - их обычно всё же стоит считать типа как бы регистрами и экономить - для снижения нагрузки на и без того не самый умный JIT. А эти локальные переменные таки есть в любой почти стековой VM.

> Если он это не замечает, что он вообще замечает?

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

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