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

[Eugene Sharygin]

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