<div dir="ltr">Guys,<div><br></div><div>I'm either not getting my point across or I'm missing something.</div><div>This is not a simple matter of accepting a different syntax or an alias for another "canonical" syntax.</div>
<div><br></div><div>There is no canonical syntax. There still is one syntactic representation for each bit-pattern. There is</div><div>no ambiguity, </div><div><br></div><div>For each pair of integers there is only one encoding. For each encoding there is only one pair of integers.</div>
<div>The problem is that the actual number these bits/numbers stand for can be represented in multiple ways.</div><div><br></div><div>You can't just parse (#a, #b) and decode it as the immediate "1". There are multiple (a, b) pairs which have</div>
<div>the meaning of "1" and which lead to different encodings. </div><div><br></div><div>So what I see is two solutions:</div><div><br></div><div>1. have parse-only instruction definitions which pipe the values #a and #b straight into their respective places</div>
<div>in the instruction word (the proposed solution)</div><div>2. a combination of:</div><div><div><ul><li>adding a new type of custom parser which parses #a, #b as one integer but keeping in mind that #b is optional and zero if left out (which I doubt is feasible within the constraints of what tablegen generates. That is not a parser by any means - just a rather dumb string matcher)</li>
<li>changing the internal representation of immediates to a value/modifier pair</li><li>changing the emission of affected instructions</li><li>changing the lowering towards MC</li></ul><div>What I have to solve is essentially an assembly syntax problem which needs resolution for tools/core validation purposes. </div>
</div><div>While I appreciate that "2" is a cleaner solution, isn't it a bit much to complex and risky to do? A bug in solution 1</div><div>will only be confined to the use of the new instructions. A bug in solution 2 will impact any compilation.</div>
<div><br></div><div><font face="comic sans ms, sans-serif">I think a good principle of taking decisions is comparing the scope of a change to the scope of it's potential impact.</font></div><div><font face="comic sans ms, sans-serif">While with 1 the scopes are similar (assembler-only functionality confined to specific instructions), solution 2 exhibits</font></div>
<div><font face="comic sans ms, sans-serif">a pretty large imbalance in this regard (the scope of the change is assembler-only functionality specific to a few instructions,</font></div><div><font face="comic sans ms, sans-serif">the scope of the potential impact is any compiled application).</font></div>
<div><br></div><div>I am curious as to the groups view on the previous paragraph. This is the main reason I chose a copy-paste-y solution</div><div>(that and the fact that tablegen does not support certain features). </div>
<div><br></div><div>Regards,</div><div>Mihai</div><div><br></div><div><br></div></div><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 29, 2013 at 10:41 PM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</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"><div class="im">On 29 July 2013 20:55, Jim Grosbach <span dir="ltr"><<a href="mailto:grosbach@apple.com" target="_blank">grosbach@apple.com</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><div><span style="color:rgb(34,34,34)">+1. This is very important. The MCInst should not have any memory of what the assembly syntax form was.</span></div></div></div>
</div></blockquote><div><br></div></div><div>Agreed. Consistency in the representation, not in the notation.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>--renato</div></font></span></div></div></div>

</blockquote></div><br></div></div>