[PATCH v1] x86: Support Zhaoxin RNG2 instruction

[Mayshao-oc]

> > From: Mayshao-oc <Mayshao-oc@zhaoxin.com>
> > Sent: Tuesday, January 7, 2025 7:04 PM
> >
> > > On 07.01.2025 04:08, Mayshao-oc wrote:
> > > >> On 30.12.2024 10:20, Mayshao-oc wrote:
> > > >>>      This patch adds support for Zhaoxin RNG2 instruction.
> > > >>>      Test ok, ok for trunk?
> > > >>
> > > >> The change to output_insn() needs at least indenting correctly.
> > > >> The two
> > > >> ||-s don't really belong to the same level of the expression.
> > > >> ||Even better
> > > >> would imo be to use (!is_cpu (&i.tm, CpuPadLock) && !is_cpu
> > > >> (&i.tm,
> > CpuRNG2)) instead of the 2nd nested ||.
> > > > Thanks for your review. The indenting is definitely wrong, I will correct it.
> > > > As to || and &&, I don't understand why (!is_cpu (&i.tm,
> > > > CpuPadLock)
> > && !is_cpu (&i.tm, CpuRNG3)) is better?
> > > > In respect of performance, I think compiler will produce the same
> > > > assembly
> > code for ||-s form and  && form.
> > > > Maybe && form helps to readability?
> > >
> > > It's entirely about readability, yes. The compiler is free to
> > > transform one form
> > into the other anyway.
> >      Thanks for your comments.
> > >
> > > >> Speaking of RNG2 - we can only hope that no other vendor will
> > > >> come up
> > with a similarly abbreviated random number generator feature. The name
> > is pretty generic, after all. H.J. - what do you think?
> > > >>
> > > >> Is there a connection between PadLock and RNG2? Does RNG2 perhaps
> > even imply PadLock as a prereq feature (wanting a dependency recorded
> > in i386-gen.c)? If so, naming it "PadLockRNG2" may be an option to
> > avoid a potential future clash.
> > > > Yes, there is a connection. I think it's reasonable to naming it
> > "PadLockRNG2", I will rename it.
> > >
> > > Well, if there's a connection, then (as said) the dependency also
> > > wants
> > recording in i386-gen.c.
> >     Ok, you mean add an element in isa_dependencies[],like
> > {"PadLockRNG2", "PadLock"}?
> >     Assambler need this depenency information to do some check? I will
> > take a while to understand this.
>
> It will help you enable PadLock when enabling PadLockRNG2 instead of only enabling PadLockRNG2 insns only. If there is a connection (or imply) between them from documentation,  programmers will have the impression that the base feature should have been enabled when enabling the extension feature. Thus, they will use all the asm in both base and extension features. Then if you don't add them in the table, it might break the code with unsupported inst.
   Thanks for your comments, it helps a lot. I test "as -march=generic64+padlockrng2 padlock.s" and the assembler not complains instruction not support.If I don't add them in the table, assembler will print instruction is not supported.
BTW: Whether gcc -march=xxx will imply a -march=xxx to assembler in gcc driver and do some check? I am curious about this.
>
> Thx,
> Haochen
BR
MayShao