[PATCH v4 2/3] RISC-V: Scalar crypto instructions and operand set

[Markku-Juhani O. Saarinen]

On Tue, Jan 4, 2022 at 8:49 AM Jan Beulich <jbeulich@suse.com> wrote:

>
> > > For these two and a few more with immediate operands and a trailing
> 'i'
> > > in the mnemonics: Shouldn't they have i-suffix-less pseudos,
> matching
> > > other insns with immediate operands?
> > >
> > > Jan
> >
> > I think the 'i' trailing is just a dinstinguishing symbol in zknd
> extension, there are no i-suffix-less pseudo definitions in the cryptogrpah
> extension spec, please check it.
>
> Perhaps I should have said explicitly that this is a question not so much
> on the implementation, but on the spec itself.
>

Hi,

I agree that it's a bit odd that sm4* instructions don't have an "i" but
equivalent-format aes32* instructions have it. Hence I wouldn't assign too
much meaning to the "i" here; there is no equivalent "register input"
version for these as there would be with something like "addi" vs "add".
For 32-bit aes/sm4 the immediate refers to a 2-bit field that could have
even been incorporated into the mnemonic (e.g. sm4ed0, sm4ed1, sm4ed2,
sm4ed3) -- to me, these instructions fundamentally have an R-type encoding.
For aes64ks1i it's a 4-bit value holding 0x0..0xA.

If we consider C language intrinsics, passing a variable as an immediate
for K extension instruction needs to be an illegal operation: if the
compiler generates some kind of switch-case statement, that is unlikely to
be constant-time and defeats half of the purpose of the instruction. At
least the inline assembler headers work this way; I hope proper builtins
will fault at attempts to use variables too.

Wrt to "the spec", the Scalar K spec was ratified in November. In the
RISC-V process, ISA ratification means that those mnemonics are beyond
"stable" and "freeze" stages in terms of unmovability. That would require
really serious technical arguments. The consistency of mnemonic and opcode
assignments is really a matter for the top architecture committee chairs,
so even us in the committee that authored that spec did not have final
control over them. Krste & Co changed some of the mnemonics (such as the
names of xperm4 and xperm8) as late as August, before the ratification.

One more thing about intrinsics: If we consider also Bitmanip intrinsics,
my take is that if an instruction has both immediate and register-based
form, it makes obvious sense to combine them into the same intrinsic (e.g.
GREV and GREVI would be better served by a single intrinsic, even though
they are separate mnemonics). K instructions only have one form -- one
avoids confusion by using the mnemonic name to create an intrinsic function
(with a consistent prefix). That's how the current C language intrinsic
proposal works.

Cheers,
- markku

Dr. Markku-Juhani O. Saarinen <mjos@pqshield.com> PQShield, Oxford UK.


>
> Jan
>
>