<div dir="auto"><div dir="auto">Похоже, примерный план на ближайшие две недели следующий.</div><div dir="auto"><br></div>В QBE закидывается куча проходов в нужном порядке, один человек это парсит и дает второму, второй запускает их по очереди. Третий пишет интерфейс реализации прохода, а четвертый - его спецификацию в виде прохода, который просто печатает в файл функцию (для тестирования работоспособности).<div dir="auto"><br><div dir="auto">После этого, в зависимости от затраченного на вышесказанное времени, можно реализовать более интеллектуальный пайплайн с зависимостями от других проходов. И одну неделю потратить на реализацию динамических библиотек.</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">18 Мар 2018 г. 21:02 пользователь "Eugene Sharygin" <<a href="mailto:eush@ispras.ru">eush@ispras.ru</a>> написал:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="elided-text">Vladislav Ivanishin <<a href="mailto:vlad@ispras.ru">vlad@ispras.ru</a>> writes:<br>
<br>
> Привет!<br>
><br>
> Eugene Sharygin <<a href="mailto:eush@ispras.ru">eush@ispras.ru</a>> writes:<br>
><br>
>> Привет,<br>
>><br>
>> Vladislav Ivanishin <<a href="mailto:vlad@ispras.ru">vlad@ispras.ru</a>> writes:<br>
>><br>
>>> Добрый день,<br>
>>><br>
>>> Вячеслав Козырев <<a href="mailto:weautify@gmail.com">weautify@gmail.com</a>> writes:<br>
>>><br>
>>>> Начну, пожалуй.<br>
>>>><br>
>>>> Первое, что стоит сказать, есть проблема, связанная с тем, что без<br>
>>>> механизма подключения плагинов работа над собственно плагинами<br>
>>>> несколько осложняется. Однако больше двух человек работать над ним,<br>
>>>> пожалуй, не смогут - это будет перебор.<br>
>>>> Поэтому предлагается взять двум человечкам работы над механизмом<br>
>>>> подключения плагинов, а двум другим тем временем отдельно заниматься<br>
>>>> плагинами с поправкой на то, чтобы плагины работали сами по себе (как<br>
>>>> в работе по курсу "конструирование компиляторов"). Затем, когда работа<br>
>>>> над механизмом подключения плагинов будет закончена, можно начинать<br>
>>>> нормально оформлять плагины и делать новые уже сразу плагинами.<br>
>>>> Вопрос, как распределить работу на этом этапе практикума, остаётся<br>
>>>> открытым.<br>
>>>><br>
>>>> Мне хочется заниматься подключением плагинов поначалу, и считаю, что<br>
>>>> на это можно отвести две недели - их должно быть более чем достаточно.<br>
>>>> После этого все будут заниматься сборкой плагинов. Вопрос, какие<br>
>>>> плагины реализовать, остаётся открытым.<br>
>>><br>
>>> В принципе, реализация чего-либо как плагина должна быть<br>
>>> простой. Т.е. нужно просто взять имеющийся проход (из домашнего задания)<br>
>>> и воспользоваться интерфейсом, который нужно создать.<br>
>>><br>
>>> Обычно соглашения для плагинов выглядят примерно так. Плагин собирается<br>
>>> как динамическая библиотека, и в нём обязательно определена функция (или<br>
>>> несколько) с известным именем, например, `onload'. А qbe должен<br>
>>> научиться в командной строке распознавать что-нибудь вроде<br>
>>> -plug=path-to-plugin.so (может быть и что-то более сложное, к примеру,<br>
>>> плагин может принимать параметры, тогда они должны задаваться там же --<br>
>>> интерфейс вам надо продумать). Соответственно, если в командной строке<br>
>>> такое встретилось, то в какой-то момент qbe должен вызвать<br>
>>> dlopen(path_to_plugin,...), затем dlsym(..., "onload") и вызвать<br>
>>> полученную функцию по указателю. Функция же onload в плагине может<br>
>>> использовать интерфейсы из all.h. Как-то так всё срастается.<br>
>>><br>
>>> На самом деле, это упрощённое описание интерфейса. К примеру, вы хотите<br>
>>> иметь какой-то оптимизационный проход в виде плагина. Если все действия<br>
>>> производить в `onload', получится, что qbe должен знать, в какой именно<br>
>>> момент вызывать onload (при том, что он не должен знать наперёд, какие<br>
>>> плагины будут написаны). Поэтому нужна какая-то система хуков. Например,<br>
>>> onload будет вызываться достаточно рано и куда-то записывать callback'и,<br>
>>> которые qbe вызовет, когда придёт время. А время придёт, когда наступит<br>
>>> какое-то событие (например, завершится проход с определённым именем,<br>
>>> которое задаёт плагин). Таким образом, в вашу задачу входит определение<br>
>>> набора событий, где будут расставлены хуки, и патчинг qbe<br>
>>> соответствующим образом.<br>
>>><br>
>>> В qbe (когда он используется не как библиотека, а как компилятор)<br>
>>> выполняется ряд проходов (см. main.c). Возможно, есть смысл переписать<br>
>>> их вызовы в новой концепции, т.е. определить единый интерфейс для всех<br>
>>> этих проходов и добавить менеджер проходов.<br>
>><br>
>> Было бы хорошо иметь не только интерфейс, позволяющий встраиваться в<br>
>> основной пайплайн QBE (IR -> Asm), но и возможность запустить цепочку<br>
>> проходов в отдельности (IR -> IR). Пожалуй, для целей курса это было бы<br>
>> даже полезнее.<br>
><br>
> Да, это основное. Я не подумал, что в func() в main.c проходы IR -> asm<br>
> тоже вызываются. Тогда единым интерфейсом все из них объединять наверное<br>
> не стоит.<br>
><br>
> Если делать новый отдельный пайплан для IR -> IR преобразований, там не<br>
> будет предустановленных проходов, и все преобразования должны будут<br>
> предоставляться плагинами?<br>
<br>
</div>Можно и с предустановленными (-O0, -O1), но я думаю, что основным<br>
вариантом использования пока можно считать изначально пустой пайплайн, в<br>
который все проходы добавляются пользователем.<br>
<div class="quoted-text"><br>
> И тогда можно обойтись без набора событий, а<br>
> порядок вызова проходов будет определяться порядком следования плагинов<br>
> в командной строке.<br>
<br>
--<br>
</div><div class="elided-text">Regards,<br>
Eugene Sharygin,<br>
ISP RAS.<br>
</div></blockquote></div><br></div>