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

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

>>Я правильно понимаю, что третий работает над интерфейсом, который будут
использовать плагины, а четвёртый - над интерфейсом, который плагины
будут предоставлять?
Не думал о таком изначально. Да, именно так.

Тогда я думаю взять интерфейс, который будут использовать плагины, и
постараюсь его реализовать за две недели. Что делать дальше, будет
видно по ходу дел.
Так как общий план по крайней мере на ближайшие две недели считай
обсуждён, может быть пора сказать, кто за что хочет быть
ответственным?

19 марта 2018 г., 22:38 пользователь Eugene Sharygin <eush at ispras.ru> написал:
> Вячеслав Козырев <weautify at gmail.com> writes:
>
>>>>... как второй и в особенности четвёртый могут начать что-то делать, пока
>> третий не завершил с интерфейсом?
>>
>> Через договорённость о методах, которые реализует третий, и их использовании.
>
> Я правильно понимаю, что третий работает над интерфейсом, который будут
> использовать плагины, а четвёртый - над интерфейсом, который плагины
> будут предоставлять?
>
>> На самом деле я не против, чтобы над интерфейсом работали двое, потому
>> что задача относительно трудоёмкая, и её реализация сильно сказывается
>> на общем состоянии выполнения работы. Если так можно, я только за.
>
> Если вы считаете, что целесообразно, чтобы над какой-то задачей работали
> двое, могут работать и двое.
>
>> 19 марта 2018 г., 22:16 пользователь Eugene Sharygin <eush at ispras.ru> написал:
>>> Вячеслав Козырев <weautify at gmail.com> writes:
>>>
>>>> 19 марта 2018 г., 20:48 пользователь Eugene Sharygin <eush at ispras.ru> написал:
>>>>> Вячеслав Козырев <weautify at gmail.com> writes:
>>>>>
>>>>>> Похоже, примерный план на ближайшие две недели следующий.
>>>>>>
>>>>>> В QBE закидывается куча проходов в нужном порядке, один человек это парсит и
>>>>>> дает второму, второй запускает их по очереди. Третий пишет интерфейс
>>>>>> реализации прохода,
>>>>>
>>>>> Входит ли сюда интерфейс доступа к результатам анализов?
>>>>
>>>> Полагаю, да.
>>>>
>>>>>> а четвертый - его спецификацию в виде прохода, который просто печатает
>>>>>> в файл функцию (для тестирования работоспособности).
>>>>>
>>>>> Есть ли между этими задачами зависимости, или все четверо готовы начать
>>>>> одновременно?
>>>>
>>>> Старался как раз придумать так, чтобы задачи были более-менее независимыми.
>>>
>>> Если задача третьего - разработать интерфейс (набор сигнатур методов),
>>> задача второго - эти методы вызвать из кода 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.
>>>
>>> --
>>> Regards,
>>> Eugene Sharygin,
>>> ISP RAS.
>
> --
> Regards,
> Eugene Sharygin,
> ISP RAS.