Home Original page

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

Richard Earnshaw rearnsha@arm.com
Tue Apr 9 08:34:00 GMT 2013 
On 09/04/13 08:07, Jan Beulich wrote:
>>>> 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?
>

I'd go further and remove all the numeric checks in that bit of code. 
If we get through parsing the register name, we just insert the number 
generated into the instruction without further validation.  Please do 
add a comment to that effect when you remove the code, though.

BTW, thanks for all the effort you've put into all this, it's much 
appreciated.

R.
More information about the Binutils mailing list