[plug] [обсуждение плана]

[Vladislav Ivanishin]

Добрый день,

Вячеслав Козырев <weautify at gmail.com> writes:

> Начну, пожалуй.
>
> Первое, что стоит сказать, есть проблема, связанная с тем, что без
> механизма подключения плагинов работа над собственно плагинами
> несколько осложняется. Однако больше двух человек работать над ним,
> пожалуй, не смогут - это будет перебор.
> Поэтому предлагается взять двум человечкам работы над механизмом
> подключения плагинов, а двум другим тем временем отдельно заниматься
> плагинами с поправкой на то, чтобы плагины работали сами по себе (как
> в работе по курсу "конструирование компиляторов"). Затем, когда работа
> над механизмом подключения плагинов будет закончена, можно начинать
> нормально оформлять плагины и делать новые уже сразу плагинами.
> Вопрос, как распределить работу на этом этапе практикума, остаётся
> открытым.
>
> Мне хочется заниматься подключением плагинов поначалу, и считаю, что
> на это можно отвести две недели - их должно быть более чем достаточно.
> После этого все будут заниматься сборкой плагинов. Вопрос, какие
> плагины реализовать, остаётся открытым.

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

Обычно соглашения для плагинов выглядят примерно так. Плагин собирается
как динамическая библиотека, и в нём обязательно определена функция (или
несколько) с известным именем, например, `onload'. А qbe должен
научиться в командной строке распознавать что-нибудь вроде
-plug=path-to-plugin.so (может быть и что-то более сложное, к примеру,
плагин может принимать параметры, тогда они должны задаваться там же --
интерфейс вам надо продумать). Соответственно, если в командной строке
такое встретилось, то в какой-то момент qbe должен вызвать
dlopen(path_to_plugin,...), затем dlsym(..., "onload") и вызвать
полученную функцию по указателю. Функция же onload в плагине может
использовать интерфейсы из all.h. Как-то так всё срастается.

На самом деле, это упрощённое описание интерфейса. К примеру, вы хотите
иметь какой-то оптимизационный проход в виде плагина. Если все действия
производить в `onload', получится, что qbe должен знать, в какой именно
момент вызывать onload (при том, что он не должен знать наперёд, какие
плагины будут написаны). Поэтому нужна какая-то система хуков. Например,
onload будет вызываться достаточно рано и куда-то записывать callback'и,
которые qbe вызовет, когда придёт время. А время придёт, когда наступит
какое-то событие (например, завершится проход с определённым именем,
которое задаёт плагин). Таким образом, в вашу задачу входит определение
набора событий, где будут расставлены хуки, и патчинг qbe
соответствующим образом.

В qbe (когда он используется не как библиотека, а как компилятор)
выполняется ряд проходов (см. main.c). Возможно, есть смысл переписать
их вызовы в новой концепции, т.е. определить единый интерфейс для всех
этих проходов и добавить менеджер проходов.

> И ещё. Не уверен, как должны работать плагины. Делается, например,
> анализ gen-kill переменных. Результатом его работы должен быть
> текстовый файл наподобие вывода в курсе "конструирование
> компиляторов", или файл с некими структурами, или он должен как-либо
> передаваться в следующий за ним проход?

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

См. сообщение Евгения [1]:
> Это потребует отделения в каком-то виде основной функциональности
> прохода от ввода/вывода, чтобы можно было программно пользоваться
> результатами анализов и запускать цепочки оптимизаций без
> промежуточного сохранения и восстановления через текстовые файлы.

Вся соль как раз в том, что qbe будет вызываться один раз. Если
передавать информацию через текстовые файлы, в принципе уже сейчас
возможно написать конвейер, который будет запускать разные программы,
использующие libqbe, одну за другой и достигать какого-то суммарного
эффекта.

> Это тоже достаточно важно обсудить сейчас, потому что на основе этого
> будет понятно, как реализовывать подключение плагинов и их вывод
> внутри "qbe".

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

[1]: https://compilers.ispras.ru/pipermail/prac-sp-18/2018/000023.html

-- 
Влад