<div dir="ltr">I don't disagree with that. However I doubt you can challenge the fact<div>that tablegen and the assembler and disassembler it generates are somewhat lacking</div><div>and whatever they lack has to be compensated for in custom code.</div>
<div><br></div><div>The disassembler is particularly foolish, the assembly parser is not even a parser</div><div>and the tablegen language is irregular, inexpressive and insufficiently well defined.</div><div><br></div><div>
Most of the issues we discussed in my working on the MC layer would have been</div><div>quicker, more easily and more elegantly fixed if:</div><div><br></div><div>1. the disassembler would be a proper decoding automaton that looks at all the bits</div>
<div>in the instruction</div><div>2. the "inheritance" in the instruction classes would be proper inheritance</div><div>3. the assembly "parser" would actually be a simple LL(1) parser</div><div>4. the tablegen language would be better defined and would provide a few extra features</div>
<div><br></div><div>So the root cause of most disagreements is systemic. While your purpose as reviewer is</div><div>to keep me from writing crap, you cannot claim that I fix systemic issues in order to support</div><div>
very specific use cases. It's simply not fair.</div><div><br></div><div>People who own pieces of code should take note of what other engineers have to do to</div><div>work with them and push for improvement. And yes, once new features are in place, they can</div>
<div>enforce them to be used.</div><div><br></div><div>I can appreciate you don't agree with the solution; I myself don't like it. It is however horrifically</div><div>unfair to have me write a new disassembler just because the current one doesn't work properly.</div>
<div>And really, short of this we will never be able to have a clean description free of duplication</div><div>and switch-rich custom decoders.</div><div><br></div><div>I am not even the first one to run into problems - just skim through the code and see what</div>
<div>people have to do in custom decoders. Surely you know. </div><div><br></div><div>Mihai</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 15, 2013 at 11:35 AM, Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> The plan is to detect at disassembly time which immediates<br>
> have multiple representations and choose between ri and rii versions<br>
> based on that.<br>
<br>
</div>A switch or something that knows each and every instruction? That's<br>
horrific. And not a step towards a non-duplicated solution.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div>