ARM v6T2 - flags, ARM-instruction disassembly

Richard Earnshaw rearnsha@gcc.gnu.org
Sat Mar 12 14:13:00 GMT 2005


On Sat, 2005-03-12 at 07:03, Zack Weinberg wrote:
> ARMv6T2's main claim to fame is the extensive revisions to the Thumb
> instruction set, but it also adds a small number of plain old ARM
> instructions.  This patch adds ARM_EXT_ and ARM_ARCH_ macros for v6T2,
> alone and in combination with the other v6 extensions, and
> disassembler support for the new ARM instructions.  If accepted,
> assembler support will follow in short order.
> 
> There is also a tangential tweak: I changed the disassembly loop so
> that an instruction whose condition field is all-bits-one will only
> match an opcode table entry whose mask covers the entire condition
> field.  This allows us not to have to worry about the relative order
> of the opcode table entries for an "unconditional instruction space"
> instruction and the corresponding "ordinary" instruction.

This is sensible.  It might break disassembly of some legacy objects but
I don't think it's very serious.  Prior to ARMv4 an instruction with
bits 28:31=0xf was treated as the opposite of 'always' -- ie never and
hence was a nop.  So

	movnv	r0, r0, r0

was a valid instruction (and indeed the above was at one time the
recommended NOP instruction).

This lead in some cases to some novel uses, such as

	ldr	r0, [pc, #-4]
	.word	0xffff0000
	and	r1, r2, r0
	...

where it was known that the data word (which had the equivalent of a
condition field equal to 0xf) would never do anything.  Anyway, this is
so long ago as to not be particularly interesting from a disassembly
point of view.

> 
> This consumes the last unused bit of the "basic core" portion of the
> masks in opcode/arm.h.  There are several more core-instruction-set
> extensions in the pipeline, so now would be a good time to discuss
> what to do to get more space.  I see three alternatives:
> 

I knew we'd run out at some point.  I hadn't realised we were that
close.

> 1) Steal bits from the co-processor space, which is currently using
>    only three of its eight bits.  Probably safe, but not very future
>    proof.

I'm sure this would be trivial and safe, but it won't last very long, as
you point out.

> 
> 2) Drop support for obsolete cores, e.g. V1 through V3 and possibly
>    also the xM and xP variants of V4 and V5.  I don't know how many
>    people are still out there using them, though.
> 

We could certainly merge v1, v2 and v2S (v1 was only a prototype, and v2
cores can generally emulate the SWP instruction added in v2s); at a
pinch we could probably merge these with v3 too (especially if we did
some manual checks on the opcode in the operands check routine).  v3 and
v3M are really needed at this time; the other xM variants are probably
not needed, but make use of either v3 or v3M as appropriate so there's
nothing that can be reclaimed there.  I think xP is also needed at this
time.  But even this only gets us back 2, possibly 3 bits, so it's not a
long-term solution.

> 3) Expand the variables that hold these values, to give us more room.
>    Lots of work, but mostly mechanical, and would make the problem go
>    away for the foreseeable future.
> 
This would, I think, be the best solution (or something very much like
this).

> zw
> 
> include:
>         * opcode/arm.h: Adjust comments for ARM_EXT_V4T and ARM_EXT_V5T.
>         Add ARM_EXT_V6T2, ARM_ARCH_V6T2, ARM_ARCH_V6KT2, ARM_ARCH_V6ZT2,
>         and ARM_ARCH_V6ZKT2.
> opcodes:
>         * arm-dis.c (arm_opcodes): Document %E and %V.
>         Add entries for v6T2 ARM instructions:
>         bfc bfi mls strht ldrht ldrsht ldrsbt movw movt rbit ubfx sbfx.
>         (print_insn_arm): Add support for %E and %V.

OK.



More information about the Binutils mailing list