This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Question about T3 and T4 encoding of B/Bcc (Branch) Instruction

On Cortex v7M architecture, looking at the T3 and T4 encodings for the B and Bcc instructions in the architecture reference manual...

Do T3 and T4 really have the J bits of the immediate value in the opposite order from one another?

T3 (20 bit immediate value):  imm32 = SignExtend(S:J2:J1:imm6:imm11:'0', 32);
T4 (24bit immediate value):   I1 = NOT(J1 EOR S); I2 = NOT(J2 EOR S); imm32 = SignExtend(S:I1:I2:imm10:imm11:'0', 32);

All the references are consistent, but it just seems particularly odd.
Is there some more intuitive way to look at the Not(S xor Jn) part of the instructions?
  • Why don't you just assemble a few lines and check the result?

  • I don't think I trust my assembler (gas):

    I mean, at least two of these are wrong, right?

    Disassembly of section .text:
    
    00000000 <start0>:
       0:	f47f affe 	bne.w	9e1ea <*ABS*0x9e1ea>
       4:	f47f affe 	bne.w	7fffe <*ABS*0x7fffe>
       8:	f47f affe 	bne.w	fffff <*ABS*0xfffff>

  • Ah; sorry.  that seems just incompletely linked, for all it produced an a.out :-(

  • Here's correct assembly/disassembly/hand decode.  It's hard to tell - the J bits look like they're in the same order, but the unconditional branch case has that possible inversion going on...

    Source (both have J1:J2 == 10, hopefully):
            @       SJJimm6..imm11..89ABw
            bne .+0b010011110000111101010 + 4
            @       SJJimm10..89Aimm11..89ABw
            b   .+0b0100111100001111011001010 + 4
    
    Disassembly and hand decode:
    00008000 <_start>:
            @    8000:      f05e 88f5       bne.w   a61ee <_stack+0x261ee>
    @           oooo oScc ccii iiii ooJo Jiii iiii iiii
    @           1111 0000 0101 1110 1000 1000 1111 0101
    
    @    8008:	f1e1 9f65 	b.w	9e9ed6 <*ABS*0x13c3d4+0x8adb02>
    @           oooo oSii iiii iiii ooJo Jiii iiii iiii
    @           1111 0001 1110 0001 1001 1111 0110 0101	
    

  • don't think I trust my assembler (gas):

    *rotfl*

    It would be serious if "gas" produces wrong op-codes from such a standard mnemonics.

  • True.  I probably meant "I'm not sure I understand how to get the assembler to generate the instructions I think it should."  The format above "B . + immConstant*2 + 4" seems to be it...
    Although, you could go a long time with errors in the encoding or documentation of the J bits for B instruction on most Cortex-M processors - that's the range beyond the amount of flash on most chips, and not enough to get to RAMFUNCs.

  • T3/T4 encoding applies to all Thumb-2 Cores, means Cortex-A,R and M. So T4 might be used.
    Still not clear to me, where your problem lies. The encoding of T4 is kind of weird,  agree. But I fear, you won't get an answer to the "why" :-)