[PATCH, RFC] arm: VMRS and VMSR should accept FPINST{,2}

[Jan Beulich]

>>> On 08.04.13 at 18:26, Richard Earnshaw <rearnsha@arm.com> wrote:
> On 08/04/13 16:02, Jan Beulich wrote:
>> The Common VFP Subarchitecture specification has two more FP control 
> registers
>> which are to be accessed through VMRS and VMSR. The assembler, however, so 
> far
>> didn't provide a way to encode the respective instructions (other than 
> through
>> legacy mnemonics or the hard to read MRC/MCR ones).
>>
>> With Common VFP and VFP apparently not being the same thing, and there not
>> being any way currently to specify the Common VFP Subarchitecture version, I
>> tied acceptance of these registers to VFPv3 being enabled. The patch is RFC
>> because of my need of confirmation whether that's acceptable, or whether
>> there's a mechanism is failed to spot.
>>
>> gas/
>> 2013-04-08  Jan Beulich <jbeulich@suse.com>
>>
>> 	* gas/config/tc-arm.c (do_vmrs): Also accept FPINST and FPINST2.
>> 	(do_vmsr): Likewise.
>>
> 
> The floating-point support code is littered with possible special cases 
> like this.  The FPINST register has certainly existed since VFPv1 (on 
> the ARM10) and FPINST2 since at least ARM11 (VFPv2), but it might even 
> go back further -- the registers were implementation defined, not part 
> of the architecture.
> 
> The legacy instructions (FMRX and FMXR) both accept these registers 
> unconditionally, leaving it to the user to get things right.
> 
> My feeling is that we should do the same for VMSR and VMRS.  That is, if 
> the register name parses ok, we should just accept the instruction, even 
> if it's meaningless to execute.  Writing support code is a specialist 
> task and we should trust users to know what they are doing in this area. 
>   Caveat emptor and all that.

So you say I should simplify the patch by just adding the new
cases unconditionally?

> As with your other patches, we really should have some test cases for these.

Will do.

Jan