работать с сегментами PE

с таблицей экспорта и импорта

а есть ли какие нибудь популярные статьи, посты и тексты на тему использования многопоточности при реализации компилятора?

да кстати интересная тема. C/C++ легко параллелизуется по юнитам компиляции, а вот в других компиляторах наверное что-то более сложное придумать можно

Мне тоже интересна эта тема.

Путь у меня есть N модулей, компилировать модуль X можно только при условии что все модули, от которых X зависит, уже скомпилированы (потому что для компиляции X нужен выхлоп анализа из этих модулей - контекст).

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

Потом я запускаю M воркеров, каждый из воркеров пытается достать из графа модуль, из которых нет дуг, и которые не компилируются в данный момент времени уже. Если таких нет, ждут пока граф поменяется. После начинают компилировать его с контекстом на этот момент времени, потом удаляют модуль из графа, обновляя контекст.

И так пока граф не опустеет.

и это выглядит ужасно некрасиво все

А зачем что-то с графом делать? Там же нужна топологическая сортировка и некий контроллер, который, проходя граф в топологическом порядке пускает в воркеры независимые ветки

ну, моя первая реализация была такая: я граф превращал в список этапов, где этап это список модулей, которые могут быть скомпилированы параллельно.

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

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

мне нужна не только информация об интерфейсах, нужна целиком информация после компиляции

А зачем?

там не просто компилятор, это достаточно сложный транслятор из одного языка в другой

Но и я не конкретно про твой случай, а в целом

а в общем случае да, это хорошее решение

но например первый этап сбора интерфейса тоже нельзя делать многопоточно в лоб, а тоже только по зависимостям

например если у функции не указан тип, и его нужно вывести из тела, которое использует функции из зависимостей

В си транслируешь?

нет, это в хаскель)

это рабочий проект, не то что я делаю с эрлангом

Подскажите, есть ли какой-нибудь *простой* (я смотрю на тебя, LLVM) compiler backend? Трансляцию в Си (упаси боже) не предлагать