OberonCore

Я вёл речь о мало-мальски сложных оптимизациях. А так-то и в Blackbox оптимизирующий компилятор. Разве такие оптимизации Вы имели ввиду? Да и речь шла не про хорошесть-плохость, а о "Oberon way". В применении генераторов парсеров и AST тоже ничего плохого нет.

Вот у Недори можно поинтересоваться, насколько они простые. Он, кстати, сам LLVM предпочитает использовать, и всячески его нахваливал с позиции разработчика компилятора с ноля.

Ну вот и IR - это не код RISC машины.

А чем Вы хотите транслировать IR в машинный код. Или мы ведём речь о разных IR?

То есть, с практической точки зрения, вероятность воплощения транслятора с простыми, но мощными оптимизациями можно оценить близким к 0

На любые работы нужен определённый бюджет. Либо финансовый, либо временной. Florian Klämpfl со товарищи уже вон 25-лет FreePascal пилит и вполне успешно. Кстати, без всяких LLVM и GCC обходятся.

При помощи LLVM. К хаосу детали, я не углублялся в структуру этой хрени. Но, на сколько я понимаю,
значит именно его можно генерировать, а дальше уже работа LLVM с оптимизацией и генерацией целевого кода.

Разумеется, нужен бюджет, но некоторые верят в воплотимость малыми силами.
Звучит, как демотиватор, учитывая сравнение характеристик. Я, кстати, слышал, что они хотели прикрутить LLVM, да пока не выходит.
Конечно, я и писал, что RISC VM не нужен для этой задачи. Наоборот, IR лучше подходит для промежуточной кодогенерации.

Вся индустрия может звучать, как демотиватор.

А я о чём? Стоило столько сообщений согласовывать очевидное?

Про LLVM и его минусы я уже писал. Если кто хочет можете создать отдельную тему про LLVM.

Про мощные и простые методы оптимизации. Так сразу я не скажу, какие методы позволят этого добиться. Это надо исследовать, возможно, экспериментировать. И затем только выяснится какие оптимизации дают самые существенные улучшения. А какие оптимизации дают только незначительные улучшения. Как раз такие темы и надо обсуждать, если будут желающие.

Смотря на то, о чём Вы. Как ещё понять друг друга, кроме как согласовывая? Начали мы, вроде бы, с C VS IR, а закончили RISC VS IR.

1. LLVM IR удобней для промежуточный генерации чем гипотетический LLVM IR RISC
2. Генерация в IR, заточенный под С и С++, не даст значимых преимуществ по скорости по сравнению с генерацией в С
3. Генераторы в С уже есть, генераторы в IR только будут.
4. С обладает более высокой переносимостью, чем LLVM IR

Так?

Может, уже наисследовано и наэкспериментировано? Ведь, если нет, то это тоже гора работы.

Можно взять OOC и прикрутить к нему кодогенератор в ассемблер. Насколько я понял, так вначале и планировалось.

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

А оно там, как ни странно, уже есть, хотя и не допиленное ещё. Но тоже ныли, llvm убьёт паскаль, нет стимула что-то делать, раз есть llvm.

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

Оно не заточено по С и С++, можешь хоть на ассемблере писать, хоть на обероне, оно достаточно эффективно сгенерирует код, к тому же, есть фаза оптимизации ir, есть машинная фаза оптимизации под конкретную архитектуру, какое отношение архитектура x86 имеет к С и С++?

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

Опять таки, я ФриПаскаль привёл, как пример проекта компилятора отличного от GCC и LLVM, над которым уже 25 лет работают, а не как образцовый пример компилятора.

Можно писать на чём угодно, это обеспечивает алгоритмическая полнота, но заточенность обеспечивает большую эффективность той системе, которая к ней ближе. Именно об этом речь. У системы, заточенной под ограничения Оберона больший потенциал оптимизации, чем через LLVM, поэтому, к примеру, наиболее эффективные реализации Java работают не через LLVM, несмотря на наличие последнего. Другое дело, что раскрыть этот потенциал очень трудоёмко
это нигде и не оспаривалось
Приблизительно такое же, как архитектура Reduceron имеет отношение к Haskell, но какое это имеет отношение к теме? Может быть, компиляторы Си не на LLVM не делают машинозависмых оптимизаций?

Я в будущем хотел бы задействовать LLVM, но на значимое ускорение не рассчитываю. Если Вы знаете, как нужно укладывать байтики в LLVM для Оберона, чтобы это дало существенный прирост по сравнению с Си, пожалуйста, расскажите об этом. Кисельные берега мне малоинтересны.

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

Я имел ввиду, что гипотетическая специализированная под Оберон система даёт гипотетическую же возможность оптимизировать программы на Обероне сильней, чем система, созданная для С. Это не означает, что это даёт преимущество в скорости языку. Тут играет близость языка задаче, привычкам программиста и целевой машине. Если Вы знаете о вещах в Обероне, которые положительно влияют на оптимизацию по сравнению с Си, то озвучьте их.

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