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

[Eugene Sharygin]

Vladislav Ivanishin <vlad at ispras.ru> writes:

> Привет!
>
> Eugene Sharygin <eush at ispras.ru> writes:
>
>> Привет,
>>
>> 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). Пожалуй, для целей курса это было бы
>> даже полезнее.
>
> Да, это основное. Я не подумал, что в func() в main.c проходы IR -> asm
> тоже вызываются. Тогда единым интерфейсом все из них объединять наверное
> не стоит.
>
> Если делать новый отдельный пайплан для IR -> IR преобразований, там не
> будет предустановленных проходов, и все преобразования должны будут
> предоставляться плагинами?

Можно и с предустановленными (-O0, -O1), но я думаю, что основным
вариантом использования пока можно считать изначально пустой пайплайн, в
который все проходы добавляются пользователем.

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

--
Regards,
Eugene Sharygin,
ISP RAS.