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

Mon Mar 19 22:38:18 MSK 2018

Вячеслав Козырев <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.