SV setvl exploration

Formats for Vector Configuration Instructions under OP-V major opcode:

Requirement: fit MVL into this format.

where:

• when bit 31==0, both MVL and VL are set to imm(10:6) - plus one to get it out of the "NOP" scenario.
• when bit 31==1, MVL is set to imm(5:0) plus one.

hang on... no, that's a 4-argument setvl! what about this?

i think those are the 8 permutations: what can those be used for? some of them for actual instructions (brownfield encodings).

notes:

• there's no behavioural difference between the vsetvl version and the vsetvli version. that needs fixing (somehow, doing something)
• the above 4 fit into the "rs2 == x0" case, leaving "rs2 != x0" for brownfield encodings.

original encoding

Selected encoding for sv.setvl, see http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-June/001898.html

The encoding I (programmerjake) was planning on using is:

It leaves space for future expansion to RV128 and/or multi-register predicates.

it's the opcode and funct7 that are actually used to determine the instruction for almost all RISC-V instructions, therefore, I think we should use the lower bits of the immediate in I-type to encode MAXVL. This also has the benefit of simple extension of VL/MAXVL since the bits immediately above the MAXVL field aren't used. If a new instruction wants to be able to use rs2, it simply uses the encoding with bit 31 set, which already indicates that rs2 is wanted in the V extension.

yep, good logic.

pseudocode

regs = [0u64; 128];
vl = 0;

// instruction fields:
rd = get_rd_field();
rs1 = get_rs1_field();
vlmax = get_immed_field();

// handle illegal instruction decoding
if vlmax > XLEN {
    trap()
}

// calculate VL
if rs1 == 0 { // rs1 is x0
    vl = vlmax
} else {
    vl = min(regs[rs1], vlmax)
}

// write rd
if rd != 0 {
    // rd is not x0
    regs[rd] = vl
}

questions

https://libre-riscv.org/simple_v_extension/appendix/#strncpy

GETVL add1 SETVL is a pain. 3 operations because VL is a CSR it is not possible to perform arithmetic on it.

What about actually marking one of the registers as VL? this would save a lot of instructions.

https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/7lt9YNCR_bI/8Hh2-UY6AAAJ

(2) as it is the only one, VL may be hardware-cached, i.e. the fact that it points to a scalar register, well, that's only 5 bits: that's not very much to pass round and through pipelines.

(3) if it's not very much to pass around, then the possibility exists to rewrite a CSRR VL instruction to become a MV operation, at execution time!

yes, really: at instruction decode time, with there being only the 5 bits to check "if VL-cache-register is non-zero and CSR register == VL", it's really not that much extra logic to directly substitute the CSRR instruction with "MV rd, VL-where-VL-is-actually-the-contents-of-the-VL-cache"

that would then allow the substituted-instruction to go directly into dependency-tracking on the scalar register, nipping in the bud the need for special CSR-related dependency logic, and no longer requiring the sub-par "stall" solution, either.

Hang on - CSRR rd, VL needs to return the register number, not the contents of tgat register number. So it's ok.

Setting VL from an immed without altering MVL is not possible in the above pseudocode. It is covered by VLtyp and the VL block in VBLOCK, however is that enough?

links

• http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-June/001881.html
• https://groups.google.com/d/msg/comp.arch/MLfqE8Rm-X4/zHLCHg6UAQAJ