aarch64 nop instruction

aarch64 nop instruction

[Eliot Miranda]

Hi All,

    I use gdb for processor simulation in a Smalltalk JIT.  I am using gdb
8.3.1 to derive an aarch64 (ARMV8) simulator.  I have noticed that 8.3.1
does not disassemble Arm's "approved" not instruction.

The approved nop is 2r1101010100000011001000000001111, 0x6a81900f, see
C6.2.202 on p 252 of
https://developer.arm.com/docs/ddi0487/ea/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile.
When I use the 8.3.1 derived system to disassemble that nop I get e.g.
00000000: .inst 0x6a81900f ; undefined


The entry in opcodes/aarch64-tbl.h for the nop that does disassemble is

CORE_INSN ("nop", 0xd503201f, 0xffffffff, ic_system, 0, OP0 (), {}, F_ALIAS)

I've tried adding
CORE_INSN ("nop", 0x6a81900f, 0xffffffff, ic_system, 0, OP0 (), {}, F_ALIAS)
which leaves 0xd503201f unaffected but still yields "undefined" for the
:"approved" nop.

I've tried adding
  CORE_INSN ("nop", 0x6a81900f, 0xffffffff, log_shift, 0, OP0 (), {},
F_HAS_ALIAS),
with the 0ther 0x6a opcodes, e.g.
  CORE_INSN ("bics", 0x6a200000, 0x7f200000, log_shift, 0, OP3 (Rd, Rn,
Rm_SFT), QL_I3SAMER, F_SF),
and this breaks the other nop, 0xd503201f, and both forms print as
undefined.

While I think that not disassembling the official nop is a bug I'm really
more interested in finding out what the minimal change to the table is to
get the "approved" nop to disassemble.  Can anyone help?
_,,,^..^,,,_
best, Eliot

Re: aarch64 nop instruction

[Andrew Pinski]

On Wed, Nov 20, 2019 at 1:31 PM Eliot Miranda <eliot.miranda@gmail.com> wrote:
>
> Hi All,
>
>     I use gdb for processor simulation in a Smalltalk JIT.  I am using gdb
> 8.3.1 to derive an aarch64 (ARMV8) simulator.  I have noticed that 8.3.1
> does not disassemble Arm's "approved" not instruction.
>
> The approved nop is 2r1101010100000011001000000001111, 0x6a81900f, see

Resent out with the attached picture so it would goto the gdb list.

Wait I think you are reading the number wrong and the ARM ARM incorrectly.
I see
(gdb) p/t 0xd503201f
$2 = 11010101000000110010000000011111

This is exactly what is written in the ARM ARM as far as I can see.
See attached picture.
It ends in 5 1's which is 0x1f (you missed the one 1 too).  starts
with 1101 which is 0xd.  I don't see where you get 6a from either.
Are you thinking the value in memory; so you are reading it as a
little-endian value or something different?


Thanks,
Andrew Pinski


> C6.2.202 on p 252 of
> https://developer.arm.com/docs/ddi0487/ea/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile.
> When I use the 8.3.1 derived system to disassemble that nop I get e.g.
> 00000000: .inst 0x6a81900f ; undefined
>
>
> The entry in opcodes/aarch64-tbl.h for the nop that does disassemble is
>
> CORE_INSN ("nop", 0xd503201f, 0xffffffff, ic_system, 0, OP0 (), {}, F_ALIAS)
>
> I've tried adding
> CORE_INSN ("nop", 0x6a81900f, 0xffffffff, ic_system, 0, OP0 (), {}, F_ALIAS)
> which leaves 0xd503201f unaffected but still yields "undefined" for the
> :"approved" nop.
>
> I've tried adding
>   CORE_INSN ("nop", 0x6a81900f, 0xffffffff, log_shift, 0, OP0 (), {},
> F_HAS_ALIAS),
> with the 0ther 0x6a opcodes, e.g.
>   CORE_INSN ("bics", 0x6a200000, 0x7f200000, log_shift, 0, OP3 (Rd, Rn,
> Rm_SFT), QL_I3SAMER, F_SF),
> and this breaks the other nop, 0xd503201f, and both forms print as
> undefined.
>
> While I think that not disassembling the official nop is a bug I'm really
> more interested in finding out what the minimal change to the table is to
> get the "approved" nop to disassemble.  Can anyone help?
> _,,,^..^,,,_
> best, Eliot

Re: aarch64 nop instruction

[Andrew Pinski]

On Wed, Nov 20, 2019 at 2:09 PM Andrew Pinski <pinskia@gmail.com> wrote:
>
> On Wed, Nov 20, 2019 at 1:31 PM Eliot Miranda <eliot.miranda@gmail.com> wrote:
> >
> > Hi All,
> >
> >     I use gdb for processor simulation in a Smalltalk JIT.  I am using gdb
> > 8.3.1 to derive an aarch64 (ARMV8) simulator.  I have noticed that 8.3.1
> > does not disassemble Arm's "approved" not instruction.
> >
> > The approved nop is 2r1101010100000011001000000001111, 0x6a81900f, see
>
> Resent out with the attached picture so it would goto the gdb list.
>
> Wait I think you are reading the number wrong and the ARM ARM incorrectly.
> I see
> (gdb) p/t 0xd503201f
> $2 = 11010101000000110010000000011111
>
> This is exactly what is written in the ARM ARM as far as I can see.
> See attached picture.
> It ends in 5 1's which is 0x1f (you missed the one 1 too).  starts
> with 1101 which is 0xd.  I don't see where you get 6a from either.
> Are you thinking the value in memory; so you are reading it as a
> little-endian value or something different?

