Re: RISC-V Vector Extension post-public review updates
|
Bill Huffman
I'm glad this came up. I certainly wouldn't want to try to make an implementation work for these cases. 😊
toggle quoted message
Show quoted text
I lean a bit toward #3, not so much because we might use the space as because I think we've called all the other similar corners of opcode space that don't make sense to implement "reserved." Possibly that's because they might make sense someday and this won't. But I'm OK with #1 or #3. Bill -----Original Message-----
From: tech-vector-ext@... <tech-vector-ext@...> On Behalf Of Krste Asanovic Sent: Monday, November 15, 2021 4:58 PM To: Guy Lemieux <guy.lemieux@...> Cc: Krste Asanovic <krste@...>; tech-vector-ext@... Subject: Re: [RISC-V] [tech-vector-ext] RISC-V Vector Extension post-public review updates EXTERNAL MAIL | We do have a choice of:On Mon, 15 Nov 2021 13:29:58 -0800, Guy Lemieux <guy.lemieux@...> said: | 1) Mandate all implementations raise an illegal exception in this | case. This is my preferred route, as this would be a minor errata for | existing implementations (doesn't affect software), and we would not reuse | this state/encoding for other purposes. | 2) Allow either correct execution or illegal exception (as with | misaligned). | 3) Consider "reserved", implying implementations that support it are | non-conforming unless we later go with 2). | I don’t have a strong opinion, but I prefer a route that allows us to | recover those instruction encodings — they seem to be getting scarce hence represent value. You said there were already requests for extra instructions — would this space be usef for any of them (or other as-yet-unforeeen instructions)? | Does (3) give us the best route to reuse the encodings in the future? | I’m a bit confused about the permanence of (1), and I don’t like the possibility software fragmentation that will arise from (2). | Guy The problem with this encoding space is that in some cases (i.e., vector indexed stores) the reserved encoding is actually only for some combination of vtype control state + instruction bits, or in the others it is low-quality space, e.g., where the source vector register specifiers overlap. So, I would assume 1) would be permanent. As a general comment, folks seem to overweight the long-term value of awkward corners of the encoding space, versus the short/medium-term benefits of having clean and simple encoding. More mature architectures tend to add cleaner extended encodings (prefix bytes/words) rather than ramming substantial additions into awkward unused corners. Krste |
|
|