This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.

2013-04-08  Jan Beulich <>

	* 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.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]