Just FYI:
(gdb) p/x 0x6a81900f<<1|1
$6 = 0xd503201f

It does look like you are missing the last 1 when you were reading the
ARM ARM :).

Thanks,
Andrew Pinski

>
>
> Thanks,
> Andrew Pinski
>
>
> > C6.2.202 on p 252 of
> > https://developer.arm.com/docs/ddi0487/ea/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile.
> > When I use the 8.3.1 derived system to disassemble that nop I get e.g.
> > 00000000: .inst 0x6a81900f ; undefined
> >
> >
> > The entry in opcodes/aarch64-tbl.h for the nop that does disassemble is
> >
> > CORE_INSN ("nop", 0xd503201f, 0xffffffff, ic_system, 0, OP0 (), {}, F_ALIAS)
> >
> > I've tried adding
> > CORE_INSN ("nop", 0x6a81900f, 0xffffffff, ic_system, 0, OP0 (), {}, F_ALIAS)
> > which leaves 0xd503201f unaffected but still yields "undefined" for the
> > :"approved" nop.
> >
> > I've tried adding
> >   CORE_INSN ("nop", 0x6a81900f, 0xffffffff, log_shift, 0, OP0 (), {},
> > F_HAS_ALIAS),
> > with the 0ther 0x6a opcodes, e.g.
> >   CORE_INSN ("bics", 0x6a200000, 0x7f200000, log_shift, 0, OP3 (Rd, Rn,
> > Rm_SFT), QL_I3SAMER, F_SF),
> > and this breaks the other nop, 0xd503201f, and both forms print as
> > undefined.
> >
> > While I think that not disassembling the official nop is a bug I'm really
> > more interested in finding out what the minimal change to the table is to
> > get the "approved" nop to disassemble.  Can anyone help?
> > _,,,^..^,,,_
> > best, Eliot

Re: aarch64 nop instruction

[Eliot Miranda]

Hi Andrew,

    thanks, yes.  I had made the mistake of typing 4 trailing 1's instead
of 5.  Apologies for the noise.

On Wed, Nov 20, 2019 at 2:02 PM Andrew Pinski <pinskia@gmail.com> wrote:

> On Wed, Nov 20, 2019 at 1:31 PM Eliot Miranda <eliot.miranda@gmail.com>
> wrote:
> >
> > Hi All,
> >
> >     I use gdb for processor simulation in a Smalltalk JIT.  I am using
> gdb
> > 8.3.1 to derive an aarch64 (ARMV8) simulator.  I have noticed that 8.3.1
> > does not disassemble Arm's "approved" not instruction.
> >
> > The approved nop is 2r1101010100000011001000000001111, 0x6a81900f, see
>
> Wait I think you are reading the number wrong and the ARM ARM incorrectly.
> I see
> (gdb) p/t 0xd503201f
> $2 = 11010101000000110010000000011111
>
> This is exactly what is written in the ARM ARM as far as I can see.
> See attached picture.
> It ends in 5 1's which is 0x1f (you missed the one 1 too).  starts
> with 1101 which is 0xd.  I don't see where you get 6a from either.
> Are you thinking the value in memory; so you are reading it as a
> little-endian value or something different?
>
>
> Thanks,
> Andrew Pinski
>
>
> > C6.2.202 on p 252 of
> >
> https://developer.arm.com/docs/ddi0487/ea/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile
> .
> > When I use the 8.3.1 derived system to disassemble that nop I get e.g.
> > 00000000: .inst 0x6a81900f ; undefined
> >
> >
> > The entry in opcodes/aarch64-tbl.h for the nop that does disassemble is
> >
> > CORE_INSN ("nop", 0xd503201f, 0xffffffff, ic_system, 0, OP0 (), {},
> F_ALIAS)
> >
> > I've tried adding
> > CORE_INSN ("nop", 0x6a81900f, 0xffffffff, ic_system, 0, OP0 (), {},
> F_ALIAS)
> > which leaves 0xd503201f unaffected but still yields "undefined" for the
> > :"approved" nop.
> >
> > I've tried adding
> >   CORE_INSN ("nop", 0x6a81900f, 0xffffffff, log_shift, 0, OP0 (), {},
> > F_HAS_ALIAS),
> > with the 0ther 0x6a opcodes, e.g.
> >   CORE_INSN ("bics", 0x6a200000, 0x7f200000, log_shift, 0, OP3 (Rd, Rn,
> > Rm_SFT), QL_I3SAMER, F_SF),
> > and this breaks the other nop, 0xd503201f, and both forms print as
> > undefined.
> >
> > While I think that not disassembling the official nop is a bug I'm really
> > more interested in finding out what the minimal change to the table is to
> > get the "approved" nop to disassemble.  Can anyone help?
> > _,,,^..^,,,_
> > best, Eliot
>


-- 
_,,,^..^,,,_
best, Eliot