Earlier quoted context omitted.
Yeah, RISC should have been called CISC, Cray Instruction Set Computer.
Well it is the fifth RISC ISA from the people who invented RISC.
CRRRRRISC then
Programming with RISC-V Vector Instructions
21–30 of 38 posts
Re: Programming with RISC-V Vector Instructions
#22Pretty cool. For RISC-V experts out there, can someone explain to me the purpose of the proxy kernel? I can't seem to wrap my head around it. Why not just run a normal kernel (e.g. Linux) on top of the emulator? What advantages/disadvantages does the proxy kernel have?
It gives you a hardware testing environment with system calls for reasonable amounts of wall clock time. If you're simulating actual hardware, e.g., a Verilog description of a RISC-V microprocessor compiled to a cycle-accurate simulation with Verilator, your simulation rate is going to be ~10KHz. You can write useful tests with the Proxy Kernel (or something like it) that run in ~1 million instructions (minutes of wa…
Nitpick: printf is is a libc call.
Re: Programming with RISC-V Vector Instructions
#23Whoa, that's a well designed ISA.
The vector extension yes, the C (compressed) extension is unusual: you can have 32 bits instructions aligned on 16bit, while nice for code density this means that the implementation is much more complex than Thumb/MIPS16 extensions..
Re: Programming with RISC-V Vector Instructions
#24Irrelevant i know, but: > For the purpose of our example, the exercise is to write vector code that efficiently converts a BCD string such as { 0x12, 0x34, ..., 0xcd, 0xef } to a corresponding ASCII string (e.g. { '1', '2', '3', '4', ..., 'c', 'd', 'e', 'f' }). On a high-level, a solution involves separating the nibbles into single bytes and then converting each byte to the matching ASCII value. If your BCD string ha…
> This code converts a byte string to its hex representation. It has nothing to do with BCD, right?
BCD to ASCII is a strict subset of bin to hex ASCII; and in this case there is no runtime cost to supporting both. This also covers nybble-coded octal.
Re: Programming with RISC-V Vector Instructions
#25Whoa, that's a well designed ISA.
The vector extension yes, the C (compressed) extension is unusual: you can have 32 bits instructions aligned on 16bit, while nice for code density this means that the implementation is much more complex than Thumb/MIPS16 extensions..
RISC-V has a variable-length instruction encoding. It's just that unlike x86 you can easily tell from parsing a few bits the length of every instruction in the stream, and like MIPS etc most "ordinary" instructions are 32 bit.
BTW if unaligned 32 bit instructions are a concern there is a Compressed NOP (C.NOP == addi x0, x0, 0 but without RAW hazards).
Re: Programming with RISC-V Vector Instructions
#26Is there a big penalty for context switching to another process that uses a different vector length?
Re: Programming with RISC-V Vector Instructions
#27What's the deal with the group sizes here? vsetvli t0, a6, e8, m8 # switch to 8 bit element size, # i.e. 4 groups of 8 registers vmsgtu.vi v0, v8, 9 # set mask-bit if greater than unsigned immediate # --> v0 = | 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 | If vsetvli results in groups of 8 registers, then surely vmsgtu.vi only affects v0 which is the first 8 registers? The following 8 are in v8 if I understood th…
As I understand it, it affects the whole “group” at v0, and it’s only storing 16 8-bit elements which likely fit in the full 8 registers you have grouped together. (That is, it’s not storing one element per register, I’m not sure exactly how the layout is but it’s probably packing them somewhere along the lines of, if the register size was 64 bit, v8 would be 0x0706050403020100, v9 would be 0x0f0e0d0c0b0a0908, and th…
AIUI the group size is a trade-off between the number of independently addressable vectors and the vector size. If the group size were always set to eight then you could only have four distinct vectors, whereas a group size of one would give you 32 vectors. You want to use the largest group size you can to take full advantage of the hardware, but you're limited by the number of vectors required by your algorithm. This is orthogonal to the size of an element within each vector.
The current RISC-V "V" draft standard requires the vector registers to be at least 32 bits wide (VLEN ≥ SLEN ≥ 32)[1], so a 128-bit vector with 16 8-bit elements may require up to four registers. Setting the group size to eight is a bit extravagant, but since the total number of elements was limited to 16 any extra registers in the group will not be affected. With a smaller group size you could potentially use those registers for something else.
P.S. I think you have the mask bits reversed. The instruction is "set if greater than" so v1 should be 0x0101010101010000 and v0 should be 0x0000000000000000 (corresponding to the |1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0| state shown in the article for the combined v1:v0 register group).
Re: Programming with RISC-V Vector Instructions
#28Is there a big penalty for context switching to another process that uses a different vector length?
It’s really funny that you asked this because I clicked on the RISC-V “V” extension spec on GitHub, and literally the only thing I read was “you can’t context switch to another CPU with different vector lengths”.
EDIT: Non-layman wording
> Thread contexts with active vector state cannot be migrated during execution between harts that have any difference in VLEN or ELEN parameters.
https://github.com/riscv/riscv-v-spec/blob/master/v-spec.ado...
Re: Programming with RISC-V Vector Instructions
#29Is there a big penalty for context switching to another process that uses a different vector length?
It’s really funny that you asked this because I clicked on the RISC-V “V” extension spec on GitHub, and literally the only thing I read was “you can’t context switch to another CPU with different vector lengths”. EDIT: Non-layman wording > Thread contexts with active vector state cannot be migrated during execution between harts that have any difference in VLEN or ELEN parameters. https://github.com/riscv/riscv-v-spe…
Very cool, thanks.
Re: Programming with RISC-V Vector Instructions
#30Earlier quoted context omitted.
The vector extension yes, the C (compressed) extension is unusual: you can have 32 bits instructions aligned on 16bit, while nice for code density this means that the implementation is much more complex than Thumb/MIPS16 extensions..
RISC-V has a variable-length instruction encoding. It's just that unlike x86 you can easily tell from parsing a few bits the length of every instruction in the stream, and like MIPS etc most "ordinary" instructions are 32 bit. BTW if unaligned 32 bit instructions are a concern there is a Compressed NOP (C.NOP == addi x0, x0, 0 but without RAW hazards).
C.Nop isn't a solution, if you implement a compliant RISC V processor with the C extension you need to handle all the possible case, for example an instruction straddling several pages.