<div dir="ltr">Let's move the discussion forward a little.<div>There are two different issues that were brought up:</div><div><br></div><div>1. whether this support should be implemented in the first place</div><div>2. the exact manner of implementation</div>
<div><br></div><div>I understand there are objections to 2. It is not clear whether there</div><div>are any objections to 1.</div><div><br></div><div>Kindly clarify.</div><div><br></div><div>Thanks,</div><div>Mihai</div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 30, 2013 at 6:01 PM, JF Bastien <span dir="ltr"><<a href="mailto:jfb@google.com" target="_blank">jfb@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This is actually covered very clearly by the ARM ARM, section A5.2.4<br>
Modified immediate constants in ARM instructions, Constants with<br>
multiple encodings:<br>
<br>
======<br>
Some constant values have multiple possible encodings. In this case, a<br>
UAL assembler must select the encoding with the lowest unsigned value<br>
of the rotation field.<br>
<br>
[...]<br>
<br>
An alternative syntax is available for a modified immediate constant<br>
that permits the programmer to specify the encoding directly. In this<br>
syntax, #<const> is instead written as #<byte>, #<rot>, where:<br>
  <byte> is the numeric value of abcdefgh, in the range 0-255<br>
  <rot> is twice the numeric value of rotation, an even number in the<br>
range 0-30.<br>
<br>
This syntax permits all ARM data-processing instructions with modified<br>
immediate constants to be disassembled to assembler syntax that<br>
assembles to the original instruction.<br>
<br>
This syntax also makes it possible to write variants of some<br>
flag-setting logical instructions that have different effects on<br>
APSR.C to those obtained with the normal #<const> syntax. For example,<br>
ANDS R1, R2, #12, #2 has the same behavior as ANDS R1, R2, #3 except<br>
that it sets APSR.C to 0 instead of leaving it unchanged. Such<br>
variants of flag-setting logical instructions do not have equivalents<br>
in the Thumb instruction set, and ARM deprecates their use.<br>
=====<br>
<br>
There *is* a canonical encoding when using the regular syntax, but<br>
that canonical encoding can be circumvented by using what Mihail is<br>
suggesting. Re-assembling to the same thing is a nice goal, but<br>
generating the same flags is, I think, a much stronger case for<br>
supporting what he proposes. +1 from me (though I haven't reviewed the<br>
code).<br>
</blockquote></div><br></div>