Re: ARM v6T2 - flags, ARM-instruction disassembly

[Richard Earnshaw <rearnsha at gcc dot gnu dot org>]

On Sat, 2005-03-12 at 18:23, Zack Weinberg wrote:
> Richard Earnshaw <rearnsha@gcc.gnu.org> writes:
> >> 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.

OK, the attached is a preliminary attempt at sorting this all out.  

The idea behind this change is to get us to the point where
'arm_feature_set' can be some arbitrary opaque structure that the tools
can manipulate as needed.  The type doesn't need to be known to the
tools and may not be a scalar (it still is at the moment, but the change
to make it a structure is probably the next step).

It introduces two new macros:

1) ARM_CPU_HAS_FEATURE(CPU,FEATURE)

which returns non-zero if the CPU has the requested feature.

2) ARM_MERGE_FEATURE_SETS(T,F1,F2)

Which takes two feature sets F1 & F2 (pointers to them) and fills in *T
with the union of the two sets.  T & F1 may be the same object.

There's some shenanigans that have to be played in tc-arm.c, but almost
all of this is in the command parsing code; most of the problems come
from the use of litterals.  I've addressed most of these by creating
static variables that are initialized to the appropriate litteral.  This
change isn't strictly necessary while arm_feature_set remains a scalar,
but will be needed in order to make it a compound type.

No substantive changes were needed to arm-dis.c since it doesn't
currently validate the CPU type.

Thoughts?

R.

Attachment: arch.patch
Description: Text document