<div dir="ltr">Tim,<div><br></div><div>I found a way to avoid having a big switch that converts opcodes between ri and rii.</div><div>Basically, I am assigning all the rii instructions to a new DecoderNamespace.</div><div>
<br></div><div>In ARMDisassembler:getInstruction I change the flow so that when an instruction is matched</div><div>int "ARM" Namespace, the new namespace is tested as well. If I have a match this second</div><div>
time then the decoded instruction has a modified immediate. All I have to do is to decide</div><div>which of the two decoded instructions to keep (i.e. ri comes from ARM namespace, rii comes</div><div>from new namespace).</div>
<div><br></div><div>Decision is as follows:</div><div><br></div><div>1. locate the two immediates in the rii instruction's operand list</div><div>2. decide whether the <value, rot> pair is "canonical" (i.e. lowest possible rot out of all representations</div>
<div>of that immediate)</div><div>3. if canonical return the ri version (i.e. friendly syntax) and the rii version (pair syntax) otherwise</div><div><br></div><div>Now, surprisingly I am having problems with step 1!</div>
<div>Although the two immediates are always the final inputs, they are not the final MCOperands, nor</div><div>the final immediate MCOperands.</div><div><br></div><div>It varies from class to class and given the lack of information in MCInsts I really can't see how</div>
<div>I could locate them reliably.</div><div><br></div><div>Any advice?</div><div><br></div><div>Regards,</div><div>Mihai</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 15, 2013 at 11:57 AM, Mihail Popa <span dir="ltr"><<a href="mailto:mihail.popa@gmail.com" target="_blank">mihail.popa@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 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="HOEnZb"><div class="h5"><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>> 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><font color="#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>