Ну это кагбэ понятно. Интересует, что именно устарело (что, грамматический разбор по-другому делается? AST какой-то другой? промежуточное представление другое? или "всего лишь" методы оптимизации поменялись?), и какие книги содержат современную информацию.
Еще нужно учесть, что не все зарабатывают на жизнь компиляторостроением.
Угу. Сейчас подстраивают не индусов под компиляторы, а компиляторы под индусов.. Ибо скорость и простота разработки, ынтырпрайз, память нонче дешева, а процы у любого школьника четырехядерные и т.пр..
> потому что она устарела, уже никто так современные компиляторы не пишет.
Никак клоун всл вылез со своим как всегда альтернативным мнением о компиляторах?
Фундаментальные знания устареть не могут, а в Книге Дракона только фундаментальные вещи и изложены. Да и не поменялось ничего принципиально в компиляторостроении за последние лет эдак двадцать-тридцать.
Там о JIT ничего не сказанно. Современные тенденции таковы, что передовые разработки делаются по схеме interpreter+jit, так что, книга действительно устарела.
Сейчас набежит анонимусов, которые быстро расскажут, как нужно писать компиляторы. А авторы Книги Дракона лучше пусть занимаются варкой супов или лепкой пельменей.
JIT - это точно такой же компилятор, как и любой другой. Ничем не отличается от всех прочих, кроме оптимизации по скорости, и, соответственно, низким качеством оптимизаций.
> Современные тенденции таковы, что передовые разработки делаются по схеме interpreter+jit,
Вы таки ламер? Какой такой интерпретатор? Стандартный подход сейчас - компилятор в промежуточный язык (именно компилятор, и всё написанное в Драконьей Книге тут применимо) + JIT (который собственно простому смертному писать не надо, но если возьмётся за это, то опять же знаний из Драконьей Книги будет более чем достаточно).
> Ну я думаю, что некоторые оптимизации можно и не делать (в расчете на JIT), хотя могу и ошибаться.
Делать надо столько, сколько можешь, поскольку JIT почти никаких оптимизаций не делает, от него высокая скорость работы требуется, что абсолютно несовместимо с серьёзными оптимизациями. Средний JIT делает удаление неиспользуемого кода, простейший инлайнинг, раскраску регистров (причём поганенько, но это увы не контроллируемо на уровне генерации байткодов), самую элементарную оптимизацию арифметики, peephole оптимизации, и, пожалуй, всё на этом. Ничего более серьёзного он делать не умеет (и не должен).
> Хм. Если набор команд VM стековый, а целевая машина регистровая, оптимизация компилятора может чем-то помочь?
Конечно. Высокоуровневые оптимизации то всё равно делаются задолго до генерации кода какой либо конкретной или абстрактной машины. И их должен делать именно первый компилятор, а не JIT - во первых у него информации о коде гораздо больше, а во вторых у JIT просто нет времени.
> Ну хоть ее можно не делать %)
А вот фиг. На уровне байткодов - всё равно нужно. Например, всякие там последовательные box-unbox раскрывать надо, поскольку нет гарантии что JIT это заметит. Разнообразные peephole-проходы вообще надо делать много раз, на каждом этапе, когда появляется плоский код.
> Я имел в виду оптимизацию использования регистров (особенно глобальную). Не очень понимаю, как она переведется из стековой в регистровую.
А, ну так про это я и говорил, что не поможет. За исключением, конечно же, локальных переменных - их обычно всё же стоит считать типа как бы регистрами и экономить - для снижения нагрузки на и без того не самый умный JIT. А эти локальные переменные таки есть в любой почти стековой VM.
> Если он это не замечает, что он вообще замечает?
Свои же собственные артефакты от предыдущих проходов и замечает. Большего от него и не требуют.
Мнение о том, что JIT-у можно скармливать сколь угодно грязный код, ничем на деле не обоснованно.