Open-Source Projects: Issueshttps://forge.ispras.ru/https://forge.ispras.ru/favicon.ico?16490126692015-05-27T08:30:33ZOpen-Source Projects
Redmine MicroTESK - Bug #5987 (Closed): Handling situations when TestBase fails to generate test data (e....https://forge.ispras.ru/issues/59872015-05-27T08:30:33ZAndrei Tatarnikovandrewt@ispras.ru
<p>The situation when TestBase fails to provide data for a test situation should be handled in the following way:</p>
<ol>
<li>A warning message explaining the reason must be printed.</li>
<li>Some default data (e.g zero) must be provided. Leaving a resource (register) uninitialized is incorrect.</li>
</ol>
<p>Now MicroTESK prints an abrupt message and leaves the resources uninitialized.</p> MicroTESK - Bug #5708 (Closed): MicroTESK build fails: SsaAssembler - symbol Changes is not definedhttps://forge.ispras.ru/issues/57082015-03-13T11:06:24ZAndrei Tatarnikovandrewt@ispras.ru
<p>Artem, please add the Changes class to the SVN source code base. Now the build fails:</p>
<pre>
javac.core:
[mkdir] Created dir: /srv/hudson/jobs/MicroTESK/workspace/bin/microtesk
[javac] Compiling 272 source files to /srv/hudson/jobs/MicroTESK/workspace/bin/microtesk
[javac] /srv/hudson/jobs/MicroTESK/workspace/src/main/java/core/ru/ispras/microtesk/translator/simnml/coverage/ssa/SsaAssembler.java:42: error: cannot find symbol
[javac] Deque<Changes> changesStack;
[javac] ^
[javac] symbol: class Changes
[javac] location: class SsaAssembler
[javac] /srv/hudson/jobs/MicroTESK/workspace/src/main/java/core/ru/ispras/microtesk/translator/simnml/coverage/ssa/SsaAssembler.java:43: error: cannot find symbol
[javac] Changes changes;
[javac] ^
[javac] symbol: class Changes
[javac] location: class SsaAssembler
[javac] /srv/hudson/jobs/MicroTESK/workspace/src/main/java/core/ru/ispras/microtesk/translator/simnml/coverage/ssa/SsaAssembler.java:169: error: cannot find symbol
[javac] private static void join(Changes repo, Collection<GuardedBlock> blocks, Collection<Changes> containers, NodeTransformer xform) {
[javac] ^
[javac] symbol: class Changes
[javac] location: class SsaAssembler
[javac] /srv/hudson/jobs/MicroTESK/workspace/src/main/java/core/ru/ispras/microtesk/translator/simnml/coverage/ssa/SsaAssembler.java:169: error: cannot find symbol
[javac] private static void join(Changes repo, Collection<GuardedBlock> blocks, Collection<Changes> containers, NodeTransformer xform) {
[javac] ^
[javac] symbol: class Changes
[javac] location: class SsaAssembler
[javac] /srv/hudson/jobs/MicroTESK/workspace/src/main/java/core/ru/ispras/microtesk/translator/simnml/coverage/ssa/SsaAssembler.java:185: error: cannot find symbol
[javac] private static Node getJointFallback(String name, Changes master, Changes branch) {
[javac] ^
[javac] symbol: class Changes
[javac] location: class SsaAssembler
[javac] /srv/hudson/jobs/MicroTESK/workspace/src/main/java/core/ru/ispras/microtesk/translator/simnml/coverage/ssa/SsaAssembler.java:185: error: cannot find symbol
[javac] private static Node getJointFallback(String name, Changes master, Changes branch) {
[javac] ^
[javac] symbol: class Changes
[javac] location: class SsaAssembler
[javac] /srv/hudson/jobs/MicroTESK/workspace/src/main/java/core/ru/ispras/microtesk/translator/simnml/coverage/ssa/SsaAssembler.java:62: error: unexpected type
[javac] this.changesStack = new ArrayDeque<>();
[javac] ^
[javac] required: class
[javac] found: <E>ArrayDeque<E>
[javac] where E is a type-variable:
[javac] E extends Object declared in class ArrayDeque
[javac] /srv/hudson/jobs/MicroTESK/workspace/src/main/java/core/ru/ispras/microtesk/translator/simnml/coverage/ssa/SsaAssembler.java:65: error: cannot find symbol
[javac] this.changes = new Changes(changesStore, changesStore);
[javac] ^
[javac] symbol: class Changes
[javac] location: class SsaAssembler
[javac] /srv/hudson/jobs/MicroTESK/workspace/src/main/java/core/ru/ispras/microtesk/translator/simnml/coverage/ssa/SsaAssembler.java:130: error: cannot find symbol
[javac] final Collection<Changes> containers = changes.fork(size);
[javac] ^
[javac] symbol: class Changes
[javac] location: class SsaAssembler
[javac] /srv/hudson/jobs/MicroTESK/workspace/src/main/java/core/ru/ispras/microtesk/translator/simnml/coverage/ssa/SsaAssembler.java:131: error: cannot find symbol
[javac] final Iterator<Changes> rebasers = containers.iterator();
[javac] ^
[javac] symbol: class Changes
[javac] location: class SsaAssembler
[javac] /srv/hudson/jobs/MicroTESK/workspace/src/main/java/core/ru/ispras/microtesk/translator/simnml/coverage/ssa/SsaAssembler.java:172: error: cannot find symbol
[javac] for (Changes diff : containers) {
[javac] ^
[javac] symbol: class Changes
[javac] location: class SsaAssembler
[javac] Note: /srv/hudson/jobs/MicroTESK/workspace/src/main/java/core/ru/ispras/microtesk/translator/simnml/coverage/ssa/SsaAssembler.java uses unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 11 errors
BUILD FAILED
/srv/hudson/jobs/MicroTESK/workspace/build.xml:217: Compile failed; see the compiler error output for details.
Total time: 18 seconds
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Finished: FAILURE
</pre> MicroTESK - Task #5678 (Closed): Support for named branches in ISA specificationshttps://forge.ispras.ru/issues/56782015-03-03T10:46:59ZAndrei Tatarnikovandrewt@ispras.ru
<p>Named branches in ISA specifications must be supported:</p>
<ol>
<li>Support the construct "<code>branch("BranchName");</code>" in the nML translator;</li>
<li>Support situations for named branches in the coverage extractor.</li>
</ol> 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 #5673 (Closed): Memory scalability for large memory ranges (address space for 48...https://forge.ispras.ru/issues/56732015-03-03T08:54:58ZAndrei Tatarnikovandrewt@ispras.ru
<p>Verify and review (if needed) the scalability of memory in the simulator for large memory ranges (address space for 48 and 64 bit addresses).</p>
<p>Question:</p>
<blockquote>
<p>o ISPRAS to review and confirm the sparseness of the implementation of memory<br />• Does memory use of generation scale with number of locations touched or the range of (min, max)</p>
</blockquote>
<p>Answer</p>
<blockquote>
<p>In the current implementation of the simulator, memory is divided into 4KB regions which are allocated only when touched (written to).</p>
</blockquote>
<p>Check whether the current way to avoid excessive memory consumption is sufficient. This includes more intensive testing. If not, the algorithm must be reviewed.</p>
<p>Basic ideas on sparse distributed memory:</p>
<p><a class="external" href="http://en.wikipedia.org/wiki/Sparse_distributed_memory">http://en.wikipedia.org/wiki/Sparse_distributed_memory</a></p> MicroTESK - Bug #5671 (Rejected): Robustness of test template processing logic must be improvedhttps://forge.ispras.ru/issues/56712015-03-03T08:16:57ZAndrei Tatarnikovandrewt@ispras.ru
<p>The issue: coding mistakes in test templates cause unhandled exceptions.</p>
<p>All such situations (e.g. like in Bug <a class="issue tracker-1 status-6 priority-5 priority-high3 closed" title="Bug: Exception when no test situation is specified. (Rejected)" href="https://forge.ispras.ru/issues/5650">#5650</a>) must be handled in a proper way.<br />That means, MicroTESK should print an understandable error or warning messages and stop processing of the test template or ignore the problematic part (depending on severity of the error).</p>
There two error handling policies to be covered:
<ul>
<li>For errors causes by mistakes in test templates which occurred at first stages of template processing</li>
<li>For errors causes by mistakes in test templates and specifications which occurred during simulation</li>
</ul>
<p>Intensive negative testing of the feature is required.</p> MicroTESK - Bug #5668 (Closed): Issues with large memory addresses (48 and 64 bits) must be fixedhttps://forge.ispras.ru/issues/56682015-03-03T07:50:50ZAndrei Tatarnikovandrewt@ispras.ru
<p>Subj. Top priority.</p>
<p>Basic test LargeAddrTestCase fails marking the current version as unstable.</p>
<p>Also, tests and examples (nML + test templates) are required.</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 - Bug #5659 (Rejected): Function 'trace' should accept addressing modes as argumentshttps://forge.ispras.ru/issues/56592015-02-27T15:29:30ZAndrei Tatarnikovandrewt@ispras.ru
<p>This would simplify writing test templates</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 - Bug #4996 (Closed): [translator] It should be possible to define the "instruction" op...https://forge.ispras.ru/issues/49962014-06-18T11:42:22ZAndrei Tatarnikovandrewt@ispras.ru
<p>The current version has an unreasonable limitation: the "instruction" operation (root) can be defined as an AND rule only. This should be changed. It should be allowed to define the "instruction" operation as an OR rule.</p> MicroTESK - Task #4283 (Closed): [translator] Support for custom attributes in operations and add...https://forge.ispras.ru/issues/42832013-07-01T10:24:28ZAndrei Tatarnikovandrewt@ispras.ru
<p>Транслятор и модель должны поддерживатить использование <strong>кастомных аттрибутов</strong>. Например, в приведённом ниже куске используется аттрибут loop, который организует цикл путём рекурсии. Для трансляции модели MIPS требуется эта возможность.</p>
<pre>
op CLZ(rd : index, rs : REG_IND_ZERO)
syntax = format ("CLZ %d,%s", rd, rs.syntax)
image = format ("011100%s%5b%5b00000100000", rs.image, rd, rd)
action = {
tmp_signed_byte = 31;
GPR [rd] = 32;
loop;
}
loop = {
if tmp_signed_byte >= 0 then
if ( rs < tmp_signed_byte..tmp_signed_byte > == 0 ) then
tmp_signed_byte = tmp_signed_byte - 1;
else
GPR [ rd ] = 31 - tmp_signed_byte;
tmp_signed_byte = -1;
endif;
loop;
endif;
}
</pre> MicroTESK - Bug #4281 (Closed): [translator] Support for aliases in memory (aka mem) definitions.https://forge.ispras.ru/issues/42812013-07-01T06:29:20ZAndrei Tatarnikovandrewt@ispras.ru
<p>Подобные конструкции сейчас не поддерживаются транслятором Sim-nML:</p>
<pre>
mem tmp_signed_half_word [1, int(16)]
mem tmp_signed_half_word_A0 [1, int(8)] alias = tmp_signed_half_word[8]
</pre>
<p>Это одна из причин, по которой не удаётся оттранслировать спецификацию процессора MIPS.</p> MicroTESK - Task #4116 (Closed): [model] Lazy memory allocation in memory modelshttps://forge.ispras.ru/issues/41162013-04-16T17:46:16ZAndrei Tatarnikovandrewt@ispras.ru
<p>При моделировании линейки памяти сейчас создаётся массив (ArrayList) соответствующего размера. При этом, если линейка большой длины, программа расходует всю доступную память и падает. Нужно сделать, чтобы память свыше определённого размера (например, 1 МБ) выделялась по требованию (при обращению).</p>
<p>public static final MemoryBase M = new MemoryBase(EMemoryKind.MEM, "M", byte_t, (int)Math.pow(2, 10));</p>