Would something like this be possible for FPUs as well? I see there are currently three separate extensions for floating point instructions varying by register widths.
Programming with RISC-V Vector Instructions
11–20 of 38 posts
Re: Programming with RISC-V Vector Instructions
#12Would something like this be possible for FPUs as well? I see there are currently three separate extensions for floating point instructions varying by register widths.
The vector extension includes FP instructions too
Re: Programming with RISC-V Vector Instructions
#13Wow, this RISC-V ISA truly is quite brilliant.
Having worked on PPC, with a RISC Instruction set the difference between 128 bit vs 256 bit instructions really does eat up the limited opcode space for really trivial differences.
Also having written say one fast version of vector array copy can now just be used between different vector version lengths, no need to write different versions to exploit expanded width, and same goes for many vector compiler optimizations.
How does this work with physical registers as opposed to architectural ones? Typically in PPC the 128 bit and 256 bit ones were architecturally and physically non-overlapping so you did get extra registers when you go from 128 to 256 or 512. I don't know if that's the case for RISC-V here.
But yeah, brilliant looking forward to more!
Re: Programming with RISC-V Vector Instructions
#14Earlier quoted context omitted.
Borrowed from the best.
For those of us not in the know, from whom were they borrowed?
This PDF might help, it explains the differences with other ISAs
https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.p...
Re: Programming with RISC-V Vector Instructions
#15Earlier quoted context omitted.
The RISC-V Vector ISA is credited to Cray "vector processors" [1], explicitly by the RISC-V authors. Additionally, I believe experimenting with vector ISAs was mentioned as one of the reasons they started another RISC research project, which ended up being RISC-V. [1] https://en.wikipedia.org/wiki/Vector_processor
Yeah, RISC should have been called CISC, Cray Instruction Set Computer.
Well it is the fifth RISC ISA from the people who invented RISC.
Re: Programming with RISC-V Vector Instructions
#16I highly recommend Lex Fridman's recent podcast with David Patterson [1] for anyone interested in learning about the history of RISC, computer architecture, and also interesting predictions re: Moore's Law. [1] https://www.youtube.com/watch?v=naed4C4hfAg
Like a year ago I only learned about Patterson, because I got a (random) book out of my uni library about computer architectures. His books are fascinating. He is fascinating.
Re: Programming with RISC-V Vector Instructions
#17What'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 the previous writing correctly.
Re: Programming with RISC-V Vector Instructions
#18Wow, this RISC-V ISA truly is quite brilliant. Having worked on PPC, with a RISC Instruction set the difference between 128 bit vs 256 bit instructions really does eat up the limited opcode space for really trivial differences. Also having written say one fast version of vector array copy can now just be used between different vector version lengths, no need to write different versions to exploit expanded width, and…
The 32 variable length registers don’t overlap; the register grouping is orthogonal to the length of each register.
The grouping... sounds “interesting” to implement in an OoOE design. Most obvious would be to have the instruction decoder emit one uop per register in the grouping... but that means vsetvli would have to stall decoding until it’s resolved. But that also seems to be how element size is set, so that would kill the performance of mixing precision in the same kernel...
Well I guess it could assume the grouping doesn’t change and flush the pipeline if it did. But you still don’t want to be mixing kernels with different groupings...
Re: Programming with RISC-V Vector Instructions
#19What'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 then v0 would be 0x0101010101010101 and v1 would be 0x0000000000000101.)
(What personally don’t understand is the point of these register groupings; they seem a bit extraneous and error prone, as you already can set the element size and you have to guess at the minimum vector register size…and why wouldn’t you always just set them to 8? I think ARM’s SVE does something similar but it fixes the size for you essentially.)
Re: Programming with RISC-V Vector Instructions
#20Irrelevant 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 has 0xcd or 0xef in it, it's not BCD, is it? It's "binary coded hexadecimal", or as we usually call it, "binary".
This code converts a byte string to its hex representation. It has nothing to do with BCD, right?