DU-Translation

Итак, что я предлагаю сделать по данному вопросу в первую очередь, а что - ни в коем случае не делать.

То, что не следует делать (по крайней мере сейчас)- это писать код, как уже было указано на семинаре. А нужно проработать следующие вопросы:

  • На каком языке пишем. То есть кто забыл/ не знал С++ (вроде меня |-[ ) - учим/вспоминаем основы объектно-ориентированного программирования.
  • Заботать систему классов Феникса. Не знаю, насколько это важно, но мне это кажется существенным. Во-первых, мы строим свою систему классов от базового класса Node (как было предложено на семинаре ), так что нужно знать свои корни. Во-вторых, чтобы не изобретать велосипед и не вставлять его в код, типа какого-нибудь своего printf() 'а вместо Phx::Output::WriteLine() (хотя у него очень забавный формат…). Всё изучить, естественно, не получится, да и не надо, достаточно знать, где что лежит, чтобы при случае ознакомиться и использовать.
  • Договориться, какой стиль написания использовать. Очень скользкий вопрос, конечно. По крайней мере необходимо, чтобы все члены проекта давали классам осмысленные имена типа DefUseDump, а не что-то вида dud31, которые другой человек не поймет. Ну а также прочие удобства, типа assert()'ов по всему коду, комментариев в достаточном количестве и т.п. Хороший образец - это шаблоны из феникса (типа c2phase), а также примеры кода из документации к нему.

Интерфейс к модулю оформляется как хэдер, его написание и есть первоочередная задача в плане кодинга.

Пока нет CVS, какие-то заготовки предлагаю писать здесь.

using namespace Graphs; // XXX Don't sure it's correct

class DU_Edge; // see below

/* Класс для представления узла def-Use Graph*/
class DU_Node: Phx::Graphs::Node
{

    protected:
        Phx::Id     Id; // ?? May be useful, may be not 
//        unsigned int     PredCount; //число связей от предков
//        Node         * Prev, * Next; // pointers to physical what?
        DU_Edge     *Edges; // all edges originating from this one node
    public:
        void     DUNode();
        void     ~DUNode();
        virtual void Dump(); // вывод отладочной информации об узле на консоль

}// DU_Node

/* For representing edges connecting our DU_Node s, both Oper_Node and Phi_Node */
class DU_Edge // XXX successor of what class?
{
    private:
    DU_Node * origin; // source of the edge
    DU_Node * destination; // to where it points
    // XXX For correctness in an implementation we should assert that types of origin and destination are the same
    // TODO Insert some useful stuff here
    // ...
    void DU_Edge(); // We prohibit creating edges without nodes, should we also proohibit a copy-construcotr?
    public:
    void DU_Edge(DU_Node orig, DU_Node dest);
    // TODO insert some stuff here...
    void ~DU_Edge();
}// DU_Edge

/* For representing basic instructions in graph*/
class Oper_Node : DU_Node
{
    private:
        CFG::Cfg_Node * LinearBlock; // I think CFG_Node contains bidirectional list itself and has methods to work with it
        Phi_Node * First_phi; // a pointer to first phi node, what you think?

    public:

}// Oper_Node

/* For representing phi-function */
class Phi_Node: DU_Node
{
    private:
    // Блин, надо знать, как устроен CFG_Node, а то непонятно, что тут писать. 
    public:

}// Phi_Node

Да, и последнее. Также прошу про все источники информации, заслуживающие внимания, упоминать здесь.
Литература

  • Bruce Eckler "Thinking In C++ vol. 1" \\natalie\incoming\! For\Thinking in C++\
  • Phoenix Documentation -> Reference -> Phx -> Namespaces -> Graphs -> Classes -> Node.
  • STL для программистов на C++, Аммерааль Л..djv , доступна на lib.mipt.ru или \\dgap-gw\lib

// GGG

За, всеми руками и ногами. Обязательно надо договориться насчет стиля кода, его коментариев и тп. Хорошим образцом может служить не только Фениксовские примеры но и также codestyle в *nixовых системах

// MICRO

Есть Cfg_Node, этот узел CFG и является линейным участком. В DU графе узлами являются операции и фи-узлы, никакого DU_Bblock'а делать не нужно. Так что DUNode должен быть родительским для OperNode и PhiNode. Вот эти классы также хорошо было бы тут отразить. А еще не забудьте про DUEdge, и про DUObj.
// dimstar


У меня есть вопросы общего характера, по стилю и средствам

  1. Используем STL для различных массивов, списков и прочего, или по старинке через Сишные указатели?
  2. Если через указатели, то какие - из VS ("галочки"), или всё же стандартные "звездочки"? Из-за этих "галочек" я не могу в другом, не от MS, компиляторе что-либо сделать - все примеры, шаблоны с этой гадостью написаны.

И еще вопрос - что такое DUObj? совсем не помню.
// GGG

STL, Managed C++ - это уж как вы сами решите, мне все равно.
Про DUObj ответил на форуме. Давай там продолжать дискуссию по этому вопросу.
// dimstar


На последнем семинаре были предложены следующие пункты, с которыми нужно разобраться для написания DU-Framework:
1. Для реализации Opcode понять, попробовать и реализовать различные инструкции: арифметические апперации/чтение и запись в массив.
2. Разобраться с аргументами инструкций (память/const/linktime const)
3. Разобраться с Symbol table
4. Разобраться с классом виртуальных регистров
5. Трансляция
6. Obj
7. Oper_Node

Предлагалось распределиться кто и что будет делать.
// wonder

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-Share Alike 2.5 License.