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

[Eugene Sharygin]

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

> Похоже, примерный план на ближайшие две недели следующий.
>
> В QBE закидывается куча проходов в нужном порядке, один человек это парсит и
> дает второму, второй запускает их по очереди. Третий пишет интерфейс
> реализации прохода,

Входит ли сюда интерфейс доступа к результатам анализов?

> а четвертый - его спецификацию в виде прохода, который просто печатает
> в файл функцию (для тестирования работоспособности).

Есть ли между этими задачами зависимости, или все четверо готовы начать
одновременно?

> После этого, в зависимости от затраченного на вышесказанное времени, можно
> реализовать более интеллектуальный пайплайн с зависимостями от других
> проходов. И одну неделю потратить на реализацию динамических библиотек.
>
> 18 Мар 2018 г. 21:02 пользователь "Eugene Sharygin" <eush at ispras.ru> написал:
>
>     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.
>

--
Regards,
Eugene Sharygin,
ISP RAS.