SIMD Implementation

[subhajit26]

Hi,
Is there any intrinsic or builtin function which can load multiple data from memory into one big register in single load instruction maybe with some sort of custom stride. Please suggest with any resources or references that can help me with the intrinsic or may be some way to implement a custom instruction with the required functionality.
An example of the functionality that I want, would be like below:
Dest_reg <- Load A[1:0]

[jim-wilson]

There is the V vector extension and the P packed extension, both of which can load multiple items into a register, and both of which are still in development, but some experimental hardware and software support is available. You can find info on the V extension programming model here
https://github.com/riscv/rvv-intrinsic-doc
and the architecture extension info is here
https://github.com/riscv/riscv-v-spec
Info on the P extension is here
https://github.com/riscv/riscv-p-spec
I don't know if they have a programming model defined.

I think that there are more companies working on vector support than packed support.

[subhajit26]

Hi Jim,
To implement the vector intrinsic load functions do we need to build the tool-chain with V extension along with RV32IMC because I will be implementing this intrinsic in FFT algorithm and then I have to add the support for same in hardware that is ibex core and Ibex does not support vector extension as of now. Regarding the spike it is alright since I can add the extension V while executing the spike because the same I am doing for P extension instruction but those Packed instructions worked with even without adding P-extension to riscv-elf tool-chain. Please suggest .

Regarding Spike I have doubt whether spike supports rv32emc or not. If it does, then do I have to build it in a same way as I did for rv32imc. Because I tried the configure command of the spike with arch = rv32imc, abi=ilp32e but that says invalid. Please suggest is there any work around to make spike support rv32emc.

[jim-wilson]

You need to use a toolchain source tree that includes the V support, but you don't need to configure for V support. You can specify V at compile time using e.g. -march=rv32imcv. However, it you want standard library support for V, then you need to configure for V, or build with multilibs and configure in at least one multilib with V support. However, I think there is no V support yet in standard libraries.

The P support should work the same. If you can generate P instructions without specifying the P extension, then that is a toolchain bug that will have to be fixed before the patch can be upstreamed.

Current V toolchain development work is in LLVM, and I don't follow LLVM, so I can't comment on that. There is a GNU toolchain with V support on the rvv-intrinsic branch of riscv-gnu-toolchain, but it is out of date, and we don't know when it will be updated.

I don't know where the P toolchain support is as I haven't been following the P extension.

I'm not a spike expert, and spike is not part of the toolchain. I know that there is a branch somewhere with V support on it. I don't know about P, but I would expect the same.

I'm not a spike expert. I don't know if spike has E support. qemu and gdb sim (non upstream) have E support.

[jim-wilson]

arch=rv32imc abi=ilp32e is not supported. if you want to use the ilp32e abi, then you have to use rv32e* for arch.

[subhajit26]

Hi,
I am trying to implement a custom instruction -> "absd" which will perform the absolute value of difference between 2 signed 32 bit values.
The functionality I have implemented to verify in ISS is :

if(sext_xlen(RS1) >= sext_xlen(RS2))
  WRITE_RD(sext_xlen(sext_xlen(RS1) - sext_xlen(RS2)));
else
  WRITE_RD(sext_xlen(sext_xlen(RS2) - sext_xlen(RS1)));

In tool-chain in riscv-opc.c I implemented the instruction as:
{"absd", 0, INSN_CLASS_I, "d,s,t", MATCH_ABSD, MASK_ABSD, match_opcode, 0},
and it gives me illegal instruction executed in Instruction set simulator.
Do I need to write the instruction as below:
{"absd", 0, INSN_CLASS_I, "d,s,t", MATCH_ABSD, MASK_ABSD, match_opcode, INSN_CONDBRANCH},
Is it because of the functionality that I have defined is based on bge condition? Please suggest because the riscv-opc.h file has been updated in a proper way. I just have a doubt that may be in riscv-opc.c file I implement the instruction using INSN_CONDBRANCH.

[jim-wilson]

You don't need INSN_CONDBRANCH. That is only for branches, and is used by some tools to help with decompiling.

it looks like the simulator and assembler are using different encodings for the instruction. So you need to double check that.

[TommyMurphyTM1234]

The rvv-next branch (https://github.com/riscv-collab/riscv-gnu-toolchain/tree/rvv-next) is where implementation/enhancement of V (Vector) extension v1.0 support is ongoing. The P (Packed SIMD) extension is still only in draft form (https://github.com/riscv/riscv-p-spec) and one version of experimental support is in a still pending PR (riscvarchive/riscv-gcc#258).