ARM v6T2 - flags, ARM-instruction disassembly
Zack Weinberg
zack@codesourcery.com
Sat Mar 12 18:23:00 GMT 2005
Richard Earnshaw <rearnsha@gcc.gnu.org> writes:
>> 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).
Hmm. If we shrink the coprocessor space as far as it can go (which
may not be a good move) and merge v1/v2/v2s, that gets us 5+2=7 bits.
Paul, you said you knew what was in the pipeline - how many bits are
necessary in the near future?
>> 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).
I am hesitant to do this mainly because I don't know where all those
variables live, nor do I know what would be a good arrangement.
>> 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.
Committed.
zw
More information about the Binutils
mailing list