What is the function of the additional coprocessor register of the MRC command?

Quoting from the ARM MRC documentation,

MRC{2}<c><q> <coproc>, #<opc1>, <Rt>, <CRn>, <CRm>{, #<opc2>}

where:

2 If specified, selects encoding T2 / A2. If omitted, selects encoding T1 / A1.

<c><q> See Standard assembler syntax fields on page A8-7. An ARM MRC2 instruction must be unconditional.

<coproc> The name of the coprocessor. The standard generic coprocessor names are p0, p1, …, p15.

<opc1> Is a coprocessor-specific opcode in the range 0 to 7.

<Rt> Is the destination ARM core register. This register can be R0-R14 or APSR_nzcv. The last form writes bits [31:28] of the transferred value to the N, Z, C and V condition flags and is specified by setting the Rt field of the encoding to 0b1111. In pre-UAL assembler syntax, PC was written instead of APSR_nzcv to sel开发者_JAVA百科ect this form.

<CRn> Is the coprocessor register that contains the first operand.

<CRm> Is an additional source or destination coprocessor register.

<opc2> Is a coprocessor-specific opcode in the range 0 to 7. If omitted, <opc2> is assumed to be 0.

If MRC is meant to copy contents of a single coprocessor register into a single ARM register, what is the reason for CRm? Also, I'm not quite sure what the reason for an opcode is either, but that's of lesser relevance.

user786653 may have hit the nail on the head with that link.

I know the old fpu, the fpa, used the coprocessor interface and if you decode the fpa floating point instructions I think you will find they line up with the opcode pattern for a generic coprocessor (mrc/mcr).

My point is I wouldnt get worked up over every field in that instruction, some field are likely dont cares as far as the coprocessor is concerned. The ARM processor and assembler dont necessarily know what you have hooked up and this is a generic way to put bit patterns into a machine instruction. You need to focus on the specific coprocessor you are talking to, its TRM specifically the TRM with matching version numbers for that logic (if possible, if from ARM) assuming that coprocessor is from arm, if it is someone elses coprocessor then use their documentation. the fields being used by each operation in that coprocessor are hopefully defined well enough. If they dont talk about what one of the fields means I would assume it a dont care. Cut and paste their mrc/mcr line in the manual if there, if not google around maybe find some already well used code and cut and paste that pattern and/or try different things for the undefined fields and see if that changes the operation.

Generically though the mrc/mcr field definitions are not set in stone, a vendor can create a coprocessor and do whatever they want with those fields. Like the FPA perhaps going so far as to change the assembler/disassembler to create a new extension to the instruction set. the arm core may care about the ARM register itself, If there is a TRM for the coprocessor interface itself I wouldnt be surprised if a coprocessor read has a control line that tells the arm to or not to modify the specified arm register based on the coprocessor driving that signal.