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

Mon Mar 19 22:26:19 MSK 2018

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

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

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.