kosh the bestподробнее: я высказал предположение, что транслятор llvm ir в машкод целевой платформы можно написать и на других языках, помимо си и с++ с терпимым провалом в скорости трансляции

Какая разница - IR или C++? И то и другое должно транслироваться БЫСТРО . В том же Clang большая часть времени при компиляции тратися именно внутри LLVM (не верите - возьмите профайлер и убедитесь). И делать это быстро на чем либо отличном от C++ вы не сможете. Все остальное будет намного, недопустимо более медленным.

далее я написал, почему все же на си и с++ будет быстрее - за счет нативных типов (в том числе и беззнаковых)

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

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

А этой фразы я вообще не понял.

ZyK_BotaNа что непонятного?

Кривизна формулировки.

выделил мегабайт памяти, и размещай там объекты как хочешь.

Ну так и надо говорить про арифметику указателей.

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

А вот это неверно. Как раз автоматический GC позволяет избежать фрагментации там, где руками это сделать очень непросто. Правда, в обсуждаемой задаче (компиляторы) это совершенно не важно, фрагментации там не будет в любом случае, так как мы можем оперировать очень хорошо разграниченными пулами.

iv_an_ruКак будто в лиспах нет возможности накидать гадостей в голую память :)

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

kosh the bestяву пишут на яве

Ага, так написали, что единственный действительно удобный для пользователя компилятор Java - это Jikes. Который, таки да, работает как раз более чем в десять раз быстрее чем родной компилятор. Угадайте, на чем он написан?

лиспы тоже пишут на лиспах

Ну, про этих в приличном обществе лучше вообще не говорить.

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

Уточнение - БЫСТРЫЕ компиляторы надо писать на C++. Да, язык низкоуровневый, некоторые вещи требуют большого объема boilerplate-кода, но за все за это мы получаем сверхсветовую скорость работы. Поверьте, оно того стоит.

iv_an_ruНу то есть пулы придумали именно сиплюсплюсовцы и никак не раньше, ага.

Ну то есть пулы фундаментально несовместимы с тотальным GC.

kosh the bestа как это сделать в лиспах?

Там вообще другая идеология, там глупо было бы этими вещами заниматься. Там скорее вот так сделают: http://okmij.org/ftp/Scheme/binary-io.html

iv_an_ruнеприспособленность языка для задач сопоставления с образцом.

1) Посмотрите на tablegen в LLVM

2) Посмотрите на Elsa (и конкретно на http://scottmcpeak.com/elkhound/sources/ast/index.html )

3) Ничто не мешает и более сложные DSL поверх C++ (или какого либо препроцессора над C++) сделать. Можно даже аналог scrap your boilerplate сделать ( http://www.haskell.org/haskellwiki/Scrap_your_boilerplate )

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

Я где-то про парсинг вообще говорил? Библиотека ast в Elsa это уже совсем другой уровень. А уж tablegen и подавно. Вы бы хоть посмотрели внимательно, прежде чем комментировать.

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

Ой не надо. Чего там толстого-то? ADT это тупо tagged unions, компилятор даже довольно сложного языка шаблонов пишется на коленке за час максимум (код-то надо очень простой генерить, лесенки из if-ов и switch-ей получаются).

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

Все уже украдено до нас. Полно готовых аллокаторов.

свои специальные кучки внутри этих кусков, свои объекты в этих кучках и пулах (а typedef для этих объектов по историческим причинам у нас носит имя caddr_t :), свои структурки из этих объектов, специфические уже для конкретного транслятора, свои процедурки обходов этих структурок,

Какие такие процедурки? Весь этот boilerplate тривиально генерить из декларативного, высокоуровневого описания.

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

Опять же, тривиальный boilerplate. То, что всякие там компиляторы haskell делают - это вовсе не rocket science, это очень примитивное раскрытие простейших шаблонов. Такое и поверх C++ сделать элементарно.

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

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