On 13 November 2013 07:09, Yufeng Zhang<Yufeng.Zhang@arm.com> wrote:
Hi Zhenqiang,
On 11/12/13 06:12, Zhenqiang Chen wrote:
Hi,
Current parse_sys_reg only supports s3_<op1>_<Cn>_<Cm>_<op2>. But
according to the document,
integer sys_op0 = 2 + UInt(o0)
o0 is bit-19.
So sys_op0 can be 2 or 3.
This patch changes GAS to to add s2_<op1>_<Cn>_<Cm>_<op2> support.
OK for trunk?
For MSR/MRS instruction, it is correct that sys_op0 can be 2 or 3. However,
it doesn't necessarily mean that the encoding space of sys_op0==2 contains
reserved area for implementation defined system registers.
The ARMARMv8 mentions in section C4.2.6 "Op0==0b11, Moves to and from
non-debug System registers and special-purpose registers" that:
"The instructions that move data to and from non-debug system registers are
encoded with Op0==0b11, except that some of this encoding space is reserved
for IMPLEMENTATION DEFINED functionality."
The document however doesn't mention about the implementation defined
functionality in section C4.2.5 "Op0==0b10, Moves to and from debug, qtrace,
and Execution environment System registers".
C4.2.5
...
This section includes **only** the System register access encodings
for which both:
* Op0 is 0b10.
* The value of Op1 is one of {0, 3, 4}.
So this section only covers "Debug" registers, not "Trace" and
"Execution environment" registers.
Section C5.6.129 defines the full encode.
Is there any named system register in the op0==0b10 encoding space that you
would like to add support for, by extending the syntax?
I do not know. Maybe customers can define some registers and map them
to s2_<op1>_<Cn>_<Cm>_<op2>.
Also if we go head with the patch, please also add some tests to
gas/testsuite/gas/aarch64/sysreg.[d|s].
Thanks. Patch is updated to include tests.
-Zhenqiang