This document describes the work necessary to implement support the scalar crypto extension in GCC and Binutils.
We currently have experimental patches for Binutils in the same
directory as this file (patch-binutils.patch
).
This has been used to develop benchmarks and compliance tests, but
cannot be upstreamed because
-
The author (Ben) doesn’t have an FSF copyright assignment and
-
has no experience contributing to GCC or Binutils, so the coding style might be off and
-
It is incomplete: it doesn’t implement the feature groupings properly.
The purpose of this document is to describe the necessary work for creating an upstream appropriate patch, in the hope that someone who is well qualified to do so can follow it.
Note
|
This doc was written by someone with very cursory experience of hacking on GCC and Binutils. Please forgive any transgressions as appropriate. |
Broadly, the scalar crypto extension only needs Binutils and intrinsics support for instructions exclusive to it. It also shares some instructions with Bitmanip, which should be available to the compiler if either the relevant Bitmanip or scalar crypto feature sets are enabled.
Instruction Opcodes can be generated by running
make opcodes
From the root of this repository. The resulting C code files are placed
in the build/
directory.
These files contain the MATCH_
and MASK_
macros for defining the
encodings:
#ifndef RISCV_ENCODING_H #define RISCV_ENCODING_H #define MATCH_SM4ED 0x800302b #define MASK_SM4ED 0x3e00707f #define MATCH_SM4KS 0xa00302b [...]
These generated macros can be pasted directly into
include/opcode/riscv-opc.h
in the Binutils source tree.
They also contain most of the code needed to describe the assembly code syntax at the very end of the file. For example, it generates
{"sm4ed" , 0, INSN_CLASS_K, "d,s,t,w", MATCH_SM4ED, MASK_SM4ED, match_opcode, 0}, {"sm4ks" , 0, INSN_CLASS_K, "d,s,t,w", MATCH_SM4KS, MASK_SM4KS, match_opcode, 0}, [...]
Which can be mostly just pasted into opcodes/riscv-opc.c
in the
binutils source tree.
Modifications are needed to specify which instructions
are RV32/RV64 only and the feature groups they belong too, which is described
in section 2 of the
specification.
The scalar crypto extension adds two CSRs, detailed in the
Entropy Source section of the specification: mnoise
and mentropy
.
These need adding to the list of CSRs recognised by Binutils.
Additionally, there are two pseudo instructions defined, which alias
csrr
instructions:
-
pollentropy rd
- Alias forcsrrs rd, mentropy, x0
. -
getnoise rd
- Alias forcsrrs rd, mnoise , x0
.
The scalar crypto extension introduces two new immediate fields:
-
bs
- used by the 32-bit AES instructions, and the SM4 instructions. It is 2 bits wide. -
rcon
- Used by theaes64ks1
instruction. 4-bits wide. The assembler should only allow values0⇐rcon⇐0xA
. Valuesrcon>0xA
are ignored by the instruction in hardware.
The patch shows how these were added up to now.
Most of the modifications are in gas/config/tc-riscv.c
of the
binutils source tree.
Constants to define their size and position were added in
include/opcode/riscv.h
, and disassembly information
was added in opcodes/riscv-dis.c
.
Feature groups for the scalar crypto extension are described in section 2 of the specification.
These have not been implemented at all in the current patches. It is expected that they can be added in a very similar way to the existing Bitmanip feature groups.
The additional complexity comes from some instructions being shared between Bitmanip and the scalar crypto extension.
There are two components to the GCC support:
-
Implementing the parsing for the
-march
string features, per the feature groups described in the specification. -
Making sure the compiler can use the set of Bitmanip instructions which are shared with the scalar crypto extension when either of the extensions are enabled.
We do not expect the compiler to use the complex algorithm specific instructions.
Note
|
It might be possible to write a matching pattern for the SHA2 and SM3 instructions, but this is not necessary for inital support. |