"branch" instruction encoding

I just tried a small C case and it does use short encoding for beq. If will be very helpful if you can share:
- Small pieces of source code. (.c or .s)
- Options to invoke compiler
- Compiler versions (4.7 2013q2 hasn't been released yet. Did you mean 2013q1?)

Thanks - Joey

File test.S:
  .syntax unified
  .text
  .thumb
  b test
  nop
test:

Compilation:
arm-none-eabi-gcc -c test.S -o test.o -Wa,-alh

Result with 4.6 2012q4:
   1 # 1 "test.S"
   1 .syntax unified
   0
   0
   2 .text
   3 .thumb
   4 0000 00E0 b test
   5 0002 C046 nop
   6 test:

Result with 4.7 2013q1
   1 # 1 "test.S"
   1 .syntax unified
   0
   2 .text
   3 .thumb
   4 0000 00F001B8 b test
   5 0004 C046 nop
   6 test:

Without directive ".syntax unified" it works fine, but I need it.

PS: version is 4.7 2013q1 own compilation. I don't know why but compilation result of gcc-arm-none-eabi-4_7-2013q1-20130313-src.tar.bz2 is package gcc-arm-none-eabi-4_7-2013q2-20130514-win32.exe

Thanks for reporting this.

Reproduced and it is binutils version update that brings this change. Need more time to figure out what happened and decide if it is expected.

Before final conclusion, a easy workaround is using explicitly b.n in your case:

      b.n test
      nop
test:

- Joey

Now I think it expected behavior. To avoid 4 byte branch all the time, you can name your local labels as ".L", which is how compiler generated code works. See following example:

test.S:
main:
.Lmain:
    b .Lmain
    b main

test.o:
   0: e7fe b.n 0 <main>
   2: f7ff bffe b.w 0 <main>

- Joey

Many thanks for answer. Both solutions works.

It made another question: is it expected behavior for next versions/generations of GCC compiler?

I think it expected behavior for future version too.

On Tue, May 21, 2013 at 3:41 PM, jdobry <
<email address hidden>> wrote:

> Question #228850 on GCC ARM Embedded changed:
> https://answers.launchpad.net/gcc-arm-embedded/+question/228850
>
> Status: Answered => Open
>
> jdobry is still having a problem:
> Many thanks for answer. Both solutions works.
>
> It made another question: is it expected behavior for next
> versions/generations of GCC compiler?
>
> --
> You received this question notification because you are an answer
> contact for GCC ARM Embedded.
>

Thanks for informations.

Sorry for re-open. But this behavior is in conflict to ARM architecture reference manual. If both encoding are available, compiler must select a 16-bit encoding.
I personally don't have problem with this behavior, but it need clarification.

Quotation from ARM architecture reference manual (ARM DDI 0406C.b ID072512 chapter A8.2):

Specifies optional assembler qualifiers on the instruction. The following qualifiers are defined:
.N Meaning narrow, specifies that the assembler must select a 16-bit encoding for the
instruction. If this is not possible, an assembler error is produced.
.W Meaning wide, specifies that the assembler must select a 32-bit encoding for the
instruction. If this is not possible, an assembler error is produced.
If neither .W nor .N is specified, the assembler can select either 16-bit or 32-bit encodings. If both
are available, it must select a 16-bit encoding.

Please refer to http://sourceware.org/bugzilla/show_bug.cgi?id=12532 for reason why this change was made.

I don't think current assembler breaks "If both are available, it must select a 16-bit encoding.". In case of global symbol, 16-bit encoding isn't available due to possible symbol preemption.

Thanks - Joey

OK. But why it works differently without ".syntax unified" ?

I don't thing that it is global label without ".globl" export. This mean, that compiler do not pass this jump distance to linker and calculate it itself. Problem with R_ARM_THM_JUMP11 relocation can't happen.

For global symbols in different ".section" on same ASM file it's clear why it isn't possible use short version of branch.