Re: Odd restriction on ARM LDRD/STRD instruction

[Richard Earnshaw <rearnsha at buzzard dot freeserve dot co dot uk>]

[The original message was supposed to go to the binutils list as well, but 
I can't type ... ]

> Hi Richard,
> 
> : The current gas code for the ARM generates an error if LDRD or STRD
> : are used with R12 as the value for Rd.  My copy of the ARM ARM makes
> : no reference to such a restriction.  Do you know where it might have
> : come from?
> 
> I suspect that it might have been an early restriction on the
> implementation of LDRD by the XScale.  I can find no reference to it
> in the current documentation though, so I think we can safely remove
> it.

OK, I'll remove it in the patch I'm working on.

>  
> : The ARM ARM also says that use of R14 generates UNPREDICTABLE
> : results, so I think the error should be reduced to a warning
> : anyway. 
> 
> If the instruction is UNPREDICTABLE then surely you do not want to
> generate it, so the message should stay as an error, shouldn't it ?
> 

Most other UNPREDICTABLE cases in tc-arm.c cause as_warn to be called.  I think that is the correct thing to do generally, since there may be good reasons for trying to try to generate such an instruction in specific circumstances (after all, the opcode is not invalid, but the way the processor interprets it is not defined).  UNDEFINED behaviour is a different issue and we do generate an error there (even here there may be a case for generating the opcode under some circumstances since the opcode is supposed to cause an undefined instruction trap).  The main point is consistency and I'm just trying to achieve that.

The reason I bring this up is that I'm working on adding the VFP instructions to the assembler.  Part of the preliminary work for this is to rework the parser to clean it up a bit (it's still basically the same parser that I implemented back in 1993 or so when I was still at the computer lab).  The new version will create a complete hash table of all valid instructions and significantly simplifies the main parser engine in md_assemble().  Expect a bumper submission sometime in the (hopefully) not-to-distant future.

R.