Open-Source Projects: Issueshttps://forge.ispras.ru/https://forge.ispras.ru/favicon.ico?16490126692018-06-09T11:26:06ZOpen-Source Projects
Redmine MicroTESK - Feature #8939 (Closed): [autogen] New option 'base-template-path' must be supported.https://forge.ispras.ru/issues/89392018-06-09T11:26:06ZAndrei Tatarnikovandrewt@ispras.ru
<p>A new option 'base-template-path' (<code>--base-template-path</code> or <code>-btp</code>) was established.<br />It specifies the path to the base template file.<br />This must be supported in Template Generator.</p> MicroTESK - Task #8481 (New): Need a way to specify the termination address for the test programhttps://forge.ispras.ru/issues/84812017-10-05T07:38:41ZAndrei Tatarnikovandrewt@ispras.ru
<p>When generation is finished MicroTESK checks whether the execution reaches the end of the program.<br />Currently, MicroTESK considers the end of the program to be the last instruction of the last sequence (e.g. the program's epilogue).<br />However, the end of epilogue might contain some supplementary code that does not necessarily executed last (handlers, termination for different PEs).<br />In such cases, MicroTESK mistakenly says that execution cannot reach the termination point. This causes generation to fail.</p>
<p>To avoid such situation, there must be a way to explicitly specify the termination point for each PE.<br />It can be a special pseudo instruction that marks the termination point or a way to specify the termination address for a PE.</p> TestBase - Bug #7759 (Closed): Avoid using lambda functionshttps://forge.ispras.ru/issues/77592016-11-28T13:25:42ZAndrei Tatarnikovandrewt@ispras.ru
<p>Использование lambda-функций (<a href="http://forge.ispras.ru/projects/testbase/repository/revisions/50f3ae809bbfc504fc7745eee8b626a5e7f4b019/entry/src/main/java/ru/ispras/testbase/storage/SQLiteStorage/db/dao/FormulaDAO.java" class="external">как здесь</a>) в реализации нежелательно. Они не поддерживаются в Java 1.7, которая сейчас используется для сборки всех проектов.</p> MicroTESK - Task #7678 (New): Generation of LLVM configuration files from nML specificationshttps://forge.ispras.ru/issues/76782016-11-04T08:41:14ZAndrei Tatarnikovandrewt@ispras.ru
<p>Subject. To solve this task, you need implement an extension in Java that will traverse nML IR and generated the required files.</p>
<p>Such extensions implement the <code>TranslatorHandler</code> interface and are registered in the constuctor of the <code>NmlTranslator</code> class (see the code fragment below).</p>
<pre><code class="java syntaxhl" data-language="java"><span class="kd">public</span> <span class="kd">final</span> <span class="kd">class</span> <span class="nc">NmlTranslator</span> <span class="kd">extends</span> <span class="nc">Translator</span><span class="o"><</span><span class="nc">Ir</span><span class="o">></span> <span class="o">{</span>
<span class="kd">private</span> <span class="kd">static</span> <span class="kd">final</span> <span class="nc">Set</span><span class="o"><</span><span class="nc">String</span><span class="o">></span> <span class="no">FILTER</span> <span class="o">=</span> <span class="nc">Collections</span><span class="o">.</span><span class="na">singleton</span><span class="o">(</span><span class="s">".nml"</span><span class="o">);</span>
<span class="kd">public</span> <span class="nf">NmlTranslator</span><span class="o">()</span> <span class="o">{</span>
<span class="kd">super</span><span class="o">(</span><span class="no">FILTER</span><span class="o">);</span>
<span class="n">getSymbols</span><span class="o">().</span><span class="na">defineReserved</span><span class="o">(</span><span class="nc">NmlSymbolKind</span><span class="o">.</span><span class="na">KEYWORD</span><span class="o">,</span> <span class="nc">ReservedKeywords</span><span class="o">.</span><span class="na">JAVA</span><span class="o">);</span>
<span class="n">getSymbols</span><span class="o">().</span><span class="na">defineReserved</span><span class="o">(</span><span class="nc">NmlSymbolKind</span><span class="o">.</span><span class="na">KEYWORD</span><span class="o">,</span> <span class="nc">ReservedKeywords</span><span class="o">.</span><span class="na">RUBY</span><span class="o">);</span>
<span class="c1">// Detects parent-child connections between primitives</span>
<span class="n">addHandler</span><span class="o">(</span><span class="k">new</span> <span class="nc">ReferenceDetector</span><span class="o">());</span>
<span class="c1">// Adds the list of root operations to IR </span>
<span class="n">addHandler</span><span class="o">(</span><span class="k">new</span> <span class="nc">RootDetector</span><span class="o">());</span>
<span class="n">addHandler</span><span class="o">(</span><span class="k">new</span> <span class="nc">ArgumentModeDetector</span><span class="o">());</span>
<span class="n">addHandler</span><span class="o">(</span><span class="k">new</span> <span class="nc">BranchDetector</span><span class="o">());</span>
<span class="n">addHandler</span><span class="o">(</span><span class="k">new</span> <span class="nc">MemoryAccessDetector</span><span class="o">());</span>
<span class="n">addHandler</span><span class="o">(</span><span class="k">new</span> <span class="nc">Analyzer</span><span class="o">(</span><span class="k">this</span><span class="o">));</span>
<span class="n">addHandler</span><span class="o">(</span><span class="k">new</span> <span class="nc">PrimitiveSyntesizer</span><span class="o">(</span><span class="k">this</span><span class="o">));</span>
<span class="n">addHandler</span><span class="o">(</span><span class="k">new</span> <span class="nc">ExceptionDetector</span><span class="o">());</span>
<span class="c1">// Generate Java code of the ISA model</span>
<span class="n">addHandler</span><span class="o">(</span><span class="k">new</span> <span class="nc">MetaDataGenerator</span><span class="o">(</span><span class="k">this</span><span class="o">));</span>
<span class="n">addHandler</span><span class="o">(</span><span class="k">new</span> <span class="nc">Generator</span><span class="o">(</span><span class="k">this</span><span class="o">));</span>
<span class="o">}</span>
</code></pre>
<p>All these handlers are examples of how to implement logic traversing IR. Some of them perform analysis and some generate code. Code generation is done using the <a href="http://www.stringtemplate.org/" class="external">StringTemplate</a> library (STG files + java classes).</p>
<p>To traverse the IR, the following classes and interfaces can be used: <code>IrVisitor</code>, <code>IrVisitorDefault</code> and <code>IrWalker</code> (or its variations <code>IrWalkerFlow</code>, <code>IrWalkerShortcuts</code>) defined in the <code>ru.ispras.microtesk.translator.nml.ir</code> package. You need to implement <code>IrVisitor</code> (use <code>IrVisitorDefault</code> as default implementation with empty methods) and pass it to the most suitable walker. <em>NOTE: implementation of IR walker and visitor is raw and a subject to improvements. Any questions/feedback are appreciated.</em></p>
<p>Expressions require using a separate walker and visitor implemented in Fortress: <code>ExprTreeVisitor</code>, <code>ExprTreeVisitorDefault</code> and <code>ExprTreeWalker</code> (<code>ru.ispras.fortress.expression</code>). Examples of using them you can find both in MicroTESK and in Fortress.</p> MicroTESK - Bug #7603 (New): List of plug-ins must be stored in etc/settings.xmlhttps://forge.ispras.ru/issues/76032016-10-11T15:49:53ZAndrei Tatarnikovandrewt@ispras.ru
<p>List of MicroTESK plugins is stored in config.xml included in JAR's resources. As a result, it cannot be modified. The format of config.xml looks like this:</p>
<pre>
<config>
<plugin class="ru.ispras.microtesk.mmu.MmuPlugin"/>
</config>
</pre>
<p>This information must be stored in etc/settings.xml.</p> MicroTESK - Bug #7418 (Closed): Reset the state of the model before starting generating a new tes...https://forge.ispras.ru/issues/74182016-07-22T13:16:48ZAndrei Tatarnikovandrewt@ispras.ru
<p>When MicroTESK processes a test template, it may place the generated test cases into multiple files.<br />When generation of a new file starts, MicroTESK must reset the state of the model (registers and memory including all MMU buffers).</p> MicroTESK - Bug #6911 (New): The "get_address_of" method must work with all label types.https://forge.ispras.ru/issues/69112016-03-01T08:49:06ZAndrei Tatarnikovandrewt@ispras.ru
<p>Currently, it is limited to labels defined in global data sections. It must support all kinds of label. It should return a lazy value instead of a constant.</p> MicroTESK - Bug #5990 (New): Memory state must be taken into account when generating test datahttps://forge.ispras.ru/issues/59902015-05-27T08:46:50ZAndrei Tatarnikovandrewt@ispras.ru
<p>Data defined in <code>data{...}</code> blocks (global data) must be taken into account when generating test data.<br />Now the test data generator does not see data placed into memory outside of the current test template block.</p> MicroTESK - Task #5674 (Rejected): Description of test data generation mechanisms (test situation...https://forge.ispras.ru/issues/56742015-03-03T08:59:36ZAndrei Tatarnikovandrewt@ispras.ru
<p>Subj. Need public documentation on this.</p> MicroTESK - Task #5670 (Closed): Examples of test templates using memory-related test situations ...https://forge.ispras.ru/issues/56702015-03-03T08:04:19ZAndrei Tatarnikovandrewt@ispras.ru
<p>Examples must be created an published.</p> MicroTESK - Task #5666 (Closed): Estimate generation speedhttps://forge.ispras.ru/issues/56662015-03-03T07:38:30ZAndrei Tatarnikovandrewt@ispras.ru
<p>Performance benchmarks and corresponding examples are needed.</p> MicroTESK - Task #5639 (Closed): Code review notes (package ru.ispras.unitesk.processor.test.mmu)https://forge.ispras.ru/issues/56392015-02-17T09:45:17ZAndrei Tatarnikovandrewt@ispras.ru
<strong>Общие замечания</strong>
<ol>
<li>Все неизменяемые поля классов (которые присваиваются единыжды в конструкторе или объявлении) должны быть final.</li>
<li>В методах, изменяющих сосотояние объекта, вида addXXX и setXXX должны быть проверки на то, что передаваемые им параметры валидны. В первую очередь не равны нулю. А то после их добавления в коллекцию, будем долго искать откуда пришли невалидные значения.</li>
<li>То же самое (п. 2) касается и конструкторов.</li>
<li>В контексте (п. 1) обратить внимание на утилитные методы Collections.unmodifiableList, Collections.unmodifiableMap и т.д. Они создают обертки, гарантирующие, что состояние коллекций будет неизменным.</li>
<li>Обратить внимание на метод toString. Он может очень помочь при отладке. Он сейчас нигде не реализован.</li>
<li>Из-за того, что позволяется создавать невалидные объекты (п. 2 и 3), везде куча проверок на null (ненужных), что затрудняет понимание кода.</li>
<li><strong>Почему столько много mutable классов?</strong> Они создаются и инициализуруются только один раз. Насколько я вижу, их дальнейшее использование не предполагает изменение состояния. Объект создается постым (или попросту невалидным), а затем инициализируется методами setXXX, addXXX. А конструкторы, фабричные методы, паттерн Builder не используются. А можно было бы сразу создать хороший, валидный объект, неизменяемый объект и не думать где он может измениться или могут ли его методы вернуть null, пустую коллекцию или другие невалидные данные.</li>
<li>Использование null для специальных случаев - не самая лучшая практика. Для пользователей класса может быть неочевидно что значит null. Может, имеет смысл сделать MmuGuard.GOTO или MmuGuard.UNCONDITIONAL. <br /><pre><code class="java syntaxhl" data-language="java"><span class="cm">/** The guard condition or {@code null} if the transition is interpreted as {@code goto}. */</span>
<span class="kd">private</span> <span class="nc">MmuGuard</span> <span class="n">guard</span><span class="o">;</span>
</code></pre></li>
</ol>
<strong>Класс Mmu</strong>
<ol>
<li>Метод getExecutions</li>
<ul>
<li>Суффикс List в названиях переменных ИМХО избыточен. В названиях переменных-членов мы его не используем. Тип переменной и так виден, особенно если метод короткий. Это на заметку.</li>
<li>Здесь удобнее сделать return сразу и не городить городушку из вложенных блоков: <br /><pre><code class="java syntaxhl" data-language="java"><span class="k">if</span> <span class="o">(</span><span class="n">transitionList</span> <span class="o">!=</span> <span class="kc">null</span> <span class="o">&&</span> <span class="o">!</span><span class="n">transitionList</span><span class="o">.</span><span class="na">isEmpty</span><span class="o">())</span> <span class="o">{</span></code></pre><br />И вообще в каком случае это проиcходит? Такое состояние валидное? Почему мы его просто игнорируем?</li>
</ul></li>
</ol>
<ul>
<li>Класс MmuAction</li>
<li>Реализация метода equals: <br /><pre><code class="java syntaxhl" data-language="java"><span class="nd">@Override</span>
<span class="kd">public</span> <span class="kt">boolean</span> <span class="nf">equals</span><span class="o">(</span><span class="kd">final</span> <span class="nc">Object</span> <span class="n">o</span><span class="o">)</span> <span class="o">{</span>
<span class="k">if</span> <span class="o">(</span><span class="n">o</span> <span class="o">==</span> <span class="kc">null</span> <span class="o">||</span> <span class="o">!(</span><span class="n">o</span> <span class="k">instanceof</span> <span class="nc">MmuAction</span><span class="o">))</span> <span class="o">{</span>
<span class="k">return</span> <span class="kc">false</span><span class="o">;</span>
<span class="o">}</span>
<span class="kd">final</span> <span class="nc">MmuAction</span> <span class="n">r</span> <span class="o">=</span> <span class="o">(</span><span class="nc">MmuAction</span><span class="o">)</span> <span class="n">o</span><span class="o">;</span>
<span class="k">return</span> <span class="n">name</span><span class="o">.</span><span class="na">equals</span><span class="o">(</span><span class="n">r</span><span class="o">.</span><span class="na">name</span><span class="o">);</span>
<span class="o">}</span>
</code></pre> Нет проверки o == this (стандартное сравнение). В данном случае это мелочь, а в более сложных объектах - это накладные рассходы.</li>
</ul>
<ul>
<li>Класс MmuConflict</li>
<ol>
<li>А количество возможных конфликтов конечно? А почему так, а не через enum: <br /><pre><code class="java syntaxhl" data-language="java"><span class="c1">// Address no equal.</span>
<span class="kd">public</span> <span class="kd">static</span> <span class="kd">final</span> <span class="nc">String</span> <span class="no">NO_EQUAL</span> <span class="o">=</span> <span class="s">"NoEqual"</span><span class="o">;</span>
<span class="c1">// Address equal.</span>
<span class="kd">public</span> <span class="kd">static</span> <span class="kd">final</span> <span class="nc">String</span> <span class="no">EQUAL</span> <span class="o">=</span> <span class="s">"Equal"</span><span class="o">;</span>
<span class="c1">// Index1 != Index2.</span>
<span class="kd">public</span> <span class="kd">static</span> <span class="kd">final</span> <span class="nc">String</span> <span class="no">INDEX_NO_EQUAL</span> <span class="o">=</span> <span class="s">"IndexNoEqual"</span><span class="o">;</span>
<span class="c1">// Index1 == Index2 && Tag1 != Tag2.</span>
<span class="kd">public</span> <span class="kd">static</span> <span class="kd">final</span> <span class="nc">String</span> <span class="no">TAG_NO_EQUAL</span> <span class="o">=</span> <span class="s">"TagNoEqual"</span><span class="o">;</span>
<span class="c1">// Index1 == Index2 && Tag1 != Tag2 && Tag1 == Replaced2.</span>
<span class="kd">public</span> <span class="kd">static</span> <span class="kd">final</span> <span class="nc">String</span> <span class="no">TAG_REPLACED</span> <span class="o">=</span> <span class="s">"TagReplaced"</span><span class="o">;</span>
<span class="c1">// Index1 == Index2 && Tag1 != Tag2 && Tag1 != Replaced2.</span>
<span class="kd">public</span> <span class="kd">static</span> <span class="kd">final</span> <span class="nc">String</span> <span class="no">TAG_NO_REPLACED</span> <span class="o">=</span> <span class="s">"TagNoReplaced"</span><span class="o">;</span>
<span class="c1">// Index1 == Index2 && Tag1 == Tag2.</span>
<span class="kd">public</span> <span class="kd">static</span> <span class="kd">final</span> <span class="nc">String</span> <span class="no">TAG_EQUAL</span> <span class="o">=</span> <span class="s">"TagEqual"</span><span class="o">;</span>
</code></pre></li>
</ol></li>
</ul> MicroTESK - Task #5403 (Closed): Test sequence generation logic (blocks, combinators, compositors...https://forge.ispras.ru/issues/54032014-10-31T15:44:13ZAndrei Tatarnikovandrewt@ispras.ru
<p>Необходимо проработать логику генерации тестовых последовательностей (блоки и комбинаторы/композиторы). Необходимо:</p>
<ol>
<li>Уточнение требований</li>
<li>Реализация</li>
<li>Примеры</li>
<li>Документация</li>
</ol>
<p>Следующие случаи должны быть проработаны:</p>
<ol>
<li>atomic { I1, ..., In } - возвращает итератор, который возвращает одну единственную последовательность.</li>
<li>atomic { I1, ..., In, block {...}, In+1, ..., Im} - возвращает итератор, который возвращает столько последовательностей, сколько из дает block: (I1, ..., In, seq1, In+1, ..., Im), ..., (I1, ..., In, seqk, In+1, ..., Im).</li>
<li>atomic { I1, ..., In, block {...}, In+1, ..., Im, block {…}, Im+1, …, Ik} - (вложенные блоки дают разное количество последовательностей) <strong>- ???</strong></li>
<li>block { I1, ..., In } - возвращает итератор, который выдает n последовательностей, состоящих из одного элемента каждая. </li>
<li>block { I1, ..., In, block {...}, In+1, ..., Im} <strong>- ???</strong></li>
<li>block { I1, ..., In, block {...}, In+1, ..., Im, block {…}, Im+1, …, Ik} <strong>- ???</strong></li>
</ol>
<p>P.S. Cейчас из этого только atomic { I1, ..., In } и block { I1, ..., In } работают корректно. Более сложные случаи не проработаны: atomic { ... } объединяет все в единственную последовательность, а block { ... } создает на основе n вложенных элементов (инструкций или блоков) n последовательностей, которые получаются путем объединения всех последовательностей, возвращаемых соответствующим элементом.</p> MicroTESK - Task #5192 (New): Assert constructions to check the model state during and after simu...https://forge.ispras.ru/issues/51922014-08-12T08:43:23ZAndrei Tatarnikovandrewt@ispras.ru
<p>Необходимо реализовать конструкции assert для тестовых шаблонов. Это внутренняя фича для нас, а не для пользователя. Assert'ами будем проверять внутреннее состояние модели во время симуляции символической тестовой программы и после (во время генерации кода тестовой программы). Это нужно для тестирования работы симулятора. Можно будет включить в автоматическую сборку генерацию тестовых программ для всех примеров тестовых шаблонов - будут регрессионные тесты.</p> MicroTESK - Task #4061 (New): Support for endiannesshttps://forge.ispras.ru/issues/40612013-04-03T09:36:03ZAndrei Tatarnikovandrewt@ispras.ru
<p>Сейчас порядок байт не учитывается при моделировании. Он принимается за little-endian по умолчанию.</p>
<p>В моделях, предоставленных IIT Kanpur порядок байт задаётся ключом byte_order. Это выглядит так:</p>
<p>let byte_order = "little" <br />let byte_order = "big"</p>
<p>Нам тоже нужно учитывать порядок байт при моделировании модели.</p>