OberonCore

Некоторые участники форума создали компиляторы/трансляторы/интерпретаторы различных модификаций Оберона. То, что компиляторы работают, уже большое достижение. Но по производительности они часто проигрывают, так как там бывают реализованы очень простые методы. Хорошо бы создать оптимизирующий компилятор, который будет оптимизировать какие-то критерии: скорость работы, размер программы, энерго-эффективность программы и другие. Вообще тема оптимизаций довольно большая и сложная и хотелось бы найти единомышленников, которым также было бы интересно разбираться в теме оптимизирующих компиляторов. Если вам эта тема интересна, то пишите в теме или в личку и обсудим, как можно совместно изучать эту тему.

Оптимизации это обман.

Давно надо уже брать и делать, а не в очередной раз обсуждать. :)
Что имеет смысл допиливать кроме более продвинутой аллокации регистров и выпиливания по пути дублирующихся [под]выражений, кроме стандартных оптимизаций которые есть уже почти в любом компиляторе оберона?

Тут как с раскраской синтаксиса: хорошо бы иметь возможность сказать, вот, мол, было целых три проекта, но никто не пользуется, поэтому они заброшены ))

На уровне ЧТО надо сделать всё понятно. Да, надо распределение регистров, удаление общих подвыражений и так далее. Хотелось бы еще понимать КАК это реализовать. Надо преобразовать программы в SSA форму, затем оптимизировать SSA форму, возникает много вопросов КАК это реализовать. Хотелось бы найти ещё желающих изучать тему КАК можно реализовать оптимизации и совместно изучать эту тему.

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

Да, вот что-то такое для начала.

На этом как начнется, так и закончится. Допустим, сделали под LLVM, что-то он там оптимиризует. Получится зависимость от него. И LLVM написан на C++, то есть требуется компилятор C++ в любом случае. Спрашивается, зачем тогда компилятор Оберона, если есть компилятор C++.

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

Это реанимация темы 2-х летней давности - Машинно-независимая оптимизация кода?

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

Кто-то хочет прикрутить LLVM. Желание понятное, но это немного не соответствует Oberon way. Например, для парсинга Oberon кода можно взять какой-нибудь мощный генератор парсеров: ANTLR, Bison. Разобраться как их использовать, написать грамматику Оберона и автоматически сгенерировать парсер. Но так практически никто не делает, потому что есть Oberon way, который гласит, что мы не будет переусложнять грамматику и сможем парсить простыми методами типа рекурсивного спуска. Также и с LLVM - это мощный оптимизатор, который написан на C++, учитывает при оптимизациях модель памяти языка C++. Исходники LLVM в архиве занимают 27 мегабайт, а после распаковки 272 мегабайта C++ кода и различных конфиг файлов. Хотелось бы также как и с парсингом найти Oberon way. Реализовать какие-нибудь простые, но мощные алгоритмы, которые не тянут за собой горы непонятно чего.

LLVM имеет нехорошую манеру менять интерфейсы с каждой новой версией.

"Oberon way" для оптимизаций генерируемого кода давно найден - не делать оптимизацию.
Есть такие?

Лишнее промежуточное звено в виде Си. LLVM IR, насколько я понимаю, это RISC виртуальная машина. Генерировать RISC вполне можно, взяв и подправив хотя бы компилятор из Project Oberon. Или там без привязки к библиотекам LLVM ничего сделать нельзя?

В книге Вирта "Построение компилятора" есть целая глава посвященная оптимизации. Там говорится о том, что надо соизмерять усложнение компилятора от реализации поддержки оптимизаций и выгоду от оптимизации кода. Но не говорится о том, что все оптимизации плохи.


Для начала можно сделать что-то похожее на Перенацеливаемый оптимизирующий Модула-2/Оберон-2 компилятор. Насколько я знаю исходники закрыты, но могут быть открыты за 50 кило евро (где-то на форуме была такая инфа).

Были бы все плохи — вопроса не было бы.

Лишнее для чего? Если речь шла о
То это правда. Есть много таких оптимизирующих* трансляторов Оберона, которые заброшены.
Если речь идёт о том, чтобы добиться большей производительности, то вряд ли llvm сильно поможет, так как заточен под языки уровня С++. Для языков с другой моделью, например, Java, он подходит хуже. То есть, хотите или нет, а лишнее звено в виде С, там всё равно есть, пусть и виртуальное. Тут я согласен с Рифатом. Вообще, идея универсального независящего от языка промежуточного представления ложна.

Всё там можно без привязок. IR - это не RISC виртуальная машина, но это и не нужно.

За 50K вам его модернизировать могут до нужной архитектуры, а не исходники отдать.

Неправильно выразился, Intermediate Representation. Но при чём тут тогда: если речь идёт о RISC-образном Intermediate Representation?

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