-mimplicit-it=thumb and FSF
Richard.Earnshaw at arm.com
Fri Jul 16 16:02:35 BST 2010
On Fri, 2010-07-16 at 15:31 +0100, Dave Martin wrote:
> Hi Richard,
> Am I right in understanding that fsf's primary objection to
> -mimplicit-it is the resulting unpredictability of the size of the
> assembler output for asm blocks? Note that the assmbler output size
> is _already_ unpredictable: what about the variable size of Thumb-2
> instructions already, and what about use of assembler directives such
GCC will count each statement in the asm as using 4 bytes. So the
variable length is not an issue (it over-accounts). It can't account
for instructions that are missing from the stream.
> #define nops(count) asm( \
> ".rept " #count "\n\t"
> ".endr" \
This isn't supported in either ARM or Thumb mode.
> Presumably this will defeat GCC's literal pool placement on any
> architecture which has literal pools. Indeed, we can come with an
> inexhaustible supply of such cases: it's an inevitable result of the
> separation between GCC and the assembler.
> If for Thumb-2 I assume we already have a heuristic that attempts to
> count the number of instructions and predicts the maximum size of the
> asm block as n*4 bytes (where n is the instruction count), would it be
> feasible to estimate a bound of n*6 bytes if using -mimplicit-it? Or,
> do we dump the literal before the asm block to be on the safe side
> (and if so, why doesn't this work equally well when using
That would be overkill.
> Re the suggestion that inline asm should be "fixed" to include
> explicit IT instructions, do you know a practical way to do this?
Run your code through the compiler with the correct assembly option,
then fix the errors. The default configuration of the assembler will
make it quietly ignore IT instructions in ARM code, so by adding them
the worst you do is cause a slight increase in GCC's assumptions about
the size of such blocks.
> My concern is that with GCC -marm, the inline asm is passed as-is to
> be interpreted non-unified syntax (for backwards compatibility
> purposes), whereas with -march>=armv6t2 -mthumb, the asm is passed
> (again as-is) to be interpreted in unified syntax. But with explicit
> IT blocks, it's impossible to be compatible with both syntaxes if my
> understanding is correct: Am I right in thinking that current GNU as
> in non-unified syntax mode, and indeed legacy versions of the tools
> will treat the IT instructions as an error and barf? Can you think of
> a way of working round this?
There really isn't any such thing as non-unified ARM mode assembly.
Some asm statements may not be fully conforming (ie use old organization
of S and <cond>) but that's all. If the assembler doesn't accept IT in
legacy mode then it should be fixed to permit it in the same way as
> The best I can think of right now is ghastly preprocessor stuff along
> the lines of
> #ifdef __thumb__ /* or more correctly __thumb2__ ? */
> #define __asm_it_generic(mnemonic,cond) #mnemonic " " #cond "\n\t"
> #define __asm_it_generic(mnemonic,cond) /* expands to nothing */
> #define __it(cond) __asm_it_generic(it,cond)
> #define __ite(cond) __asm_it_generic(ite,cond)
> /* ... */
> "moveq r0, #0\n\t"
> "bleq func1\n\t"
> "blne func2\n\t"
Yes, you could do something like that.
> An alternative, if we are happy to "fix" source packages in a way
> which breaks building them with older tools, is to pass unified
> assembler assembler in unified syntax too. But that would require
> some work in the code gen backend for arm if I understand correctly.
> But it's a huge task to port everything and some upstream projects may
> not accept the changes at all. My concern is that without some
> transitional approach, there's simply too much existing code for this
> to be viable.
What would their reason be to not accept valid source? The only excuse
they could use would be based on an invalid view of the ARM world.
> Do you know when unified assmbler support was introduced in fsf?
About 5 years ago would be my best guess. But it's been somewhat
Richard Earnshaw Email: Richard.Earnshaw at arm.com
Engineering Manager Phone: +44 1223 400569 (Direct + VoiceMail)
OpenSource Tools Switchboard: +44 1223 400400
ARM Ltd Fax: +44 1223 400410
110 Fulbourn Rd Web: http://www.arm.com/
Cambridge, UK. CB1 9NJ
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
More information about the linaro-toolchain