Are there differences between coprocessor instructions and instruction2:s?
I mean:
MCRR vs. MCRR2
MRRC vs. MRRC2
MCR vs. MCR2
MRC vs. MRC2
LDC vs. LDC2
STC vs STC2
I didn't find any differences in the encoding except the condition code, and no differences in the description of the functionality.
If there are no differences, are there any explanations why they are "condition-code-doubled"?
Hello,
I think it would be a very good question.
I would like to know the truth, too.
However, I guess the reason as extending the number of co-processors.
That is, if the co-processor number was 0, target co-processors for ldc and ldc2 could be different.
For example, regarding ldc instruction, the co-processor numbers of 10 and 11 indicate SIMD instructions.
However, regarding ldc2 instruction, the co-processor number of 10 and 11 can indicate other than SIMD instructions.
The below is the dis-assembler result.
11, cr0, [r1, #4]
They probably are not the same.
How do you think about my idea?
It would not be correct because the co-processor numbers of 10 and 11 for ldc2 would be UNDEFINED according to ARM ARM.
After all, the above explanations would be nonsense.
Best regards,
Yasuhiko Koumoto.
So, your idea is definitely not nonsense,but not really definitive either.
It only holds for coprocs 10 and 11.
I guess that all coproc 10 and 11 "operation writes" map to the same bit patterns as the floating point
and vector instructions - aliases,one might say.
Haven't checked anything, though (= compared fp / vector instruction encodings to coproc instruction encodings).
Another "good" question: why are coprocs 10 and 11 OK with LDC,but not with LDC2, while all other coprocs are
OK with both? Could it be some future expansion of fp/vector instructions via LDC2 only?
(I'm talking about LDC and LDC2, but the same applies for all coproc instructions:MRC/MRC2, ...)
Anyway, strange asymmetry...
In my manual (ARMv7-A/R ARM, Issue C) it says:
Coprocessor 15 (CP15) provides system control functionality. Coprocessor 14 (CP14) supports: — debug, see Chapter C6 Debug Register Interfaces — the Thumb Execution Environment, see Thumb Execution Environment on page A2-95 — direct Java bytecode execution, see Jazelle direct bytecode execution support on page A2-97. Coprocessors 10 and 11 (CP10 and CP11) together support floating-point and vector operations, and the control and configuration of the Floating-point and Advanced SIMD architecture extensions. Coprocessors 8, 9, 12, and 13 are reserved for future use by ARM. Any coprocessor access instruction attempting to access one of these coprocessors is UNDEFINED Coprocessors 0 to 7 can provide vendor-specific features. LDC: cond 1 1 0 P U D W 1 Rn CRd coproc imm8 if Rn == ‘1111’ then SEE LDC (literal); if P == ‘0’ && U == ‘0’ && D == ‘0’ && W == ‘0’ then UNDEFINED; if P == ‘0’ && U == ‘0’ && D == ‘1’ && W == ‘0’ then SEE MRRC, MRRC2; if coproc IN “101x” then SEE “Advanced SIMD and Floating-point”; LDC2: 1 1 1 1 1 1 0 P U D W 1 Rn CRd coproc imm8 if Rn == ‘1111’ then SEE LDC (literal); if P == ‘0’ && U == ‘0’ && D == ‘0’ && W == ‘0’ then UNDEFINED; if P == ‘0’ && U == ‘0’ && D == ‘1’ && W == ‘0’ then SEE MRRC, MRRC2; if coproc IN “101x” then UNDEFINED;
Coprocessor 15 (CP15) provides system control functionality.
Coprocessor 14 (CP14) supports:
— debug, see Chapter C6 Debug Register Interfaces
— the Thumb Execution Environment, see Thumb Execution Environment on page A2-95
— direct Java bytecode execution, see Jazelle direct bytecode execution support on page A2-97.
Coprocessors 10 and 11 (CP10 and CP11) together support floating-point and vector operations, and the
control and configuration of the Floating-point and Advanced SIMD architecture extensions.
Coprocessors 8, 9, 12, and 13 are reserved for future use by ARM. Any coprocessor access instruction
attempting to access one of these coprocessors is UNDEFINED
Coprocessors 0 to 7 can provide vendor-specific features.
LDC:
cond 1 1 0 P U D W 1 Rn CRd coproc imm8
if Rn == ‘1111’ then SEE LDC (literal);
if P == ‘0’ && U == ‘0’ && D == ‘0’ && W == ‘0’ then UNDEFINED;
if P == ‘0’ && U == ‘0’ && D == ‘1’ && W == ‘0’ then SEE MRRC, MRRC2;
if coproc IN “101x” then SEE “Advanced SIMD and Floating-point”;
LDC2:
1 1 1 1 1 1 0 P U D W 1 Rn CRd coproc imm8
if coproc IN “101x” then UNDEFINED;
To my understanding the same CRd and coproc goes to either encodings except cp10 and cp11.
10, cr0, [r1, #4]
1 1 1 1 1 1 0 1 1 0 0 1 0 0 0 1 0 0 0 0 1 0 1 0 0 0 0 0 0 0 0 1 = 0xfd910a01
P=1, U=1, D=0, W=0, Rn= r1, CRd= cr0, coproc=10, imm=1
Looks like the disassembler doesn't disassemble the ldc2 into vldrs0, [r1, #4],
[EDIT] And it shouldn't, but should it mark it UNDEFINED or something... [/EDIT]
I guess they are the same, but it's hard to tell - there seems to be no info about coproc 10 registers,
except system registers (accessed via CP15).
I looked into these:
DDI0406C_C_arm_architecture_reference_manual.pdf,
DDI0462F_cortex_a7_neon_mpe_r0p5_trm.pdf
DDI0463F_cortex_a7_fpu_r0p5_trm.pdf
Any idea/hunch/good guess/not-so-good guess where to look next?
I reviewed the ARM ARM and came to the thought that cond=4'b1111 instructions (i.e. MCRR2, MRRC2, STC2. LDC2. CDP2, MCR2 and MRC2) were currently valid only for the coprocessor 10 and 11.
Therefore, you would be probably right.
Another "good" question: why are coprocs 10 and 11 OK with LDC,but not with LDC2, while all other coprocs are OK with both? Could it be some future expansion of fp/vector instructions via LDC2 only? (I'm talking about LDC and LDC2, but the same applies for all coproc instructions:MRC/MRC2, ...) Anyway, strange asymmetry...
Regarding this, I agree with you. It would be a mystery.
View all questions in Cortex-A / A-Profile forum