This is the mail archive of the binutils@sourceware.org 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 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.




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