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

[Vladislav Ivanishin]

Привет!

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 преобразований, там не
будет предустановленных проходов, и все преобразования должны будут
предоставляться плагинами? И тогда можно обойтись без набора событий, а
порядок вызова проходов будет определяться порядком следования плагинов
в командной строке.

-- 
Влад