MRC命令的附加协处理器寄存器的作用是什么？
引用 ARM MRC 文档，
MRC{2}、# 、 地点：
2如果指定，则选择编码 T2 / A2。如果省略，则选择编码 T1 / A1。
请参阅第 A8-7 页上的标准汇编器语法字段。 ARM MRC2 指令必须是无条件的。
协处理器的名称。标准通用协处理器名称为 p0、p1、...、p15。
是协处理器特定的操作码，范围为 0 到 7。
是目标 ARM 内核寄存器。该寄存器可以是 R0-R14 或 APSR_nzcv。最后一种形式将传输值的位 [31:28] 写入 N、Z、C 和 V 条件标志，并通过将编码的 Rt 字段设置为 0b1111 来指定。在 UAL 之前的汇编语法中，使用 PC 而不是 APSR_nzcv 来选择这种形式。
是包含第一个操作数的协处理器寄存器。
是附加源或目标协处理器寄存器。>
是协处理器特定的操作码，范围为 0 到 7。如果省略，则假定为 0。
如果 MRC< /code> 的意思是将单个协处理器寄存器的内容复制到单个 ARM 寄存器中，CRm 的原因是什么？另外，我也不太确定 opcode 的原因是什么，但这无关紧要。
Quoting from the ARM MRC documentation,
MRC{2}<c><q> <coproc>, #<opc1>, <Rt>, <CRn>, <CRm>{, #<opc2>}where:
2If 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 select 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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
user786653 的这个链接可能一语中的。
我知道旧的 fpu、fpa 使用协处理器接口，如果您解码 fpa 浮点指令，我想您会发现它们与通用协处理器 (mrc/mcr) 的操作码模式一致。
我的观点是，我不会对该指令中的每个字段都感到兴奋，就协处理器而言，某些字段可能不关心。 ARM 处理器和汇编器不一定知道您连接了什么，这是将位模式放入机器指令的通用方法。您需要关注您正在交谈的特定协处理器，其 TRM 特别是具有该逻辑的匹配版本号的 TRM（如果可能，如果来自 ARM）假设该协处理器来自 ARM，如果它是其他人的协处理器，则使用他们的文档。希望该协处理器中每个操作所使用的字段都定义得足够好。如果他们不谈论其中一个字段的含义，我会认为他们不在乎。剪切并粘贴手册中的 mrc/mcr 行（如果有的话），如果没有，则可能会找到一些已经使用良好的代码，然后剪切并粘贴该模式和/或为未定义的字段尝试不同的操作，看看是否会改变操作。
一般来说，尽管 mrc/mcr 字段定义不是一成不变的，但供应商可以创建协处理器并对这些字段执行任何他们想要的操作。就像 FPA 一样，可能甚至会更改汇编器/反汇编器来创建指令集的新扩展。 ARM核心可能关心ARM寄存器本身，如果协处理器接口本身有一个TRM，如果协处理器读取有一条控制线告诉ARM是否根据协处理器修改指定的ARM寄存器，我不会感到惊讶驱动该信号。
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.