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

[Eugene Sharygin]

Привет,

Vladislav Ivanishin <vlad at ispras.ru> writes:

> Добрый день,
>
> Вячеслав Козырев <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). Возможно, есть смысл переписать
> их вызовы в новой концепции, т.е. определить единый интерфейс для всех
> этих проходов и добавить менеджер проходов.

Было бы хорошо иметь не только интерфейс, позволяющий встраиваться в
основной пайплайн QBE (IR -> Asm), но и возможность запустить цепочку
проходов в отдельности (IR -> IR). Пожалуй, для целей курса это было бы
даже полезнее.

--
Regards,
Eugene Sharygin,
ISP RAS.