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

[Вячеслав Козырев]

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

Полагаю, да.

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

Старался как раз придумать так, чтобы задачи были более-менее независимыми.

19 марта 2018 г., 20:48 пользователь Eugene Sharygin <eush at ispras.ru> написал:
> Вячеслав Козырев <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.